Quality assurance process consists of many stages: creating a test plan, writing test scenarios, automation, etc. However, the requirements stage is fundamental, and the quality of the product depends more on the thorough and deep elaboration of the task at the initial stage of its development.
Why is it important to focus specifically on working with requirements?In my opinion, the testing cycle can be compared to the famous testing pyramid.
One can observe a trend that with each level of the pyramid, the importance and complexity of testing increases. Mapping the stages of testing onto the classical testing pyramid, the foundation will be working with requirements.
As can be seen from the scheme, the basis of testing is a thorough and deep elaboration of the task requirements.
Working with requirements is important because:
- It is possible to identify incompleteness of requirements in the task.
- There is an opportunity to detect contradictions in the requirements.
- Working with requirements allows creating a basic checklist of checks.
The requirements checklist can be used by developers to validate the quality of the product at all stages of software development.
How to work more effectively with requirements?
I use Xmind, but you can use any other tool.
As an example, I want to present the requirements for a task. In this case, I have put together requirements for the Reporter App — an application that allows managing Qase reporters and also performs actions on behalf of the reporter:
- As a user, I can install reporters on the Apps page.
- As a user, I can create API token.
- As a user, I can launch Qase reporter by using API token.
- As a user, I can remove API token.
Here’s how I transfer use cases to Xmind:
It is already possible to identify the entities with which the Reporter App will be interconnected, as well as actions with them.
The next step is to extract the actions with the entities into a map:
Now it is possible to identify connections between elements in the form of a mini state-diagram, where there is an entry point for the user and an exit point, as well as actions that take place between objects.
At this step, deficiencies and contradictions in the requirements can be easily determined. Let's examine an example.
From the list of requirements, it is clear that we have the installation of the Reporter App, but if the user no longer wants to use our reporter, then it should be removed. However, this is not provided for in our requirements.
Also, some questions arise: what reporters can the user install? How many of them? Can the user install multiple apps within the same programming language?
We can include all these questions in the diagram, and there may be more or fewer questions, depending on your requirements.
After compiling the list of questions, they should be discussed within the team. It is crucial to add the collected answers to the diagram as well as document them: these answers are implicit requirements for the feature!
Answers to the collected questions form a basic checklist for the feature, which can be discussed with the developers. The team can familiarize themselves with this checklist and also expand the list of checks or exclude unnecessary items. Then this checklist can be used both in testing and development.
In conclusion, I would like to outline the stages of working with requirements:
- Collection of requirements.
- Identification of entities and actions, marking connections between them.
- Identifying deficiencies and contradictions in the requirements.
- Collecting questions and coming up with answers.
- Creating a basic checklist based on the requirements and collected answers.
Remember the Boehm's Curve: the earlier an error is detected, the cheaper the cost of its correction. This is precisely why it is essential to identify deficiencies in technical requirements at an early stage of software implementation.
