A few weeks ago I recommended the Linkedin discussion "How to reduce the cost of testing", then on page 10.
Now it's on
page seventeen. Here's an answer I found really interesting, by Sushil Gehi:
Simplest way, make unit testing robust and complete, introduce right the first time concepts and eliminate system, integration and UAT.
(emphasis mine)
Challenged on this idea, Sushil responds:
Deming in his 3rd point of his 14 point concept clearly says "Cease dependence on Mass Inspections"
The revolution will soon be at your door. either accept it or get swept by it.
Here's my reply; I thought you might enjoy it:
@Sushil wrote:
"The revolution will soon be at your door. either accept it or get swept by it. "
RESPONSE:
I'm pretty sure Bill Hetzel wrote something like this around 1986, when he claimed the next era of testing, the "Prevention Era" was upon us.
When Extreme Programming (XP) started in 1999, the rhetoric was that XP teams did not need "QA People" because we were going to automate all the tests. Today, even the founders of XP (Kent Beck, Ward Cunningham, Ron Jeffries) would admit there can be a role for a tester in an XP shop.
Now we're hearing the rhetoric again. How are we supposed to respond?
How about this:
In point 3 of his 14 points, Deming was talking about mass inspection of /manufacturing/. Now, inspecting the physical bits on the CD one by one after the CD is copied, that kind of thing is what Deming meant. Nobody I know actually does that.
Instead of trying to get it right the first time, I'd suggest failing fast and adjusting; the kind of solid engineering principles that created the gossamar condor.
Also, I'd take a long hard look at the bug tracking system, and ask ourselves "are these the kind of defects that could be prevented up front?" Given that the number of possible test scenarios are infinite, we'd want to know if it would be faster to try to create all the tests up front, or if it might be net faster to find tests as we explore the software - viewing testing as a learning process.
In my experience, doing empirical research on a couple of different bug tracking systems, the latter is often true. Yes, to some extent, you can use the cost of change curve to do up-front work and save money. Eventually though -- and this is where I disagree with some of the classic interpretations of the cost of change curve -- 'everything up front' analysis costs cause the total cost of the delivered software to increase.
If you want say you want a revolution, please allow me to suggest "The Ongoing Revolution in Software Testing" by Cem Kaner.