Testing is a document

Documents must be comprehensive, updated in real time, and easy to understand. All I said is that apart from introducing the functions of the program, it should also cover some important aspects of the Code. For many people, the importance of documents is self-evident, but it is difficult to maintain its timeliness and accuracy. The consequences of poor documents are usually a waste of resources and time. Documents are often written for some errors.
　　Reasons for the requirement document
There are many reasons for writing documents. Teams often write documents due to institutional requirements, or simply out of ignorance. The following are some reasons for document writing errors:
Some people think that documents are closely related to project success or failure.
This document can prove the existence of some people.
The demand side does not know what to do except the document.
If you want to provide documents, you just need to feel at ease and know that everything is okay.
The workflow prompts you to create a document.
All documents are outdated
A major problem with software documentation is that it is generally not up-to-date. Some part of the Code may be modified, but the document does not reflect this situation. This statement applies to almost all documents. The most influential ones are the requirements and test cases. No matter how hard you work, document expiration is inevitable.
　　Who is the document useful?
The document type and format vary depending on different audiences. Developers, testers, customers, supervisors, and end users are the largest potential users of documents.
　Developers
Developers should not rely on documents because they are usually outdated. In addition, no document can provide more detailed and up-to-date information than the Code itself. If you want to know what a method has done, read this method. Not sure what a class is doing? Take a look at it. Generally, you need to add a document to the code when the code is too poorly written.
Using the Code itself as a document does not mean that other documents are not needed. The key is to avoid redundancy. If you can see the code to obtain detailed information about the system, you can also have some other documents to provide quick guidance and an overview at a higher level. The document of the Code itself cannot answer the question about what the system is or what technology the system uses. In most cases, a simple readme. md is enough for developers to get started quickly. Such items as project description, Environment configuration, installation, build and Packaging Commands are very useful to new members of the project. But then the code is your Bible. The product code provides all the required details, and the test code is a description of the internal intent of the product code. Test Cases are Executable documents, while TDD (test-driven development) is the most common way to implement it.
Assume that you have used a continuous integration method. If some of the errors in the test-document (here the test is the document, and the document is also the test) are incorrect, the routine execution fails, it will be repaired soon. Continuous integration solves the problem of incorrect test-documentation, but it cannot ensure that all functions are documented. For this reason (of course there are other reasons) test-the document should be created using TDD. If all functions are defined as test cases before code development, the test cases can be used as a complete and up-to-date document for developers.
What about other members of the team? Testers, customers, supervisors, and other non-coders may not be able to obtain the required information from the product and test code.
.......
This article is transferred from 51testing Software Testing Network