Merge pull request #153 from Zuehlke/peitor-article-tester

#149 What’s Wrong With: “I don’t write any tests since I am not a tester”?

articles/whats-wrong-with-i-dont-write-any-tests-i-am-not-a-tester.md

@@ -0,0 +1,106 @@
+---
+authorName: Peter Gfader
+authorGithubUsername: peitor
+issue: 149
+title: What’s Wrong With: “I don’t write any tests since I am not a tester”?
+---
+# {{page.title}}
+
+"Not a tester, so what are you then?" you might ask.  
+Being that offending is generally not helpful.  
+Unless you try to catch the attention as I do in this article 😉  
+Let’s digest the situation in detail.
+
+A friend of mine attended my Scrum Developer class and caught fire during the "Testing" module where we talk about Code Quality, Testing, Test-First approaches, TDD and more.
+Boom! After that class he was on a mission to convince everyone that TDD is the only way to do things.
+
+The 1st day back at work he talked about improving the team and trying TDD and got the following statement from his colleague:
+"I don’t write any tests since I am not a tester".
+
+I know he handled the situation quite well, but he asked me for advice.
+
+One thing to consider is the underlying question to this, which might be:
+"How do we get people to change their behavior?"
+So here are my thoughts.
+
+## **Yourself First**   
+First of all, think about things to consider for yourself:
+* Why is the practice or tool that you are suggesting any better than the current way of doing things?
+* Can you explain the value in the proposed change?
+* Can you lead by example?
+* Do you have enough patience and skills to teach others?
+I would try to work on yourself before trying to change others.
+
+
+## **Roles?**  
+I see that a lot of people are focused on their role, forgetting the bigger picture of the team and purpose of the work they are doing.
+I would ask these questions:
+* Are we one team that focuses on the Sprint Goal?
+  In a Scrum context there is no “tester”, “programmer” or “architect”, we are all professional engineers that deliver value through collaboration.
+* No matter what, do we stand together and support each other?
+* Are we doing whatever is necessary to deliver a usable product every Sprint?
+
+
+## **Done?**  
+Colleague: "I don’t write any tests since I am not a tester".  
+Ask: "How do you know when you are done?"  
+
+What is on our Definition of Done?
+How can we build a usable, tested and fully integrated product increment every Sprint?
+Are we doing that already? Why not?
+
+
+## **Fast Automated Feedback**
+Tests send you a message. They send you a message now and in 5 years from now. They tell you:   
+**Is the code working as it is expected or not?**  
+This fast feedback is very valuable if you are working on your product, either by changing it, fixing a bug or by adding a new feature. 
+Ask: "How do you know our product works in 5 years?"    
+
+
+
+## **Tests are as important as documentation**  
+Documentation is needed, and one good way to document how software **must** work are tests. I emphasize **must**, since written documentation only documents how the software **might** work.  
+We learned too often that documentation gets out of sync too easily.  
+
+
+
+
+
+## **Quality**  
+Quality is everyone’s responsibility in a Scrum Team. There is no QA Team in a Scrum context, which means the whole Scrum team is responsible for delivering high quality software that works and is fully tested.  
+
+Quality attributes that are important:
+* Does it work at all?  
+  Huh!
+* Does it work well?
+* Is it deployed and use-able?  
+  Are the users able to access it?
+* Is it useful? 
+* Is it successful?
+* Does it make the impact we wanted to achieve?  
+   -> Yes! Value is key
+
+
+## **Tests are code**  
+Are you a coder?? Yes?   
+Tests are code. So write some tests, especially so that you can sleep better at night.  
+
+
+## **Another 2 reasons for automated tests**  
+1. You help your Team. You support development with a very fast feedback loop. You will find tests covering small units very helpful as they allow to develop logic quickly and with high confidence.  
+Developers that design, code, test and drive their implementation with tests are much faster in developing software.  
+
+2. You help to reduce regression issues: Did you break any major functionality? Bigger tests that cover entire "user scenarios" are especially helpful here.  
+
+
+## **Still not willing to write tests?**  
+Ask: 
+* How can You help? 
+* What can You do?  
+
+You can always get them coffee.
+
+Show support. We are in this together.  
+
+*By {{page.authorName}}*
+