Where Does Requirements-Based Testing Fit Into Software Testing
Requirements-based testing is a preliminary testing strategy used to validate system requirements. It was popularized in the early years of software development, especially among development teams who used Waterfall methods.
Waterfall dates back to the 1970s and uses a linear, stepwise approach to software design. The first step involves gathering and documenting requirements. The requirements in this step also serve as test cases for requirements-based testing.
Let’s examine the intricacies of requirements-based testing and whether the method is still useful in today’s software development practices.
Requirements
In an application, an example of a functional requirement might be: “The system must allow a user to delete their account”. With this requirement, a developer can easily run a test case by creating an account and testing to see if the user can delete that account.
Non-functional requirements are equally important to test. Some non-functional requirements to test include:
- whether the system can handle the load;
- how quickly a user can perform an action in the system; and
- how quickly the system can process and return data.
Requirements testing confirms software functionality at a superficial level, based on the requirements gathered at the start of a software project.
Requirements-Based Testing Today
Agile processes such as Scrum, sprinting, and planning poker have largely replaced requirements-based testing in modern software development due to the abandonment of a waterfall approach.
Waterfall encourages strict deadlines and well-defined concrete steps that feed into each other, while Agile focuses on creating customer value earlier in the development process and ignores any notion of a demanding planning step. Agile only defines a minimum set of requirements to get something in front of the customer as quickly as possible.
Compared to a detailed, requirements-heavy plan in Waterfall, development teams use requirements-based testing much less often now.
Advantages and Disadvantages of Requirements-Based Testing
In Waterfall, requirements-based testing has the advantage of being well-defined and time-bound, which makes test planning easier. Developers can use their knowledge of the number of requirements that will define the test suite to more accurately estimate how long it will take to test the software. In the same way, it is easier to design tests when developers know the explicitly defined requirements from the early stages of a Waterfall project. So if testers map tests to requirements for a project (using a software requirements document), they can potentially measure test coverage.
However, requirements-based testing can easily miss important parts of software quality. For example, requirements may be too brief and struggle to capture important software design elements. Requirements, for example, that “the software is intuitive to use” or that “a system is secure” must be defined in great detail. Such requirements can often be more easily covered by a manual exploratory session.
So teams can turn to exploratory testing to avoid the headaches associated with detailed and stringent requirements. Often, a team’s understanding benefits from testers simply presenting the software system to a user and observing its behaviors during certain use cases.
Is requirements-based testing right for your project?
Output is one of the most important factors developers need to consider when considering requirements-based testing for their software project. These tests generate a logical, well-defined output that a team can map to requirements. The tests will pass or fail depending on whether the software meets the given requirement.
Other types of testing – such as exploratory testing – are much more open. When testing in an exploratory fashion, there are certain test goals, but there are often no specific requirements that testers can refer to. For example, a tester’s goal may be to break a system with bad input. In an exploratory session for this scenario, the tester would try to press buttons multiple times and enter unexpected inputs. An exploratory session would not generate test results that you would see if you were running a test suite, but it can be an easier way to find and document bugs in a system than tests based on more stringent requirements.
Other types of testing can allow a team to move faster and release more features, but the detailed results of requirements-based testing can be useful for project stakeholders to quickly understand the status of a project. project and the remaining schedule.
Requirements-based testing might be a little dated, but it’s still worth your attention. If the project has customers who strongly require specific needs and detailed documentation, requirements-based testing may be appropriate to assess the success of the system. If your project is more open and has iteratively designed systems that prioritize agility and customer delivery, requirements-based testing won’t be the right way to go.
