Developers Heart Testers
The process of testing used to be easy. A tester would take the requirements and the specification and write a test script. When the functionality was completed the tester would execute the test script and provide feedback based on the output.
As with waterfall, doing handoffs to testing has fallen out of style. As I had one client telling me
We don't need any testers. Why not have the developers write it correctly the first time.
And I would agree. But test driven development and testing does not target the same defects. Developers can assure code they're writing executes as intended, but they cannot garantee that requirements where correctly communicated, or that we're building the right thing.
Today we're working with small self-organizing, cross-functional teams where team members work together to deliver the most valuable product. We put the client in the team to recude waste in handoffs and remote communication.
The team will iterate over a subset of the product features, and in a few weeks delivering an MVP (minimum viable product).
We don't have a tester in this team because
- Developers are writing automated tests
- The product owner is in the team to reduce communication errors
So we don't need any testers right?
While we're building each feature after the product owners will, there is no role to question if we're actually building the right thing.
We're missing out on the testing role using experimentation and questioning to challenge the product. Our software developers are building according to spec, but the specification might be wrong and the requirements can be misconcieved.
Do the product owner really know what he wants?
Testing in an agile project
Nobody wants us to bring back the handover to testing.
Instead we must bring the tester into the team with the developers. I've had great experience of pairing with a tester, working out the functionality together and the test cases for the automated tests.
By pairing developers with testers we reduce the need of documentation in test scripts, test reports and can focus on what's important - experimentation and questioning the product.
The result is a higher degree of awareness in the team about the problem, the problem and the solution.
A tester can also automate
Developers are reluctant to pairing with testers who don't know anything about code. But that is a misconception of value versus waste. Code is not a cryptic language that programmers own sole rights to.
Instead we should think like this
If a tester can understand my code, then the code is maintainable.
A tester can, and should use code to automate their needs when it comes to testing. Coding is a tool that is very usable for repetitive tasks, as well for a tester as for a programmer.
In a cross functional team, the software developer does not have sole right to code.
Are we testing or aren't we?
We must take extra care in what we call testing. A developer cannot test the functionality that he's written, because he has his head in the code. He can write automated tests to verify the code does what he intended it to do.
Unless we have someone with the ability to experiment and question our product, we don't really have testing in our team.
I've seen situations where the product owner is the tester, but that person would only verify that the implementation fulfills his requirements and expectations on the product. Testing is also about challenging the requirements to find the right solution to the problem.
There should be a tester in every team
My conclusion is that every agile team should have a tester in it. You cannot expect developers to test the implementation that they produce. You cannot expect the product owner to know how to test, and the project manager is too biased to do it properly.
A tester on the team, pairing with developers, will give developers insight how to challenge the system and experiment with it. It will help you to provide better solutions making sure you do the right thing, and not only doing it right.