Should Testing Be Involved in the Requirements Elicitation Process

Should Testing be Involved in the Requirements Elicitation Process?

In this increasingly complex software development era, it is extremely important to include QA / 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. Companies that are making the waterfall to iterative shift are questioning the added costs of introducing Testing earlier in the project. Project Managers are under increasing pressure to manage cost. It is not uncommon for testing to have to defend why they need to be included in early project meetings such as requirements elicitation (workshop) sessions. This paper summarizes responses to the commonly asked question, “Why should testing be included in early requirements elicitation sessions?”

Let’s first look at some of the pressures iterative development has on testing:

Releases to production are more frequent in iterative development. Thus, testing has less overall time than before to verify functionality.

This is complicated by the fact that iterative development is usually performed on an emerging complex technology that the tester is usually forced to learn “On the fly.”

The totally finished product in iterative development may be delivered only days before a production release.

Requirements are delivered piecemeal across several iterations, and pressure to automate regression tests for previously fulfilled requirements is intense.

Rapidly accelerated project cycles result in many requirement gray areas that force testers to determine expected results.

The above pressures 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. By involving testing in the requirements elicitation process (such as Requirement Workshops, JAD Sessions, Interviews, etc), Testing will benefit by 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.

The result of Testers attending requirements elicitation sessions will result in clearer, concise requirements. For example, is the requirement testable? Another example is clarifying the gray area requirements that frequently get overlooked, for example, Error Messages, Usability issues, etc.

Participation in requirements elicitation allows Testers to capture the feelings about certain requirements that Testers 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:

Requirements that are important to the business (high priority)

And

Requirements that make development uneasy (high risk).

While the Requirement Specialist’s role is to elicit requirements, 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.

Understanding the requirements can result in a jump-start on Test Case creation. You 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.

Understanding the requirements (and the interdependencies between requirements) will make it easier for Testing to set test case to business requirement traceability.

Part of the role of Testing / QA 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.

Kurt Derfler November 27, 2001