A Fortunate Perusal…
I was recently browsing in a second hand charity book shop.
On the counter was a copy of Hetzel that they had neither priced nor put out on the shelf so I asked them how much it was, feigning disinterest in case they should quote a figure too close to Amazon’s (£££). Fortunately they quoted £2, this was the first time I had ever been pleased to see testing undervalued.
There then followed a short conversation between myself and the staff, the Older Charity Shop Assistant (OCSA) and the Younger Charity Shop Assistant (YCSA):
The Obligatory Sales Talk…
- OCSA: Software testing, how dull.
- Tester: Well… that’s my job
- OCSA: Oh, what do you test it for then
- YCSA: (knowingly) Viruses
- Tester: No. Problems.
- OCSA: Oooh, I had a problem with some software once, kept crashing my machine, every so often, boom, lost work I did,
- Tester: Well, yes software does that…
- OCSA: We have one through the back, slow as anything when it works at all and then it doesn’t, boom, many’s the time I’ve had to start again I have,
- Tester: Well…
- OCSA: That was you not doing your job properly that was
- Tester: Ehm…
- OCSA: Always something going wrong with these software things, viruses and the like, why can’t you do your job.
- YCSA: (knowingly) Yeah, viruses
- Tester: …here’s your two pounds thank you very much.
I considered telling them all about testing, about quality and about the software development process, about budgets and about compromise, possibly using the battered copy of Pressman that they had on the shelf, but decided not to.
Others
This is not an isolated incident, mistakes in the software process are often blamed on quality control, and testing in particular, rather than the development process as a whole. And it isn’t a view held solely by the general public, but also by people who should know better - management.
The easy retort by testers is that they do not code bugs in to the system. But if testers are ever put in the position where they feel like making such a retort then the process has already failed and has gone into scapegoat mode. This is usually a process of denial rather than learning and very little good can come of it.
There are no silver bullets which will slay the error demon. The team must be vigilant when striding out on each new quest, step confidently on solid ground and guard against their comrades succumbing to weakness, for it is at those moments when the error demon strikes.
Quality is the responsibility of the entire development process. To blame the feedback loop is to ignore the symptom and the organism will most likely perish from disease.
This essay originally appeared on CompendiumDev.co.uk on 4th January 2012 as a ‘journal notes’ this was in the days before I had a ‘blog’ setup and still had a ‘web site’. It seems more like a blog post than an essay so I’ve moved it over to EvilTester.com.
