Testers' involvement in requirements gathering important

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 eli...

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Software Testing How to stop developer vs. tester, quality-killing blame game How to apply modeling techniques to support software testing Calculating mean time to failure in performance testing The lowdown on PCI compliance 5 ways to answer executives' unfair software test, QA questions 10 steps to acing Web app security assessments Three software regression testing steps can perfect defect fixes Exploring mobile layout testing, emulators and goals Preparing for testing applications in the cloud Hack maliciously to boost your software's security Software testing and quality assurance (QA) fundamentals Software Testing: New software testing technologies bring new challenges Testing strategies for complex environments Astronaut's STPCon advice: Teamwork delivers "The Right Stuff" How to make your software tamperproof Software consortium seeks standard quality metrics Demo: Using WebGoat, a free software testing tool Seven steps for a quality change and configuration management program Winning responses to "Why is QA always the bottleneck?" Where to find good methodology guides for software testing 5 ways to answer executives' unfair software test, QA questions Software Requirements Documentation VisibleThread aims to boost IT documentation quality, improve processes When it comes to requirements, what is 'just enough'? How to deliver, implement testable software requirements Blueprint rolls out Requirements Center 2010 Writing a software requirements specification (SRS) for a portal app Should QA check changes from outside the requirements document? Agile software development tutorial: Agile requirements gathering Defining requirements during software project feasibility analysis Template for requirements use cases What should a business analyst's requirements document include?

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary build  (SearchSoftwareQuality.com) code review  (SearchSoftwareQuality.com) conformance testing  (SearchSoftwareQuality.com) error handling  (SearchSoftwareQuality.com) garbage in, garbage out  (SearchSoftwareQuality.com) load testing  (SearchSoftwareQuality.com) NUnit  (SearchSoftwareQuality.com) quality assurance  (SearchSoftwareQuality.com) stress testing  (SearchSoftwareQuality.com) white box  (SearchSoftwareQuality.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

citation 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.

Rate this Tip To rate tips, you must be a member of SearchSoftwareQuality.com. Register now to start rating these tips. Log in if you are already a member. Submit a Tip DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.