There are many other requirements for writing and testing documentation. Here, we will look at the most important ones. But the main rule that will always help is the ability to put yourself in the shoes of a user who has encountered a particular problem situation.
Basic principles of requirements testing
It is better to test requirements before development starts. To do this, it is necessary to calculate the time required for testing and to freeze the test documentation until the end of the test. Requirements testing can be done by both analysts and testers. However, for better results, requirements writing and testing should be assigned to different people.
Identifying defects through documentation isn't different from identifying defects through the product. Bugs should be entered into the bug-tracking system as usual. In the case where requirements checking is done in parallel with development, it is highly desirable to alert the development team about the defects. The level of detail in the requirements depends heavily on the level of the project. It makes no sense to check the response time of a button in a project that has just started.
Requirements testing techniques
Testing of documentation and requirements are categorized as non-functional testing. The main technique of such requirements testing in the context of testing is peer review. It is one of the most widely used requirements testing techniques and can take one of the following three forms (as it gets more complex and expensive):
Review. Can take the form of either an author showing their work to their peers to create a shared understanding and get feedback, or simply sharing the results of the work between two or more authors for a colleague to raise questions and comments. This is the quickest, cheapest and most commonly used type of review. As a reminder, the analogy to a review is when you and your classmates used to check each other's essays for typos and mistakes before handing them in at school.
Technical review. Carried out by a team of specialists. Ideally, each specialist should represent a different area of expertise. The product under review cannot be considered to be of sufficient quality until at least one reviewer has comments. Developers, designers, analysts, testers, and other specialists from different fields are called into technical review product requirements.
Questions. If anything in the requirements makes you confused or suspicious, ask questions. You can ask the customer representatives or refer to reference information. Many questions can be asked of more experienced colleagues, provided they have the relevant information previously obtained from the client. The key is to formulate your question in such a way that the answer will improve the requirements.
In addition, there are several more requirements testing techniques. Test cases and checklists are a good requirement – they should be testable. You can use checklists or full test cases to determine this. If you can think of a few checklist items quickly, that's a good sign.
System behavior research is necessary to mentally simulate the process of the user's work with the system created according to the tested requirements and then to determine ambiguous variants of the system usage.
Drawings is a graphical representation that gives a visual representation of the application. In a drawing, it is easier to see that some elements do not fit together, something is missing somewhere, etc. For example, the behavior of the system in the case of user authorization can be described in dozens of pages of text. But if you have a clear and concise scheme, it can be described in 1-2 pages.
Prototyping. Having made sketches of the user interface, it is easy to evaluate the application of certain user solutions.
Conclusion
Requirements testing requires careful testing. This minimizes further misunderstandings and inconsistencies in the operation of the application and reduces labor costs for solving problems. With experience, you will assemble a useful set of test methods for yourself, which will allow you to quickly and efficiently test requirements.