If you work as a software quality assurance (QA) engineer, you have to deal with many documents that are not all produced during software testing activities. This article lists the 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 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 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 PRD on your 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.
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.
You should always test examples! Since all users are different, lazy and not, ii they want to see the system capabilities, they won’t 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.
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 either.
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 commit an error at all. For example, if there is a numeric input field, it shouldn’t allow typing letters or special symbols.
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 as well to clear documentation from inaccuracies, contradictions, and deliberately incorrect statements.
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.