During the ‘Agile Quality Management – Axiom or Oxymoron?’ talk at Agile Testing Days today in Berlin, David Evans talked about several aspects of agile development that often confuse and scare traditional test managers. One of the aspects that was particularly interesting to me is the fact that there is no test management role in agile literature. Test managers are often “afraid that they’ll disappear in a puff of logic when agile testing starts”, said Evans.
According to Evans, the oxymoron here is managing testing. Test management is one of those hangovers from traditional waterfall development, which was a best practice then but does not really apply in agile processes. When testing was a mini project itself, it had to be managed separately. When development and testing are integrated this overhead goes away. Testers belong to the team, tests are specifications, so they don’t need separate management from development. The responsibility of test management still exists, but lies with the team.
This doesn’t mean that test managers will necessarily lose their jobs. Test managers can become “practice managers”, who are responsible to get the best possible testers and make them available to a team, but then step away. Test management activity can also become similar to coaching, mentoring testers and educating them, hiring, helping people through their career. These responsibilities still exist and that is where the responsibilities should be in terms of management. An alternative, which Lisa Crispin mentioned, is that they can go back to testing.
Speaking about heavy test management tools, which are equally missing from agile literature, Evans said that they are useful for metrics such as tests are running at a given pace, or 98% of our tests are passing. But on agile projects you expect a 100% pass rate and frequent execution, so metrics become irrelevant. Evans said that 98% pass rate might be good news for a test manager on a waterfall project, but an agile team will view that as “we have tests failing”, something that has to be addressed and fixed straight away. The percentage of failing tests is irrelevant in this case. As there is no need for such metrics, agile teams tend to use lighter-weight tools that get their job done.
