Key Concepts of Requirements Testing

Hi all! Throughout my work experience as a QA engineer, I’ve explored various approaches to enhance team outcomes by refining the quality assurance process for projects. Today, I’d like to discuss one fundamental and crucial rule of software testing: The significant contribution of QA begins with requirements verification.

What are Product Requirements?

A requirement is a specification of what needs to be implemented. It outlines the system’s behavior and attributes.

The process of requirements specification holds immense significance within the requirements development journey. It stands as the third phase, succeeding requirement collection and analysis, managed by roles such as Business Analysts, System Analysts, and Product Designers, varying from project to project.

The goal is to produce requirements document or specification with appropriate details. This document will contain all requirements for the design, verification, and maintenance of the product.

Requirements — the first thing the project team looks at is the foundation for product design and development.

Requirements serve as the cornerstone, laying the foundation for product design and development. Any flaw or inaccuracy in documentation can emerge at the most inopportune juncture. Steve McConnell, in his book “How Much Does a Software Project Cost,” indicates that about 30% of errors are introduced into the product when developing requirements.

Obviously, it is much easier and cheaper to fix a defect in a couple of lines of requirements than to revise several hundred (or even thousands) lines of code later.

Why is Requirements Testing Important?

Requirements testing is a necessary and very important procedure that help optimize the work of the team and avoid misunderstandings and also allows you to understand whether these requirements can be met in terms of time, resources, and budget.

The quality of the generated requirements depends on the quality of the software. Requirements form the product’s blueprint. They drive test cases, revealing defects where the product diverges from these specs. Issues highlight contradictions, guiding corrective actions.

In connection with the above, when developing software, testing must be performed already at the stage of developing the specification. Requirements testing is aimed at eliminating the maximum possible number of errors at the initial stages of system design. In the long term, this allows:

• To establish mutual understanding when creating a product between team members.
• Significantly reduce the cost of product development and testing.
• Reduce the risk of receiving a product that does not meet customer expectations or end-user needs.
• Improve product quality.
• Reduce the delivery time of the finished product.

What happens if requirements testing is avoided?

• Difficulties arise during the development process.
• Issues in the requirements will be found after development:

1. By testers at the testing stage.
2. By users after release to production.

Fixing such issues can be expensive and sometimes impossible.

• Customers and end-users are not satisfied with the implemented user experience.
• Developers will spend more time trying to clarify details and come up with solutions to fit the missing requirements into the system.

Key features of good requirements

Each project has its own requirements — in some projects it can be multi-page documents, and in others only a user story or a minimal description of what needs to be done. Therefore, testing requirements will also be different. Hence, rely on the requirements quality criteria and choose what is important for your project.

The key features of good requirements are:

• Completeness. Is everything described? Haven’t forgotten anything? What if we still have undescribed functionality or user case? The documentation should provide the clearest possible information about how each individual module and the entire product should work. After reading the documentation, there should be no questions, but in practice, a large number of shortcomings are revealed.
• Correctness and Coherence. All statements should be correct and truthful and make sense.
• Consistency. Requirements should not contradict themselves. This usually happens when there are many requirements. The analyst simply forgets that he has already written about the parameter and again comes up with its behavior. Sometimes he comes up with something a little different.
• Clearness. Requirements should be transparent and clear for everyone, with only one interpretation possible.
• Testability. Can this functionality be tested? Think about it ahead of time. And it happens that the developer has already done everything, and then only the tester understands that the task cannot be checked in any way. Or you can check it manually, but you can’t write autotests, the framework for the new functionality is not sharpened. If everything in a company becomes autotests by detection, then this is a problem.
• Traceability. A requirement fully or partially compiles with business needs as stated by the stakeholders and is documented.
• Atomicity. A requirement can’t be divided into several more detailed requirements without losing completeness.
• Feasibility. A requirement can be realized within the given project.
• Relevance. A requirement hasn’t become obsolete after time has passed.
• Modifiability.
• Ordered by importance, sustainability, and urgency.

Basic principles of requirements testing

• Requirements testing is best done before development starts. To do this, you need to calculate the required time for verification and freeze the tested documentation until the end of the verification.
• Everyone on the team can help to conduct requirements testing. However, to achieve the best result, the description and verification of requirements should be entrusted to different people. For example, during the sprint refinement.
• Reporting documentation defects is no different from reporting product defects: bugs should be reported to the bug tracking system as usual.
• In the case when the requirements check is carried out in parallel with the development, it is highly desirable to warn the development team about the defects found (so that they can fix the error in time).
• The level of detail of the requirements (as well as the depth of testing) strongly depends on the level of the project. It makes no sense to check the response time to a button on a project that has just started (unless, of course, this applies to key functionality).

Requirements testing techniques

• Mutual review:

1. Skimming.
2. Technical review.
3. Formal inspection.

• Questions.
• Writing the test cases and checklists.
• Study of system behavior.
• Drawings.
• Prototyping.

Requirements testing ideas

Completeness

To check for completeness of requirements:

1. Check each object against CRUDL (Create, Read, Update, Delete (or Deactivate), List).
2. Think about what could go wrong, and what negative scenarios and boundary conditions could be (use cases).
3. Check that in complex if-then conditions, all options are described (decision table).

Correctness

If the requirement is correct, then it does not contain wrong and inaccurate information. This criterion is usually difficult to test. It helps when the requirements are tested by a person who is well-versed in the subject area.

Consistency

When checking for consistency, pay attention to:

1. The same requirement is written several times in different places — if you change it, you will most likely forget it somewhere.
2. The union “and” for requirements is several different requirements and they may contradict each other. For example, “fast, good, and cheap.”

Clearness

All team members must understand the requirements unambiguously:

1. Terminology — everyone should understand what is behind each concept. The same things should be called the same concept.
2. Qualitative definitions — “beautiful”, “convenient”, and “fast”. Such requirements should be replaced with specific parameters so that everyone understands how to check them.
3. The requirements are written in simple language — it is clear “who does what.”

Testability/Verifiability

One of the most important criteria is verifiability. How do you know that a requirement has been met? How will you know that the project as a whole is successful? If a requirement doesn’t have a test case, or you can’t come up with a test right away, it’s a bad requirement. For example, you can check the user story:

1. Acceptance criteria are present in the user story.
2. Acceptance criteria are accurate and unambiguous.
3. QA Engineer can write a checklist or test cases for this user story.

Feasibility

When you check the feasibility of the requirements, look at whether it can be done at all within the existing restrictions. Usually, the QA Engineers do it together with developers, since the second has deeper technical expertise.