Saturday, 17 July 2010

Testers - we don't need that any more.

In the past Uncle Bob and Martin Folwer have both pissed me off with their "we don't need testers anymore" messages that they have delivered in the past. To be fair, Martin knows he pissed me off, i told him, (stick to getting more women into IT Martin); but recently Uncle Bob seems to have recognised the benefits of having career testers within the team. Perhaps he hadn't met good testers before; after the recent discussions I had at the London Tester Gathering it seems that good testers (Agile or not) are a fairly rare breed.

So O.K, let me stand back for a moment and reflect on what XP teaches us in that a highly disciplined team should be able to achieve zero defects, so its easy to say, zero defects means we don't need testers.
Moreover, at the SIGIST conference in June, Julian Harty (ex Google  senior test engineer) delivered a presentation that posed the question, do we need testers. What if we stop testing? After all these days people seem to want speed first and fully working functionality secondary. The future of testing?
So yes the playing field has changed, its true. But that doesn't mean i have to agree with it.

If the software is crummy, your users will only tolerate it to a point. A great example of this is reading the feedback comments on iPhone App store. Even when a piece of software is offered for free, people leave bad feedback complaining about the uselessness or poor UI etc.

The crux of the matter for me is this. Even if we did find the magic incantation that could give us defect free code, it still wouldn't mean the business would get quality software.

I'm signed up to Bachs ideal, but i'm embedded in an XP/Lean team. We have 90% test covereage across 903 classes and 201,000 lines of code (and counting).  Those thousands of tests run in seconds, before they make their way up the CI pipeline to run UI and performace tests. No nightly build, we test every checkin.

CI had my support 100%, because it should mitigate lots of manual testing. In fact it should mitigate lots of testing. As the product we work on has matured, the CI has formed a regression pack. Its sound great right? So why do I still have a team of 8 testers and a 15% defect rate?? Because developers are humans not robots. Because developers focus on what "Done" looks like, and not the bigger picture. Because they dont understand the context within which the story was written and thus make an assumption. Because they are testing in the small. Because they didn't have the right data in the development environment. Because there exists two different mindsets between good developers and good testers. But non of those reasons are new, or particular to Agile. Its all old news.

But then i read this by Chief Frank C. Montagna

"Firefighters, as all humans, make mistakes. When firefighters make a mistake on the job, however, it can be life-threatening to themselves, to their coworkers, and to the public they serve. Nonetheless, firefighters will continue to make mistakes and on occasion will repeat a mistake.

Our goal should be to learn from each mistake and to try not to repeat it. We should also teach others not to make the same mistake we made. To do this, we have to admit our mistake publicly by telling others about it. This is not always easy to do. "

This Agile vs Tester friction just needs us, the testers to be pragmatic and professional; we must continue to share best practice, collaborate and talk to the developers earlier in story life-cycle. We should shout STOP! sooner rather than later, jump in feet first and embrace what may feel like an awkward discussion.

We testers are not here to simply find defects, appoint blame, or hold a "who sucks the most" post mortem. We are here to add value, and if we don't, then why do we need testers?

A defect report is pretty meaningless. You cant sell it or market it to your customers. Worse, it has overheads. So why have one? Why not have a discussion with a developer and a product owner instead?

We (Developers and QA) both work for the same company, so why aren't we working together, and demonstrating to Martin and Uncle Bob, that we are valuable and that testing and testers should be taken seriously.





1 comment:

  1. Thanks for your thoughts Stuart. I would tend to agree with what you're saying. We really should be working more closely with the developers and not have to generate so much paperwork assigning "blame" to bugs

    I don't work in an agile environment myself but I'd like to try it at some point.

    ReplyDelete