Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 84 posts at DZone. You can read more from them at their website. View Full User Profile

Applying a Classic QA approach to Software Development

  • submit to reddit

My father was Quality Manager in a company that produced card board boxes for
cigarettes, pralines and stuff.

When he tested (i.e. inspected) a batch of boxes, he took a sampling and checked various criteria like the coloring the alignment of different colors.

Then there were a couple possible options:

  • If almost no problems were found, the batch was shipped to the customer.
  • If some problems where found, people had to go through all of the batch and sort out the bad ones. The good ones got shipped to the customer.
  • If to many of the samples were bad, the complete batch was scrapped.

Of course scrapping a production batch is expensive and a lot of effort was made to avoid it. But it was a valid option to prevent unusable products to show up at the customers door step, which was the wortst thing that could possibly happen.

In software development I most of the time see a process which only considers the first two options after testing:

  • If there are no, or very few bugs the software gets shipped.
  • If there are to many bugs the bugs get fixed and the software gets tested again.

Often this gets iterated until the first option is achieved.

There are good reasons for the difference of course. Scrapping a piece of software is very expensive. Most of the time way more expensive then scrapping even lots of palettes full of card bord boxes.

But there are cases where the third option should be considered.

What if you have very few testers, compared to developers? What if the developers produce really bad code? What would happen if you tell them:

“We gonna look at 2% of the stuff you deliver. And if we find more then x bugs the complete feature will get scrapped. We won’t accept a fixed version. We require a complete new version and we want to know what you will do differently this time to ensure the next version is way better then then this one.”

Of course this puts a lot of pressure on the developers. It’s certainly very frustrating to get the work of weeks rejected like this. Certainly nothing you want to do with a healthy team that had a single bad sprint.

But maybe an option when a team constantly fails to deliver shippable software and you only pile up crap without making progress.

Published at DZone with permission of Jens Schauder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Dapeng Liu replied on Wed, 2013/08/28 - 9:05am

Interesting idea ... 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.