Testing is the document _ Test document

The document needs to be comprehensive, live updated, and understandable. All I'm saying is that in addition to the introduction of the program's functionality, you should cover some important parts of your 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 documentation often waste more resources and time. Often, documents are written for some wrong reasons.
Some reasons for asking for documents
There are a number of reasons why we need to write a document. Teams often write documents because of institutional requirements, or simply out of ignorance. Here are some reasons to write a document incorrectly:
Some people think that the success of documents and projects is closely related.
Documents can prove the existence of some people.
The demand side doesn't know what to do except the document.
The person who wants you to provide the document is to ask for reassurance, knowing that everything is OK.
Workflow Tip says you should create a document
The documents are obsolete
One of the main problems with software documentation is that it's usually not up to date. Some part of the code may have changed, but the document doesn't show it. This applies to almost all documents, and the biggest impact is in fact requirements and test cases. No matter how hard you try, the expiration of the document is unavoidable.
Who the document is useful to.
Depending on the audience, the type and format of the document will vary accordingly. Developers, testers, customers, supervisors, and end users are the largest potential users of the document.
Development staff
Developers should not rely on documents because they are usually obsolete. In addition, there is no document that provides more detailed and up-to-date information than the code itself. If you want to know what a method is doing, look at the method. Not sure what a class is for. Take a peek at it. Typically, only the code is too poorly written to add documents to it.
Using the code itself as a document does not mean that no other documents are needed. The key is to avoid redundancy. If you can take a look at the code to get the details of the system, there are other documents to provide a quick guide and an overview of the higher level. The documentation for the code itself cannot answer the question of what the system is or what technology it is using. In most cases, a simple readme.md is enough for a developer to get started quickly. Things like project description, environment configuration, installation, build, and package directives are very useful for new members of the project. But after that, the code is your Bible. The product Code provides all the details that are required, and the test code is a description of the intrinsic intent of the product code. The test case is the executable document, and TDD (test-driven development) is the most common way to implement it.
Let's say you're using some kind of continuous integration, and if a test-document (where the test is a document, the document is a test) is partially incorrect, the session fails and it will be repaired quickly. Continuous integration solves the problem of testing-incorrect documentation, but it does not guarantee that all features are documented. For this reason (and of course there are other reasons) testing-documents should be created in a TDD way. If all of the functionality is defined as a test case before the code is developed, the test case can be a complete and up-to-date document for the developer.
What about the other members of the team? Testers, customers, supervisors, and other non-code farmers may not be able to get the information they need from the product and test code.
.......
This paper has been transferred from 51Testing Software test network