In her article “Better Testing, Worse Quality?” Elisabeth Hendrickson makes an interesting case about independent testing, i.e. testing done by an independent test team. She discovered that beyond a certain point, investigating more in independent testing will make both quality and speed go down, not up. In episode 3 of the Idealcast, she summarizes her article as follows:
“[…] when you ramp up the amount of investment in an independent test group, then given the amount of pressure that’s already on the developers to deliver, it is so easy1 for the developers to say, this isn’t my problem anymore. Thank goodness we’ve got the professionals over here. It’s their job to test.” (00:11:21)
Later in the article, Elisabeth Hendrickson gives advice on how to avoid or escape this spiral of decreasing quality and speed. There are four dials you can turn either up or down:
- bug fixing
- defect prevention
- developer testing
- independent testing
Agile testers to the rescue
While the article says that it’s the managers turning these dials, I read this list and thought: is this not what we expect from a tester working in an agile team?2 We expect them to advocate for the right bugs getting fixed. To prevent defects by participating in refinement. To pair with developers on testing. And finally, to do some testing themselves as they are the experts.
And in that last part lies the danger, as Elisabeth Hendrickson tells us. Thanks to agile, we now have testers in the team with developers. Yet don’t these testers often end up being the sole owners of everything in the “testing” column? You don’t need a separate testing team to have independent testing, nor to have too much of it. Ironically, an important challenge for an agile tester is to not do too much testing.
Agile tester or quality engineer?
Looking at agile tester in this way, the difference between an agile tester and a quality engineer becomes rather moot. In practice they will be doing very similar things: avoiding to become a quality safety blanket for the team, and working in a supportive and collaborative way with their team on quality.
A bit later she adds: “This wasn’t about the people not caring, they cared deeply. […] This is an example of structure. This previous structure was giving people the illusion of something that didn’t even exist [QA will catch the bugs for us]. And once we managed to wipe away that illusion and they were dealing with reality, then they changed their behavior and their behavior resulted in an outcome that was so much better than we had before.” (00:14:57) ↩
That expectation is not entirely fair, by the way. Turning these dials from a position of authority as a manager is a very different game than doing so from a position of influence as a tester. ↩