|
Test Your Requirements
Use these three 10-minute checkpoints to verify your project requirements throughout the application lifecycle.
by Jeff Gainer
Posted October 15, 2003
Contrary to what many software practitioners think, testing is not an activity that begins when coding is mostly complete. For that matter, testing doesn't necessarily begin with unit testing, either. The good news is that you can begin testing even earlier.
You can remove defects long before they reach the coding phase, and best of all, you can produce higher-quality software and save your project money. The cost of removing a defect (or bug, if you want to be politically incorrect) rises exponentially throughout the product lifecycle. In fact, studies have demonstrated that it can cost as much as 200 times more to remove and fix a bug in production than if the same bug had been caught in the requirements phase.
But how can you test requirements? And isn't that the job of the requirements team, anyway?
Ideally, testing commences as soon as the business case development begins. From that moment on, testing runs in parallel with requirements definition, and then testing continues all the way through design, coding, release, and maintenance. (For further reading, see the FTPOnline Special Report on Testing and Performance.)
The Three Checkpoints for Requirements
This article describes three 10-minute checkpoints for your project requirements. A 1997 study found that requirements errors can be traced back to as much as 85 percent of project rework costs (see Resources).
Test a requirement by asking three straightforward questions: Is it correct? Is it complete? Is it measurable? If the requirement passes all three of these tests, your requirement is in good shape and you're ready to proceed with writing tests based on that requirement.
Checkpoint One: Correctness
This is the most obvious test, and also the most problematic to determine. At this point, you might need to work closely with business analysts and domain experts. Walk through each path of the use cases (or user stories, if you're doing XP). Each path or scenario in the use case will specify one or more functional requirements. You'll be surprised how often a fresh, independent eye and a simple walkthrough of a use case will uncover missed alternate paths or incorrect assumptions.
Back to top
|
