Is Your Database Ready to Release?
How do you know when a database is ready to release?
If you're like me, you first check with your test manager. Who better to tell you what kinds of bugs remain. As far as I'm concerned, there's also no one better equipped to size up the overall quality of the latest build. When you've finished talking with your test manager, you might drop by to chat with your developers. Bug counts and quality assessments are one thing. But you also need a read on how close the developers are getting to finalizing their designs and implementing the application requirements.
Follow the Pros
It might surprise you to learn that this is basically how professional release managers assess a database's readiness for release.
With a couple of exceptions, anyway. First, release pros demand objective evidence to tell them how close to "bug-free" and "code-complete" a database really is.
And second, the pros don't wait until a release candidate nears completion before checking its readiness. They're busy tracking progress from the day development begins.
SQL Readiness Metrics
So what's this "objective evidence" the pros demand? The release readiness of a database rests on four related metrics:
1. Functional readiness
This is basically your database's "feature set". Does it satisfy all logical requirements and business rules? Has every nonessential function been carefully stripped away? As a readiness metric, the evidence for functional readiness is observable from your code inspections and test reports.
2. Performance readiness
Performance readiness verifies that your database satisfies the production qualities your customer expects: response-time, throughput, load tolerance, failure and recovery behavior. You capture these performance metrics with bug reports and SQL code inspections.
3. Defect readiness
When you hear "system readiness", reliability is what usually comes to mind. How long is your database available before a serious bottleneck appears or before preventive maintenance is required? How long does it take you to recover once a serious failure forces you offline?
Bug counts are your single best defect readiness metric. By tracking weekly trends in "defect arrival rates", you'll always know how ready you are to release. Weekly build tests are an excellent source for these defect counts. So are the regular bug reports your QA staff starts logging once system testing begins.
4. Source code readiness
As if I had to remind you about all those triggers and stored procedures you've written for your next release.
The issues here are pretty straightforward:
* How much new code are you generating each week?
* How much existing code are you reworking for the second or possibly even the third time?
* Are both metrics dropping and stabilizing as they should?
Your source base initially multiplies as you construct new database features. But once development's underway, testing workflow increasingly drives the release process. Bug repairs, in other words.
What? You don't already have a readiness tracking system? Then consider which of these metrics might work best for you. And don't forget to factor in the time and effort you're ready to invest.