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