In this increasingly complex software development era, it is extremely important to include testing as early in the project as possible. In the predictable old waterfall lifecycle world, testing was typically included in the coding phase right before they were needed. In today's iterative world, testing needs to be included at the project's inception.
Even today the requirements phase of a project generates most of the defects. Over 50% of the defects are injected during the requirements phase. This is important because this phase forms the foundation for the product that future work will be built on. So, if the requirements are not correct, there may be fundamental issues that do not surface until the later phases. And that may mean having to completely redesign major portions of the product. The amount of rework to fix assumptions or undiscovered issues can have a significant impact on a project.
Let's first look at what can happen when testers are involved during the later phases of development.
- Testers' understanding on the requirements is limited and tests designed aren't robust.
- Requirements defects get carried on to next phase due to the insufficient review process.
- Testers are forced to learn the application on the fly from the requirements.
- The risk analysis on the requirements are skipped, and the tests designed may not be of adequate coverage.
- Requirements-based testing gets skipped and most of the ambiguous, inconsistent and immeasurable requirements are not corrected.
- Traceability, relationships, correlation and dependency in requirements are not traced.
- Rapidly accelerated project cycles result in many requirement gray areas that force testers to determine expected results.
The above issues convey the need for testing to be active participants in the requirements elicitation process. Testers should not be passive recipients of requirements in the form of a use case or a requirements document.
The benefits of involving testing in the requirements elicitation process (such as requirement workshops, review sessions, interviews, etc.) include the following:
- The test plan will include more than a regurgitation of the project features. By understanding the requirements as they are being created, the test plan will include a better plan of attack for testing each of the areas of functionality.
- As the project progresses, testing will typically be asked to refine their resource estimates. Understanding the requirements as they are being created will help refine resource estimates with greater confidence. Even if test cases are not yet developed, you can get a sense of the number of requirements and estimate the necessary number of test cases and multiply by your time factor to create and execute test cases.
- You will end up with clearer, concise requirements. For example, is the requirement test-able? Another example is clarifying the gray area requirements that frequently get overlooked, such as error messages and usability issues.
- Testers can capture the feelings about certain requirements that they cannot get from an after-the-fact requirements review. Feelings are not captured as requirement attributes. Testers can also hear about how development feels about certain requirements. This dichotomy is essential for risk-based testing. If you don't have enough time to test the entire system, test efforts may focus on the following:
- Requirements that are important to the business (high priority)
- Requirements that make development uneasy (high risk).
- Testers may better understand the impact of the requirement on other parts of the system. Participation from testing in requirements elicitation sessions may result in fewer changing requirements throughout the project and fewer design problems.
- Testers can get a jump-start on test case creation. They may be able to create several tests with steps from basic flows of a use case. This preparation may allow time later on to automate between iteration releases.
- Testers can better set test cases to business requirement traceability.
- Part of the role of Testing is to ensure that projects adhere to the software development process that the organization has in place. Requirements elicitation is a distinct activity, and testing should ensure that it is performed and that it is performed correctly.
If testing passively waits until requirements are published, it may already be too late. The time needed to then learn, question and understand the requirements eats into precious time necessary for test plan and manual/automated test case development.
If your organization already includes testers in requirements elicitation, keep up the good work. If not, help the leaders understand the importance of early involvement and the value-add that testing gives this activity. The benefits far outweigh the costs.
