Writing test documentation is similar to writing any other type of documentation. The most important thing is to make it easy for both writer and reader 🧐 Clear instructions are imperative, as interruptions or confusion can lead to mistakes resulting in very expensive problems.
This list is pretty comprehensive, but you may find that some items do not apply to your application’s needs, so don’t be afraid to customize it for your specific application.
Must-haves in Test Documentation – Table of contents
- What documentation does a QA expect from a developer?
- What every test documentation should have
- Basic documents for a meaningful documentation
- What does a test report template contain?
- Good habits of maintaining test documentation
- Conclusion
1) What documentation does a QA expect from a developer?
Before a tester begins testing, they need some documentation from developers on how the application is supposed to work and after interpreting them. Every tester should document the test’s starting conditions and expected results. Documents such as:
- Software requirements spec: The requirements document is a detailed description of what is required. You can learn about the business requirements for the software in order to clarify the user’s needs.
- Technical specifications doc: Programmers are required to write detailed documents of processes, algorithms, code formats, etc. These are useful for QA engineers in the testing process.
Proper documentation serves the purpose to outline some common methods for ensuring that test steps and results are clear and unambiguous and that time gaps between steps can be pinpointed.
Everyone involved in testing (testers, developers, project managers) can benefit from a well-defined style guide for tests (and other documents) ✅ A style guide ensures consistency across all documents, making them easier to read. This is especially helpful when multiple people work together on a project long-term.
2) What every test documentation should have
- Include a glossary on the first page of documentation, so users know what terms mean suffixes, etc.
- Make the documentation localizable with a template – that should be available to the entire team.
- Include a test directory. This will require a set of scripts/scripts config files and the use of a database to keep track of tests.
- Include code snippets in the documentation.
3) Basic documents for a meaningful documentation
One must understand what the application is supposed to do in order to write a good test documentation. Test documentation should also include test case coverage, if possible. Let’s have a look at the important documents that help to achieve this goal:
Test Plan
The test plan is a simple plan which has the following parts:
- Purpose: For what purpose is the test plan valid? It is essential as it notifies whether this test plan will be valid from the development stage to the production stage.
- Strategy: How to perform testing? This part is very important as it provides a structure to the test plan.
- Ground Rules: This should be the main part of the test plan as it is impractical for testers or developers to apply test cases without any strategy.
Test Cases
The test cases are the most important section that every tester should understand 🔎 The ground rules apply to each test case listed here. In addition, test cases contain information like how many times a step needs to be repeated, how many options are there, what kind of conditions are there, what kind of data you need to use, etc.
Also, this section includes a flowchart for each step in testing or programing data processing system or software application, etc. which shows each step clearly.
A test case is a list of steps that need to be performed in order to verify whether an application works properly under specified circumstances. Each test case is designed for a specific set of the development environments where the desired functionality needs to be verified against defects or bugs in the tested application.
Meaningful test cases must have the following : test case number, test description, test procedures/replication steps, test prerequisites, acceptance criteria, results, comments, duration, and priority.
Test Reports
A test report is a summary of all test cases that have run in a given period of time 📜 Let’s discuss test cases and test reports and why they are important.
The main purpose of a test report is to make an easily understandable and accessible document to facilitate a quick and efficient understanding of the project’s current status.
4) What does a test report template contain?
- Software version: System used for testing (application name/version), test case, test results, and pass/fail information for each test case.
- Automated tests: What are the percentages of automated vs manual tests? Will they be automated in the future?
- Defects: Fixed by developers with details about the defect (show screenshots, logs, etc).
- Comments and clarifications: From developers and testers.
- Document history: Updates to the report.
- Test matrix: Any changes made to the requirements during testing.
- Defects logged: With screenshots or logs for each defect.
5) Good habits of maintaining test documentation
- Recording the exact input data used for a test run is important. It can be used to determine whether a defect has been introduced in the application during the previous test run- This helps the team choose what to fix.
- It’s a good habit for test scripts to be stored in the same file where the source code is stored.
A developer may write a testing plan according to their perspective of testing. In this case, when they have written their code, they expect that when testing against another developer or when using an automated test suite, that they will come across types of defects in their code because it has not been covered by a testing plan ❌
Conclusion
Having good test documentation is crucial, and it needs to be understandable by all team members, including the testers, the developers and the project managers. Ultimately, all test documentation has the same goal in mind: document what was done, what wasn’t done, and even why something wasn’t done.
All of this should be clear enough for other team members to make their own decisions on how the testing should be conducted or if any other testing should be conducted at all, before releasing software products or features into the wild 🏕