Okay, so that title might seem a bit over the top. But then again, I haven’t put a public blog up for a while, so why not go back to basics – what do I think a tester does within an Agile Team?

I believe the best way of developing is by using a collaborative approach to development, and hence to testing. I believe that testers should be involved right from the very start, and for them to be continuously involved throughout the whole of the development cycle. I do not believe that a piece of work should go through an individual product, development, and testing phase.

When an individual piece of work reaches a story ‘kick off’, or ‘Three Amigos’ session, I prefer that the first part of this meeting should only be a discussion of the requirements – what is actually required by the end user. I like to use some variation of example mapping, or specification by example, etc, in order to talk about the requirements, get a shared vision of them, decide what is in and out of scope, and talk through the edge cases. The tester(s) in the team will use their experience of the application to drive those discussions. Only once the requirements and scope have been agreed will the solution be discussed. It is the tester’s responsibility to ensure that they understand how they will be able to test the story.

While the story is in development the tester should be fully involved then too. The tester should be viewing any work that can be demoed at any point in the development process (not wait until all code is complete); they should be viewing automated tests (and suggesting new tests too); and pairing with the developer to test on the developer’s machine. Testing this early means that finding issues does not have to wait until the code is complete and available on the test environment; it reduces the number of bugs that are raised; minimises stories ‘bouncing’ between dev and test; and speeds up story delivery.

I believe that every bug should have a kick-off too. I’ve seen too many bugs fail in test due to a lack of understanding of the scope of the issue, the bug only being partially fixed, or inappropriate solutions (that are sometimes worse than the original bug!).

I believe that testers add most value through exploratory testing. That a tester’s time is best spent exploring software – using their knowledge, experience and intellect to discover how the software works, and to think through how it will be used by its end users. I believe that having to spend time writing test cases, running regression tests or writing bug reports is a poor use of a tester’s time.

I believe that the test environment should be the very last time that a tester tests the new functionality. Not the first.

I believe that a tester isn’t just responsible for testing. I believe that the tester is equally responsible for teaching the rest of the team how to test and the benefits that good testing brings to the team, the product, the department and the business. I believe that the only way that can happen is by close collaboration and open communication with every member of a development team – a team with shared goals and vision.

I believe that a good tester can learn well by themselves, but will learn better with others. And I believe that learning is even better when it’s with people from other teams, departments, companies, industries, countries. I believe that teaching, coaching, collaboration and mentoring are equally as important as learning.

I believe that the best testers are vocal testers, and the most important skill for testers is the ability to communicate well with others..

The Test Commandments:

  1. You shall have no other gods before SBE.
  2. You shall not make idol, vague or inaccurate bug reports.
  3. You shall not take the name of Elizabeth Hendrickson in vain.
  4. Remember the Sprint Planning day, to keep it holy.
  5. Honor your customer.
  6. You shall not murder in order to get out of doing Regression Testing.
  7. You shall not commit adultery. (You work in Development – just count yourself fortunate you’ve managed to find one person who’ll have sex with you!)
  8. You shall steal – good ideas and practices from anyone and everyone.
  9. You shall not bear false witness against the Developer.
  10. You shall not covet. Even when James Bach yet again tells you how much he earns for a couple of hours work.

I was at TestBash a couple of weeks ago, and in the Lean Coffee meet-up one of the other testers at our table was telling us all about how they’re having to put huge amounts of resource into regular Regression Testing. I asked them whether they were finding enough issues in Regression Testing to justify it, and they responded “Lots. Every time”.

Which got me thinking – doesn’t that just mean that part of their process is really broken? Regression Testing is probably the least fun part of testing. The least interesting. The most stress related. The most labour intensive work for the lowest possible reward. It’s how we operated 15 years ago, when I first started testing. So why does it seem to be relatively unchanged in all that time, when so much else that we do has matured and grown?

Let’s think about it:

So there you are, you have a working Live Environment, and you have new work (features / stories / bug fixes) that you want to add to it. You have some kind of ‘new’ shiny process that you’re using to get your new features Live (Agile / Scrum / Kanban / Lean / or some variant thereof…). You’re doing all of the following:

Step 1: You’re agreeing the Acceptance Criteria before a single line of code is written.

Step 2: You’re telling the Developers exactly what you’re going to test.

Step 3: You’re deciding as a team at what level all the tests are going to be automated.

Step 4: You’re sitting with the Developers who are showing you all their automated tests. You’re suggesting more, which they are adding.

Step 5: You’re testing (often!) on the Dev machine.

Step 6: All of the existing automated tests are being run – and are, of course, all passing!

Step 7: You’re deploying to your Test Environment and checking all the basic functionality works (so no environment / deploy issues).

Step 8: You’re running Exploratory Testing sessions on your new functionality.

Step 9: You’re having your testing reviewed, and having new charters suggested.

Step 10: You’re adding additional automated tests, should you have thought of them.

So, you’re doing all of that.

And then you’re finding issues during Regression Testing?!!!!

Maybe it’s about time you stopped fixing the issues you find, and start fixing the reasons that they’re getting there?

Look at each issue that you raise – and identify how it didn’t get picked up earlier.

  • Do you not have the right automated tests (too few, the wrong level, just plain bad!)?
  • Are you not testing early enough, or not being a part of the development process until it’s too late?
  • Are your test environments out of kilter?
  • Are you not adequately using methods of protecting unready code (like feature toggles, etc)?

Spend the time closing that hole in your process – and soon you’ll be able to reduce the time that you spend Regression Testing – and get back to the good stuff…




If any form of pleasure is exhibited.

Report to me and it will prohibited.

I’ll put my foot down,

So shall it be.

This is the land of the Free.