Algorithms of Work with Technical Documentation
Algorithms of Work with Technical Documentation
Every tester, one way or another, is familiar with all the nuances of early testing when he honestly reviews the stated requirements, architectural designs, and the rest of the documents. Also, he focuses on finding incomplete descriptions, and instructions that can lead to bugs and unanswered questions.
Because of all of the above, it can sometimes be extremely difficult to focus on testing documentation, especially when it comes to collective review. The following are some basics of review that can be used to structure the review process in a convenient format.
Algorithm Used to Test Documentation
So, as we know, any testing life cycle includes:
- Preparations and planning processes;
- Designing all tests;
- Tests execution;
- Writing reports;
- Final actions (optional).
Reviewing technical documentation is just like software test services, but with its peculiarities. Hence, it has a special algorithm for its implementation.
- Preparation of the document. Why is it created? What information exactly should it contain? What group of additional information should be there? Adding generally available examples from the Internet.
- Work on the checklist: add common requirements of your company, find best practices from the global network, and optionally add a list of potential bugs (which can harm the product development process).
- Conduct a review: test the implementation of all items on the checklist; identify lists of bugs and recommendations for technical improvement; rank in order of priority and criticality.
As a result of working with the document, it can be considered successfully closed, if there are no more than 2-3 minor comments in the content that do not affect the overall behavior of the system. If you constantly and monotonously “improve” the document, you risk wasting precious time on the testing. The more correctly and completely the technical documentation is described, the more effectively it can be used as a template for future projects and tasks. And don’t forget that any review has some subjective moments. In other words, some critical bug for you may be an acceptable feature for someone else.
