What’s wrong with: “I don’t write any tests since I am not a tester”?

from on 13.10.2015

“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 blog post 😉

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:
Henri (made up name): “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.

1 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.

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.


I see this a lot, that people are focused on their role, forgetting the bigger picture of the team and purpose of the work they are doing.

  • Are we 1 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?


Henri: “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?


Tests are as important as documentation
Documentation is needed, and 1 good way to document how software *must* work are tests. I emphasize *must*, since documentation only documents how the software might work.
We learned too often that documentation gets out of sync too easily.
I blogged about the “Why are *automated tests* so important?” on my personal blog.


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?
  • 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
Testing can be fun

Testing can be fun


Tests are code
Are you a coder?? Yes? Tests are code. So write some tests, especially so that you can sleep better at night.

Get test infected in 3 days in my Scrum Developer class!
Recently I did a a video interview where I ask my students 3 questions about the Developer class.
Check it out here https://www.youtube.com/watch?v=oLxBV4hPMkU


Still not willing to write tests?
Ask yourself: How can I help? What can I do?
You can always get them coffee.

You can always get the team coffee

You can always get the team coffee

Show support. We are in this together.

Write a comment Peter Gfader Cancel

Your e-mail address will not be published or shared with third parties. Fields marked with * are required.

7 comments for “What’s wrong with: “I don’t write any tests since I am not a tester”?

  1. Arne Mertz

    I strongly agree. I even would go further and say, a programmer who does not test is behaving unprofessional, period. Why? I'll recap a few of your points:

    Done: Unless done means "I wrote some code, don't care if it works", "done" includes the verification that the code works as intended. And the short word for "verify that the code works" is "to test". So "done" means "tested", period.

    Role: It does not matter if we have roles or not, if we are in a scrum context or not. No matter if we label ourselves "Programmer" or "Software Engineer" or something else, our time is precious, and the one thing we really know that saves time is using programs to do our work, a.k.a. automation. So "well done" in our context means automated tests.

    So, even if there are different roles, and we are doing waterfall and everything we write goes through a QA team afterwards, we HAVE to do automatic testing. Not only to prevent regressions the QA team might miss, but also because not testing means endless task ping pong from development to QA and back.

    1. Peter Gfader Post author

      >> the one thing we really know that saves time is using programs to do our work, a.k.a. automation.

      >> we HAVE to do automatic testing
      I like that you said *have* and not *must*.
      What I think about automation is, that investing in automation is something that pays off quite quickly. Although its still an investment that has trade-offs. In some context it might not make sense to automate testing.

      1. Arne Mertz

        I agree. An example that comes to mind is system tests for a prototype or spike solution. They may take a good bit longer to set up than just a manual test, and for a short lived solution that won't go into production you won't want to run that test too often, so automation might be a waste of time.
        (I am talking about real prototypes here, not the "we-call-it-prototype-but-build-the-real-thing-on-top-of-it" nightmare).
        There's a nice chart at xkcd, about investing time vs. gained time, e.g. in automation: https://imgs.xkcd.com/comics/is_it_worth_the_time.png

  2. Adam Bantell

    My team also follows the Scrum methodology. Officially, we are comprised of three developers (software engineers) and three testers (QA). Per Scrum rules, all team members are "developers". This means everyone writes code and everyone tests code. This approach has been good in that it creates an expectation that the software engineers write all sorts of tests (automation, integration, unit tests, TDD, etc) The QA resources have also enjoyed the developers teaching them how to write code -- both for the core application and testing. The major downfall of this approach is the QA resources have discovered they like writing code more than testing...and of course the engineers are not fond of testing to begin with (hence the reason they hired QA resources) So basically in the beginning, the Scrum approach worked very well for the team, but after numerous Sprints it feels like the team is about to collapse because the QA resources despise testing (the job they were hired to do) and the software engineers are spending a lot of time fixing the code that was written by the QA resources. IMO the best feature is Scrum is getting regular feedback from the "customer" at frequent intervals. The idea that engineers should be testers and testers should be engineers is counterproductive. I cringe at the thought of the medical field embracing such a practice -- where a heart surgeon performs brain surgery and a brain surgeon performs heart surgery. It is a recipe for disaster.

    1. Alan Larimer

      @Adam Bantell
      That would certainly be a challenging situation. It seems that the group has fallen into a common misunderstanding.

      The Development Team is to be cross-functional, not the individual members; individual members may still have specialized skills, as nobody can be specialized at everything; accountability belongs to the Development Team as a whole; not by organizational titles or specializations.

      The purpose of the definition of the Development Team as such is to replace the practice of having a group of individuals working for the same manager with an actual team collaborating toward a common goal. Replacing silos and hand-offs with communication and team accountability.

      HTH As always . . . http://scrumguides.org/