Where requirements-based tests fit in software testing
Requirements-based testing has its upsides and downsides, and it's not right for every software project. But certain dev teams should still adopt the method. Learn which ones.
Requirements-based testing is a preliminary test strategy used to validate system requirements. It was popularized in the early years of software development, particularly within development teams that used Waterfall methods.
Waterfall dates to the 1970s and uses a linear, stage-based approach to software design. The first stage involves requirements gathering and documentation. The requirements from this stage also serve as the test cases for requirements-based testing.
In more recent years, development teams have moved away from Waterfall to Agile software development, a more iterative approach with a less requirement-heavy planning stage. This has also contributed to development teams' move away from requirements-based testing and towards more Agile-compatible methods.
Examine the intricacies of requirements-based testing and whether the method is still helpful in current software development practices.
What is requirements-based testing?
It ensures that everything specified in the requirements stage is accounted for and tested before the software is delivered. It covers both functional and non-functional software requirements outlined in the requirements stage.
An example functional requirement might be, "The system shall allow a user to delete their account." With that requirement, a developer can run a test case by creating an account and testing to see if the user can delete that account.
Nonfunctional requirements are equally important to test. Some nonfunctional requirements to test include the following:
If the system can handle the expected load.
How quickly a user can complete an action within the system.
How quickly the system can process and return data.
Requirements testing confirms the software's functionality based on the requirements gathered at the beginning of a software project.
Stages of requirements-based testing
Requirements-based testing involves several general steps, which might vary slightly from team to team. The steps involved in requirements-based testing are as follows:
Define test completion criteria. Development teams create a definition of done based on the requirements laid out in the planning stage. Testing is complete when software meets this definition.
Design test cases. Teams design test cases based on the definition of being done, initial system state, system inputs, expected outcomes and actual outcomes.
Build and execute tests. Teams build the test cases by integrating the necessary data and system components, then execute those tests and document the results.
Verify test results and coverage. Teams compare test results to expected results and note any discrepancies. They also ensure that tests cover both functional and non-functional software requirements.
Monitor defects. Teams track any defects that arise during testing and monitor them up to their resolution.
Importance of requirements-based testing today
Agile processes such as Scrum, sprint and planning poker have largely replaced requirements-based testing in modern software development because of the move away from a Waterfall approach.
Waterfall encourages strict deadlines and well-defined, concrete stages that feed into one another. In contrast, Agile focuses on providing customer value earlier in the development process and shrugs off any notion of a requirement-heavy planning stage. Agile defines only a minimum set of requirements to get something in front of the customer as quickly as possible.
When compared to a detailed requirements-heavy outline in Waterfall, development teams use requirements-based testing much less often now. Testing with user stories presents a more flexible and adaptable alternative to requirements-based testing.
Pros and cons of requirements-based testing
Despite the move away from requirements-based testing, the approach has its benefits and disadvantages.
In Waterfall, requirements-based testing has the advantage of being well-defined and time-boxed, which makes testing easier to plan. Developers can use their knowledge of the number of requirements that define the test suite to more accurately estimate how long it will take to test the software. In the same way, it's easier to design tests when developers know about the explicitly defined requirements from the early stages of a Waterfall project. If testers map tests back to a project's requirements using a software requirements document, they can conceivably measure test coverage. Requirements-based tests also tend to produce logical and well-defined output.
Requirements-based testing, however, can easily miss important elements of software quality if the requirements aren't carefully defined. Requirements such as "software should be intuitive to use" or "the system should be secure" need to include a lot more detail to accurately design tests. Instead, vague requirements like this are typically more appropriate for manual exploratory testing.
As such, teams can turn to exploratory testing to prevent headaches associated with detailed, strict requirements. Often, teams can better understand software when they put the software system in front of a user and observe their behaviors during certain use cases.
Are requirements-based tests right for your project?
Output is one of the most important factors that developers should consider when they contemplate requirements-based testing for their software projects. These tests generate a logical and well-defined output that a team can map to requirements. The tests pass or fail depending on whether the software meets the given requirement.
If the project has customers that require highly specific needs and detailed documentation, requirements-based testing may fit the bill to evaluate the system's success.
Other types of testing, such as exploratory testing, are much more open-ended. With exploratory testing, there are still certain test goals, but there often aren't specific requirements for testers to refer to. For example, a tester's goal might be to break a system with a bad input. In an exploratory session for this scenario, the tester would try to press buttons many times and enter unexpected inputs. An exploratory session wouldn't generate test results that you would see if you ran a requirements-based test suite. But it might be an easier way to find and document bugs within a system than stricter requirements-based testing.
Other types of tests can enable a team to move quicker and release more features. However, the detailed results from requirements-based testing can be useful for project stakeholders to quickly understand a project's status and remaining timeline.
Requirements-based testing might be a bit dated, but it's still worth consideration. If the project's customers have highly specific needs that warrant detailed documentation, requirements-based testing might be the right approach. If the project is more open-ended, with iteratively designed systems that prioritize agility and quick delivery, then requirements-based tests might not be appropriate.
Matthew Grasberger is a DevOps engineer. He has experience in test automation, DevOps engineering, security automation and open source mobile testing frameworks.
