What do testers do on agile projects?

I was just talking to someone who is on the journey towards the good life in agile.   But in their early projects they have hit a snag.

It seems that the testers want to record lots of bugs in their log so they can show them to their friends. They also want to talk to the developers about all those bugs.

But the developers don’t want to talk to the testers about bugs.  They want to write new code and create new bugs – not get interrupted to hear about the bugs that already exist.

This is not actually ideal on an agile project. So I decided to sit back and ponder why you might want a tester on an agile project.

Before I continue though, stop and think about how you would answer the question in this “agile testing exam”.  Testers are allowed three hours but it should take you a bit less:

I think the answer is (f) Foster Learning.

My reasoning is this – in waterfall you define your requirements, analyse them and then build something to meet them.  Then you test that you met your requirements.  But you can’t really test all your requirements properly so the key to testing (I think) is to treat testing as a form of risk management.  It is about identifying the key risks and implementing the tests that are worth doing to protect against them.

But in agile we have not fully documented our requirements and we are learning about our risks through building our solution.  For example, we are creating prototypes, showing people what we did to get feedback and so forth.

This means that the purpose of testing is the same as the purpose of building things early – to learn fast.  This is partly about risk mitigation (failing fast) but it is also about innovation (testing out new ideas cheaply).  In other words, testing is the core of what an agile team does – learning from the work they are doing.

This means that when you test in the early sprints (and even the late ones) you will find bugs.  But you are also going to identify potential new requirements and solution options.  You might even find that the thing people wanted before is no longer useful to them.

Some teams don’t need a tester but in my experience a good tester is like a force multiplier – they help the rest of the team learn a lot faster and therefore pay for themselves early, even if the team needs to drop a developer to afford them.

But they don’t do this by finding bugs – they do this by contributing to each stage of development from conception of an idea to implementation of a solution.

If fact – nobody on a real agile project cares if the team did what they said they would do.  Nor do they care how busy you are.  They care about whether the team is adding value and what they should do next.

Thus the role of the tester is to help the team and their stakeholders learn faster – both about the impact of what they have done and also about the potential things they could do next.

Btw – If you want some simple instructions for testers in agile projects you can try this link mechanical approach to testing