Use Test Cases to Clarify Requirements

How can you as a tester reduce the problems caused by inadequate requirements processes earlier on in the lifecycle ? Finding bugs earlier reduces the amount of rework for developers and allows the testers focus more on acceptance level testing.

Failed tests and re-execution of tests often result from vague requirements. Here are a couple of quick-win strategies for improvements in the requirements area. It are small gradual steps, below the management radar (no approval required) with benefit for developers, testers, and other members of the team.

Direct your attention to answering the question "What happens when ..."

When you define a test case:

• Identify input states and then specify the expected outcome. In the process of developing system level test cases, you can easily identify poorly documented requirements whether it’s ambiguous input conditions, missing information, or unspecified expected outcome. Pinpoint where requirements fail to describe the outcome.

• Complete the test descriptions by replacing missing information with reasonable assumptions and indicate this as such. This is of enormous assistance to the manager or lead developer, who then merely has to approve the modified description rather than schedule resources to complete the product definition.

• Share the information with developers, previews what tests are planned, give them the opportunity to bullet-proof their code if necessary.

These shortcut actions are not sufficient to comply with CMM or other quality standards, it is not really requirements management, important boundary/performance/configurations may be overlooked, they do not present you the big picture, neither a full description of system behaviour. However see them as a jumpstart to process improvement, you have to start somewhere and it provides a baseline for future improvements.

Find this and other paractical strategies for testers in the article: Quick Start to Quality - Five Important Test Support Practices, by Louise Tamres at StickyMinds.

To learn more about writing use cases: Writing Effective Use Cases, by Alistair Cockburn, Addison-Wesley 2001.