Test documentation in software testing allows for a precise reference point for what should be tested, how testing should be done, and by whom. Test documentation allows developers or other team members to find out the details of testing that has been performed on a system or product, thus enabling them to make informed decisions when changing or enhancing the system or product.

Test documentation is the only way to communicate software test requirements to development and maintenance groups. It is a guide for testers and a checklist for developers.

Software Testing is a process and an activity. It is not a department or a project for developers and testers like the white-box approach, White box test approach and Black box approach. See differences between white-box and black-box here.
Test documentation helps the team members to design test cases that will be executed during the testing phase.

During development, we tend to think of the product more than the process. We understand the features of the software product better than how it will be tested. During testing phase, we tend to think of how do we test this software product. If we wish to improve our existing products or create new products, this document helps us in knowing what has already been tested (and what needs to be tested).

Types of test documentation in software testing

Bug trackers

Use bug tracker software that is easy to use and makes it possible to hunt down bugs quickly. Collaboration tools such as mailing lists and wikis such as Wikipedia (and even other wikis like Wikipedia) are great for collaboration.

One of the most important types of documentation is a bug tracker, which tracks all bugs including the steps to reproduce them. A bug tracker can also be used for any test cases when it is not possible to keep track of the test steps. A bug tracker can be as simple as an excel sheet to other more functional tools like JIRA or Trello(which are more task productivity tools). There are more dedicated bug tracker tools such as testrail.

A variety of other tools are used to share information about the system being tested, to communicate with other team members, to report on the progress of testing, and to record how bugs are discovered. The tools can be very simple or very sophisticated. For example, if you want to share information about the system being tested, you can just use e-mail or instant messaging. Instead of using a wiki or blog tool to communicate, you can set up your workspace to ask your peers (or the team lead) questions about what has already been tested, and how it has been tested. This is particularly useful if you are working on a project with multiple sub-projects.

The process for creating test documentation varies depending on who is doing it, how, and when. If you are looking to create new tests then you will want to write them down before starting any testing. This would be the best time to create your checklist, because later on in the testing phase you may forget things that needed to be done at one point in time.

Test plan

A Test plan is an important piece of document and it describes the general objectives of the testing process, describes non-functional requirements (if any), describes the test environment and provides document structure describing what tests will be performed. The test plan acts as a high-level blueprint for the tests executed during the testing phase. It acts as a map for both testers and developers.
Test plan would include:

Test procedure and test cases (test instructions)

Test Procedure describes step-by-step instructions on how to execute a test case. Test instructions are written to ensure that each test case executes completely and that each result or defect observed has been considered in the analysis of results or defects respectively. Test Procedure describes what, how, when, where, who, etc that are required to be performed during testing process. A test procedure may have detailed steps or just an outline with missing detailed steps to be filled in by the developer(s).

Test case

This is a set of instructions or input data that must result in the expected behavior of the product (i.e., what happens when you do this). Test cases can be used to verify whether a software system meets or conforms to specifications. They are grouped into test groups called test suites.

Test ID

Establishes unique ID for each ID number for identification purpose. It is used in all test plans, procedures, etcetera.

Test environment

A Test environment is the resources required for testing an application or system including hardware, operating system and application programs used during testing.

Test logging, audit and traceability

More complicated software development projects require better documentation and more elaborate test environments (for instance, virtual machines and emulators for testing legacy systems) that make it harder to understand the impact of changes on the various components.

The test execution tools typically generate logs or records of tests that can be automatically compared to results. Such logs help the testers verify whether the changes they made had an unintended effect on other components (breaking existing functionality).

Conclusion

It is very difficult to tell whether documentation techniques are being used effectively. There are several techniques that influence test case development and are important to consider.
However, it is important to understand what you can do to ensure your test cases are of good quality. A good document structure and proper testing tools can come in handy when writing test scripts. It can also help with testing issues because it provides a good place to look for help if there are any problems running the scripts or identifying problems.

See also: The most common automation testing challenges.