Requirements Analysis for QA

Precision and clarity 

You can start testing requirements with a superficial inspection of the documentation. It is difficult to call it testing, but quite often already at this stage, many shortcomings are revealed. Let’s start with the usual scenario. You started reading the requirements and already from the first lines, you have a lot of questions for the author (for example, “What is the expected result after clicking this button?” or “What happens if I cancel the order?”). This is bad. After reading the documentation, there should be no questions. At all. Requirements are like a code of laws for a product, and laws do not allow ambiguity, “water” and inaccuracies. The documentation should give extremely clear information about how each individual module and the entire product should work. Unfortunately, after reading most of the requirements, a number of questions remain.

Example. In the requirements it was written: “Alphabets and numbers can be entered in the “Username” field.” The developer began asking the analyst which letters (Cyrillic, Latin or Arabic) and which numbers (integer, fractional, Roman) are meant. After clarifying the requirements, the developer implemented the functionality according to the analyst’s comments. The issue has been moved to testing. The tester did not understand what criteria to check this field by, and also began to ask the analyst.

Effects: 

• Spent time of several team members. 
• The discrepancy between the final and originally planned functionality. 

How to test: 

• If you still have questions after reading the requirements, revision is necessary. 
• If developers often clarify details in chats, this is a bad sign.

 Further, (“deeper”) research requires much more time.

Relevance 

The need to keep requirements up to date seems obvious. However, on some projects, the requirements are not updated for months or even years. This may be due to the fact that there is no analyst in the state, and the employee who performs his duties simply does not have enough time. Another thing happens: the requirements are updated only if there are really significant changes, while various “little things”, in the form of changing buttons or texts, are ignored.

Example. It was decided to change the position of the buttons on the authorization page. The analyst did not edit the documentation but wrote a personal message to the developer with a request to correct the location of the buttons. The developer made changes and closed the issue. During the next regression testing, the tester decided that this was a defect and started a bug on it. Another developer returned the buttons to their original positions according to the documentation.

Effects: 

• The time of several team members is wasted. 
• The final position of the buttons does not match the expected result. 

How to test:

• If there are such messages in the team chat, you need to make sure that the updated requirements are documented. 
• It is necessary to compare the dates of updating the terms of reference and the explanatory note with the date of the last update of the requirements.

Logics 

As the name implies, the operation of the system must be logical. The user cannot change his profile settings or write a letter before he is authorized in the system. It sounds, again, elementary, but in projects with many clients or with complex logic, such errors are often made.

Example. In the mobile application, it became necessary to implement the functionality of the electronic signature of the document. The user was prompted to enter his data, after which they were automatically substituted into the document template. The application opened the document and offered to sign it. If the user understood that there were errors in the document, then he could no longer correct them: he only had the opportunity to sign this document. Closing the application or reinstalling it did not help – when the user logged into the account, the same document was immediately displayed for signature.

Effects: 

• The user is furious. 
• Further work with the account without contacting technical support is impossible. 

How to test: 

• Draw an approximate flowchart of the system in accordance with the requirements and make sure that there are no logical gaps in it. 
• Make sure that the required core functionality is described in the requirements. 
• Make sure that the interaction between the system modules is stated correctly.

Possible Scenarios 

The documentation should describe in detail both obvious and non-obvious uses of the system. The obvious (positive) options, for example, include entering the correct login/password pair. To non-obvious (negative) – entering an incorrect login / password pair or the absence of these data at all. 

Example. Often overlooked are such points as error texts, system behavior when the connection is lost, as well as handling errors associated with third-party services (for example, with payment).

Effects: 

• If the connection is lost, the system behaves incorrectly (no errors, freeze). 
• Error messages are not obvious. 
• In the worst case, reputational or financial losses are possible.

How to test: 

• Draw a block diagram of a separate module of the system, within which to designate all possible conditions and user actions. 
• Make sure that the requirements include a description of each possible case.

Integration 

It makes sense to highlight integration with third-party services since here you have to go beyond checking the documentation. Before starting development, analysts usually study the operation of a third-party system and then describe how this system interacts with the product being developed. In this case, the probability of an error is very high, since both analysts and representatives of a third-party service who consulted or wrote documentation can make mistakes.

Example. On the project, it was necessary to implement the possibility of authorization through a third-party service. The analyst mistakenly studied the outdated documentation of third-party service and described a deliberately non-working interaction scheme. The developers started work, in accordance with the finished scheme, but constantly received errors. They “interrogated” the analyst, who in a hurry called the technical support of third-party service and found out the reasons for the errors.

Effects: 

• Delay in the development of functionality for a week. 

How to test: 

• You must manually check that the third-party service processes all the necessary requests, in accordance with the described scheme. 
• Check whether the analyst has correctly and completely indicated all the information necessary for development.