If you perform software testing as a software quality assurance (QA) engineer, you have to deal with many documents that are not all produced during your activities. This article discusses the software testing documentation that is important for software QA engineers, like the product requirements document or the user guide.
Author: Nataliia Syvynska, TestMatick, https://testmatick.com/
Usually, when we are talking about software testing documentation, we mean checking the requirements contained in a product requirements document (PRD) for completeness of content, consistency, and univocacy. But besides the traditional PRD, there are also a lot of various documents that are useful for different project stakeholders and that the software quality assurance engineers should check and verify. At the very least, they should be checked for errors.
Let’s start by analyzing the types of documentation used by Software QA Engineers and how to use them correctly. One way or another, a software tester needs to work with the following documents:
- Product requirements document;
- Client documentation;
- Examples of implementation;
- System documentation;
- Error messages;
- User guide.
Now, let’s take a look at each of these documents.
Product Requirements Document
It is the most important part of the documentation, both for a software tester and for everyone who takes part in a process of software development and software delivery. If there is a product requirements document on your software development project, it should always be checked for correctness. It is necessary to test both the PRD and the software for compliance with the product requirements document.
Client Documentation
Unlike the PRD, this is not a trivially described history of the client’s interaction with the system, but a whole “story”. Such a document contains data not only about the user, but also his/her requirements, desires, expectations from the product, etc. Client documentation can contain both examples of implementation and requirements.
Implementation Examples
You should always test examples! Since all users are different, lazy and not, if they want to see the system capabilities, they are not going to create their data but will simply test an example from the provided documentation or will use a sample file from the system.
Now, let’s see what we should call the implementation examples:
- An example file;
- Prefilled fields in the input form;
- Examples of calling API methods;
- Other examples.
System Documentation
It is a very important document, since modern software, on an ongoing basis, sends a user various notifications, congratulations, reminders, etc. Such letters are also documentation! What problems can occur there? It can be an incorrect display of headings or incorrect translation in the case of multilingualism. Additionally, there may be problems with dates: incorrect date of sending notifications, wrong logic of sending letters (before or after registration). Also, you shouldn’t forget about trivial spelling mistakes and other minor issues.
Error Messages
It is also a kind of documentation, just like the product requirements document. It is extremely important to process all possible negative scenarios to avoid system failure. Ideally, a user shouldn’t be able to make an error at all. For example, if there is a numeric input field, it shouldn’t allow typing letters or special symbols.
User Guide
If we are talking about public-domain software, the users will be working with it. There may be a lot of documentation on how to use the software before/after installation, as well as data on additional configuration of parameters, filters, etc. All these things take some time from the siftware QA engineers as well to clear documentation from inaccuracies, contradictions, and deliberately incorrect statements.
Conclusion
There are a lot of different of documents linked to a software development project! And it is not limited only to the requirements, bugs or test reports. You need to keep in mind each type of documentation when testing and delivering a project! Some good advice: draw up your checklist for testing the current documentation, since it affects a specific project anyway with which the QA department is currently interacting.