Testing documentation involves the documentation of facts that should be developed before or during the testing of Software.
Documentation for software testing helps in estimating the testing effort required, test coverage, requirement tracking/tracing, etc. This section describes some of the commonly used documented facts related to software testing such as:
A test plan outlines the strategy that will be used to test an application, the resources that will be used, the test environment in which testing will be performed, and the limitations of the testing and the schedule of testing activities.
A test plan includes the following:
It is a one-line statement that notifies what area in the application will be tested. Test scenarios are used to ensure that all process flows are tested from end to end. A particular area of an application can have as little as one test scenario to a few hundred scenarios depending on the magnitude and complexity of the application.
The terms 'test scenario' and 'test cases' are used interchangeably, however a test scenario has several steps, whereas a test case has a single step. Viewed from this perspective, test scenarios are test cases, but they include several test cases and the sequence that they should be executed. Apart from this, each test is dependent on the output from the previous test.
Test cases involve a set of steps, conditions, and inputs that can be used while performing testing tasks. The main intent of this activity is to ensure whether a software passes or fails in terms of its functionality and other aspects. There are many types of test cases such as functional, negative, error, logical test cases, physical test cases, UI test cases, etc.
Furthermore, test cases are written to keep track of the testing coverage of a software. Generally, there are no formal templates that can be used during test case writing. However, the following components are always available and included in every test case:
Many test cases can be derived from a single test scenario. In addition, sometimes multiple test cases are written for a single software which are collectively known as test suites.
Traceability Matrix (also known as Requirement Traceability Matrix - RTM) is a table that is used to trace the requirements during the Software Development Life Cycle. It can be used for forward tracing (i.e. from Requirements to Design or Coding) or backward (i.e. from Coding to Requirements). There are many user-defined templates for RTM.
Each requirement in the RTM document is linked with its associated test case so that testing can be done as per the mentioned requirements. Furthermore, Bug ID is also included and linked with its associated requirements and test case. The main goals for this matrix are:
A good test case template maintains test artifact consistency for the test team and makes it easy for all stakeholders to understand the test cases.
4. Test Designed by: Tester's Name
5. Date of test designed: Date when test was designed
6. Test Executed by: Who executed the test- tester
7. Date of the Test Execution: Date when test needs to be executed
8. Name or Test Title: Title of the test case
9. Description/Summary of Test: Determine the summary or test purpose in brief
10. Pre-condition: Any requirement that needs to be done before execution of this test case. To execute this test case list all pre-conditions
11. Dependencies: Determine any dependencies on test requirements or other test cases
12. Test Steps: Mention all the test steps in detail and write in the order in which it requires to be executed. While writing test steps ensure that you provide as much detail as you can
13. Test Data: Use of test data as an input for the test case. Deliver different data sets with precise values to be used as an input
14. Expected Results: Mention the expected result including error or message that should appear on screen
15. Post-Condition: What would be the state of the system after running the test case?
16. Actual Result: After test execution, actual test result should be filled
17. Status (Fail/Pass): Mark this field as failed, if actual result is not as per the estimated result
18. Notes: If there are some special condition which is left in above field
Optionally you can have the following fields depending on the project requirements
A sample Test case template is attached.
Test Summary Report is a document which contains
Based on the test report, the stakeholders can
All information of the project such as the project name, product name, and version should be described in the test report.
As mentioned in Test Planning tutorial, Test Report should include the objective of each round of testing, such as Unit Test, Performance Test, System Test â€¦Etc.
This section includes the summary of testing activity in general. Information detailed here includes
• The number of test cases executed
• The numbers of test cases pass
• The numbers of test cases fail
• Pass percentage
• Fail percentage
This information should be displayed visually by usingcolor indicator, graph, and highlighted table.
One of the most important information in Test Report is defect. The report should contain following information
• Total number of bugs
• Status of bugs (open, closed, responding)
• Number of bugs open, resolved, closed
• Breakdown by severity and priority
A Good Test Report contains