https://www.techtarget.com/searchsoftwarequality/tip/Pros-and-cons-of-requirements-based-software-testing
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.
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:
Requirements testing confirms the software's functionality based on the requirements gathered at the beginning of a software project.
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:
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.
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.
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.
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.
25 Feb 2022