Testing the Requirements: A Guide to Requirements Analysis
I have asked a lot of colleagues, “Do you test your requirements?” All of them reply, “Of course.” But when I ask, “How exactly do you test your requirements?” no one can answer that. Everyone knows testing requirements is important, and everyone says they do it, but no one knows exactly how.
The best way to solve this problem is to introduce a requirements analysis stage that has to be done before coding starts. No one knows a product as well as a tester who works with it every day, so it’s a good idea to have QA check all the requirements specifications, wireframes, and mockups.
The mnemonic I use for what to look for is the four C’s and one T: completeness, clearness, correctness, consistency, and testability.
- Check that all possible scenarios have been considered in a requirement, and try to find any gaps or uncovered cases
- Check that all statements are correct, truthful, and logical
- Try to find all ambiguities in requirements (only generally accepted terms should be used)
- Uncover contradictions with other requirements and with internal and external standards
- See if there is a way to check whether implementation meets a requirement
To make testing requirements more effective, you can use the approach called heuristics testing, or testing with a strategy that relies on past data about probabilities. This targeted type of testing often allows for more intelligent investigation of where any bugs or problems may occur, even in requirements testing.
This strategy helps determine what types of errors are likely and how common errors occur in certain parts of the code. It also helps to check requirements against an accumulated base of problems. Be sure to cover all these areas in your app:
Structure (what the product is): Is it one program or many? What physical parts come with it? Can I test it module by module?
Function (what the product does): What are its functions? What kind of error handling does it do? What kind of user interface does it have? Does it do anything that is not visible to the user? How does it interface with the operating system?
Data (what it processes): What kinds of input does it process? What does its output look like? What kinds of modes or states can it be in? Does it come packaged with preset data? Is any of its input sensitive to timing or sequencing?
Platform (what it depends on): What operating systems does it run on? Does the environment have to be configured in any special way? Does it depend on third-party components?
Operations (how it will be used): Who will use it? Where and how will they use it? What will they use it for? Are there certain things that users are more likely to do? Is there user data that would make the tests more realistic?
You can invent your own heuristics and apply them to the whole application as well as to requirements analysis.
Good requirements should be clear and precise, with no uncertainty or ambiguity; should be measurable in terms of specific values; should be testable and complete; and shouldn’t contain any contradictions.
Evgeny Tkachenko is presenting the session The Four Cs and One T of Requirements “Testing” at the STAREAST 2018 conference, April 29–May 4 in Orlando, FL.
