It is 3:55 AM and I need to head to the airport in about 30 minutes but before my lovely 28-ish hour journey back home I wanted to jot down a repeating theme from the STeP-In Conference that just concluded here in Bangalore...
Keynote address was by Ashutosh Tiwary, Product Unit Manager for Visual Studio Team Edition for Software Testers. In his presentation he talked about the future quality as moving beyond funcationality into areas like performance, load testing, coordination with operations, etc. One of the most striking things in his talk was a workload trend diagram from lean manufacturing (Toyota?) that showed the (a)amount of work still to be delivered by development, (b) the amount of work currently ready to be tested or in testing, and (c) the amount of work completed. The chart for a healthy team shows a roughtly constant amount of work in category (b); the unhealthy chart showed the amount of work in category (c) balloning, as clearly the QA team is unable to keep up.
This chart was cool, and then on top of that I was I was totally caught of guard by what he said next: "...so in this situation you need to diagnose why the project is unhealthy. Maybe the problem is poor quality coming in, so maybe you need to shift more resources in to coding and unit testing." Exactly!
This idea of poor quality out of development making QA slower was supported by Michael Bolton during his talk on Exploratory Testing. He had a chart -- that I will steal (with attribution) for a future talk, I promise! -- showing the number of features tested in a 90 minute session when 0, 1 and 10 defects were discovered and logged. This was a model driven chart where he was assuming something like 2 minutes per feature to test and 10 minutes to investigate and each defect. When you see that 45 features tested in the session is slashed to only 19 when ten bugs are discovered, you can understand why improving unit testing could help make your QA team faster.
As you might imagine this a perfect setup for my talk, Improving QA Through Developer Testing. It was my first time talking to a QA audience about why developers should be testing and I wasn't sure how it would go. Perhaps it was the excellent warm-up presented by the earlier speakers but I found the audience very interested and very engaged. I think these talks helped them better understand how they've been suffering from incomplete work. Of course they knew they were suffering, but now they could put a name on it!
So if you're a developer reading this who _isn't_ writing unit tests, look out! You might be having a visit from some of your coworkers who'd like to talk to you about that...
Posted by Jeffrey Fredrick at January 20, 2007 02:24 PM
TrackBack URL for this entry:
"Maybe the problem is poor quality coming in, so maybe you need to shift more resources in to coding and unit testing." Exactly!"
Amen. It upsets me when I hear fellow programmers complain that QA is not catching enough bugs. Hello?
Posted by: Julio Santos on January 20, 2007 04:52 PM
Shouldn't that be "make your QC (Quality Control) team faster"?
Though the title "Improving QA Through Developer Testing" still works.
Posted by: Jason Yip on January 20, 2007 05:33 PM
Reminds me of the story in The Goal (Eliyahu M. Goldratt ) where his camping expedition taught him about bottlenecks and I was thinking of using ideas like this to sell testing to the management
The examples you give above are pretty much the way I was thinking of going, thanks for helping clarify my thoughts and give me some good examples
I think I'll pay our developers a little visit this week...
Posted by: Phil Kirkham on January 21, 2007 03:15 AM