Why Requirements Should Be Tested - A Lesson in Quality Assurance

Software development teams may be accustomed to working with quality assurance (QA) teams at the end of the development cycle but there are many reasons to involve QA at the beginning of a project. One great reason is to let the QA team “test” the software requirements. Whether your software development team is following agile or waterfall processes, having a QA analyst test your requirements can mitigate the risks of misunderstood requirements and delivering software that does not meet the expectations of stakeholders.

QA team members are very good at questioning requirements because they must understand how to test all features. When testers question the requirements at the beginning of a project, they can reduce defects in the code.

Why test the requirements? Requirements can provide a starting point to discuss and solidify feature development. By “testing” or questioning the details of the functionality, the team can ensure that they are creating software that meets the correct requirements.

Here are some things to look for when testing requirements:

• Ambiguous Requirements: A tester can ask questions to flesh out details of the requirements. For example, a requirement might state, “as a new user I can create a secure password.” To test this requirement, you need to know specifically what the system will consider secure and what will not be secure. Are the users required to enter passwords of a certain length? Are certain characters required? Is the user restricted from using certain characters or words? Does your organization have a security / password policy that you need to follow? If questions are asked to confirm requirement details, developers will know what to code and testers will know what they need to test.
• Unnecessary Requirements: Requirements may detail functionality that is not necessary. As the project progresses, a requirement that once was valid may no longer be valid.
• Unwritten Requirements: Many requirements are unwritten or assumed. If the project team does not share the same assumptions, the team risks delivering a system that does not meet the requirements of the end users. Unwritten requirements often include non-functional requirements such as system performance, security issues, usability, accessibility, configuration, etc. Questioning these assumptions will get everyone on the same track. What if there are no written requirements? Have you ever heard, “I can’t test this because there are no requirements?” Even if there are no written requirements, there are still requirements! Testing or questioning the details around these unwritten requirements can resolve a lot of ambiguity. Agile teams do not always have the time to write all the details of the requirements. One of the principles of agile software development is “working software over comprehensive documentation.” Often agile teams will refine requirements via team meetings. It is crucial for QA teams to attend these meetings. Testing can serve as documentation of the required functionality when requirements are missing.
• Conflicting Requirements: Does a requirement conflict with another requirement. Maybe the requirements conflict with other information you have from the customer or another source.
• Testable requirements: How will you test this functionality? Are there data dependencies that could affect how you create your tests? How can you make sure that you have fulfilled this requirement? Another consideration for testable requirements is the timing of testing. Is there a test that depends on an overnight process or batch to run in the system? Consider security roles for users. Can any user access or use the functionality? Or is functionality restricted only to certain users. If so, which users can or cannot perform this functionality? If the team is planning on automating tests for a web-based application, do all the pages have a <title> tag and all objects and images have an ID or name that the automation tool will recognize? Do you have the right tools to test this requirement? For example, if the requirement is that the system must support 10,000 concurrent users, how will you verify this? If there is a requirement that the system must run on different browsers or mobile devices, do you have access to those browsers and devices? What versions of each browser will you need to test?

QA team members know how to test to make sure the customer’s requirements are met by using critical thinking skills, attention to detail, and curiosity. Testers can utilize these skills and techniques to help teams achieve consensus on project requirements.

By involving QA early in the software development process and “testing” the requirements QA can help the team do the right thing, the right way, the first time.

Editor’s Note: This blog was updated from its original post.