Opinov8 is a fast-growing company, and we, Opino8rs, are proud of it! We are always thinking about our future, our growth, and our customers — how could we provide the best service? Obviously, to achieve these goals, we must build strong and scalable processes. Requirements testing is one of them.

Today, we are going to talk with Vadym, Opinov8 QA Practice Lead. Vadym will tell us about one of the processes implemented in Opinov8 — requirements testing. This is a basic and mandatory process for all our projects.

Vadym Krykhno, QA Practice Lead

• 13 years in QA, experience in building QA teams, and QA practice from scratch. 
• More than 7 years of expertise in Automation in different languages. 
• Worked with many global companies in e-commerce, finance, CRM, game, and other domains. 

As you know, requirements are the foundation for any development project.  Projects start with documentation (requirements) and end with it. One of the most vital processes for us is requirements testing. In Opinov8 (for a project with SDLC based on Scrum), we created a few rules when implemented this approach:

• What? — Requirements testing is a process;
• Who? — QA engineers;
• What does a QA engineer do? — Have the ability to return requirements for revision; 
• When? — Before these requirements get into the backlog of the future sprint.

We need to test the requirements exactly before these requirements are added to the sprint backlog. On the other hand, it is not necessary to perform these actions at a very early stage because there is a possibility that these requirements will lose their relevance.

Requirements testing before sprint as a process allows us to:

• Reduce the number of meetings (grooming, planning) or the duration of these meetings for the entire development team;
• Reduce development time (as everyone understands what exactly needs to be developed, the number of improvements or change requests will be reduced as well);
• Reduce the number of defects (as we have clearer and more understandable acceptance criteria);
• Reduce the number of conflicts due to unclear or flexible requirements;
• Predict possible changes in requirements. This allows us to more accurately plan our tasks and activities in the sprint.

As a result, we can significantly reduce the cost of the project (or sprint, since we are talking about testing requirements as a sprint activity).

How exactly to test the requirements?

Our Business Analysts use a requirements approach based on the INVEST mnemonics described here. However, from the QA practice side, when we do Requirements Testing, we also stick to the following aspects:

1. Correctness.

All statements must be correct, truthful, and make sense. Testing a system for incorrect requirements is a waste of time, money, and effort. How correct is your requirement? Is this really what is required of the system?

2. Necessary. 

Can be traced back to the business problem or business need that triggers it. Does this really cover the needs of the business?

3. Completeness. 

The requirement should contain all the information needed by the developers and everyone else who uses it to do their job. The requirement must include all the details necessary to express the needs of the users.

4. Consistency. 

Requirements must not conflict with other requirements. Are all buttons or error messages in the same style?

5. Testability. 

There must be a way to check if the implementation meets the requirements. Can the requirements be verified? How do you do this, and what data and tools do you need?

6. Logic. 

Is it possible to develop the described functions, we do not have blockers and restrictions?

7. Unambiguous. 

Anyone who reads the requirement must come to a common interpretation.

8. Traceable. 

Is the requirement unambiguously defined so that it can be unambiguously referred to?

9. All possible scenarios. 

Are all scenarios covered in the requirements?

Requirements testing is a top priority to help you get your developing project to a really good level. Timely use of these activities can save the development team time and money.

If you wanna join our super-friendly QA team, don’t hesitate to check our open positions or send your CV to [email protected]