Imagine There's No... BUG DATABASE

It’s not easy to imagine life in the software industry without a defect management system – these tools have become a foundation of the software development process.  We spend staff years of time discussing the defects, arguing about the priority and severity and making sure that the defect lifecycle matches our business needs.

THE SOFTWARE DROP TO QA

You know the excitement that greets you in the office when software is dropped to QA.  The testers salivate as they prepare to rip the delivery apart limb by limb, in the same way a lioness would shred a hyena on the African plain.   There’s not a formal competition to open the most defects but everyone knows that Allen finds the most problems, and he doggedly stands his ground when a developer challenges the validity of his defects or the severity that he assigned. Sally is new and her bug tally has been low.  But she’ll find her way soon.

The bugs start to mount and the daily meetings start. All the developers and all the testers sit around a table and on a conference call discussing the minutia of each problem.  Periodically the team takes time out to remind all the members about the distinction between severity and priority assignments and reviews that these are being used properly.

When a coder addresses an issue she must spend a further 15 minutes writing an explanation of the fix (“code diff preferred, where feasible”) and after validating the correction, the tester must spend another 5 minutes updating the defect to ensure that the correct code drop number is included and the test case number used to do the retest is properly logged.

On a weekly basis the managers pull reports from the bug database and spend several hours manipulating and annotating those reports so they can go into a nice thick PowerPoint that they can present to executives while said executives do more important things like check their email and IM their spouses.

Folks, all of this takes far too much time and it all distracts from the primary end goal.  Our goal is to deliver high quality software in a timely manner.  The only time that a customer or an executive cares about the quality of the data in your bug database is when they do an audit because you consistently miss your primary goal!

Despite this, an entire industry has been built up to support, maintain, and grow this wasteful practice. We need to stop this now!

NOW IMAGINE…

Imagine this scenario: Your test team works closely with the developers to build test scripts.  As the developers finish their code, the testers work, with the developers to run the test scripts, identify and fix defects (in both the code and the test scripts). When the code tests clean it’s checked in and goes into a build with other changes.  That build gets installed in a controlled environment and all the test scripts, from all the testers are run, together with test scripts from previous releases. If some of the tests fail, the developers fix the defects, and when all the scripts run clean, the code is released to production.

THERE IS NO BUG DATABASE.  The code is released when the tests run clean.  If you want to know whether you can release the code, simply run the test suite – if all the tests pass, you can release the code; if they don’t, you can’t!

Now think about the time and effort that you would save.  Think about the productivity gains that you would realize if that time and effort was re-channeled into building more features and functionality.

Now, in practice, yes, there must be a bug database because sometimes a test will fail and you will decide that the failure is not significant enough to hold up the release.  In that case you need to disable the failing test, and log the bug somewhere so you don’t forget it.  But still… this is a much smaller amount of effort than the traditional software team spends tracking defects.

A NEW YEAR’S RESOLUTION

It’s that time of year so let’s break down that critical barrier in many traditional software development teams – the invisible wall between the developers and the testers.  Both teams need to appreciate the value that the other brings – and both need to understand that the real goal is delivering quality software… fast!