What Do Agile Testers Look Like?
I recently spoke with a recruiter. “I don’t understand the QA market anymore. No one is hiring except for agile people. And they want people who are developers. What’s happening to QA?”
Manual testing was never quality assurance; it was testing. And, manual testing is low-value, high cost work, especially when you compare it to automated regression testing. Now, before you assume I mean there is never a time for manual testing, no, I did not say that.
There is a time and place for exploratory testing, which tends to be more manual. There is a time and place for opportunistic testing. But the kind of system-level testing that says “Does this feature meet its acceptance criteria, and does the rest of the system still work and can we know that within a two-week timebox?” is not primarily manual testing. That’s what agile projects need. (If you’re using an incremental or iterative lifecycle, you need to know this too, just not in a two-week timebox.)
That means that agile testers have different technical skills and provide different deliverables (and value to the project) than the kinds of testers this recruiter is accustomed to.
These testers have different functional skills, solution-space domain expertise, and tool capabilities than strictly manual testers. See Four Dimensions of Technical Skill for more information. In agile teams, some of the testers don’t look much different from developers, except that their code doesn’t release. Some of the testers might be better at sitting with a product owner and saying “What does done really look like for this feature?”
Whatever their skills, these testers are multi-dimensional people, capable of much more than manual testing. They are not second class citizens, but are valuable members of the product development team.
For you recruiters, think about what value the testers add to a project team. If you’re a tester, what skills do you need to acquire to provide more value to your project team? And, managers, does this make sense to you? Does knowing about the state of the product often provide you more value than having to wait days or weeks until you can manually finish a test run make more sense?
6 comments October 2nd, 2009