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

13 October 2015
| |
Reading time: 3 minutes

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

Comments (7)

Arne Mertz

Arne Mertz

13 October 2015 at 10:53

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.


    Peter Gfader

    13 October 2015 at 18:37

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

      Arne Mertz

      Arne Mertz

      14 October 2015 at 13:14

      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


Peter Gfader

13 October 2015 at 18:33

Microsoft CEO Satya Nadella realized something similar:
“it often makes sense to have the developers test and fix bugs instead of a separate team of testers.”


    Michael Schadt

    20 October 2015 at 09:02

    Took Microsoft a while to realise 😉


Adam Bantell

21 April 2016 at 06:46

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.


    Alan Larimer

    26 June 2017 at 13:42

    @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/


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »