Documentation as part of process

Testing documentation is usually associated with the documentation of artifacts that should be developed before or during the testing of software.

Testing Documentation is an important part of the testing process.

Documentation for software testing is necessary for evaluating the testing effort needed, requirement tracking/tracing, test coverage etc.

Further are described commonly used documented artifacts concerning software testing:

• Test Plan.
• Test Case.
• Test Scenario.
• Traceability Matrix.

Test Plan

A Test plan outlines the common strategy that will be applied to test an application, the resources that will be used, the test environment in which testing will be performed, and the schedule of testing activities along with the limitations. Typically writing a Test Plan is the competence of the Quality Assurance Team Lead.

Test plan outlines the common strategy that will be applied to test an application.

A test plan includes the following:

• Introduction to the Test Plan document.
• Assumptions while testing the application.
• Approaches to be used while testing the software/application.
• List of test cases used during the testing process.
• Enumeration of features to be tested.
• List of deliverables to be tested.
• The resources allocated for testing the application.
• A schedule of tasks and milestones to be reached.
• Possible risks involved during the testing process.

Test Case

Test case is a complexity of inputs, serious of steps, and conditions that can be used during the process of testing. The key point of this activity is to find out whether a software is successful in terms of its functionality and other aspects. There are various types of test cases such as logical, functional, error, negative test cases, physical test cases, UI test cases, etc.

What's more, test cases are written to keep track of the software testing coverage. Basically, there are no formal templates that can be used while writing a test case.

Test case is a complexity of inputs, serious of steps, and conditions that can be used during the process of testing.

However, the following components are commonly accepted:

• Test case ID.
• Product module.
• Product version.
• Revision history.
• Purpose.
• Assumptions.
• Pre-conditions.
• Steps.
• Expected outcome.
• Actual outcome.
• Post-conditions.

A single test scenario can be applied to many test cases. In addition, sometimes numerous test cases are written for a single software which are collectively known as test suites.

Test Step – is the smallest unit of testing. This is the minimum action which is done by a tester during testing. As an example, a good test scenario is the wish to brush your teeth. Rather simple and clear wish, I may say. The test case can be performed by the process of squeezing a toothpaste from the tube. This process can easily be divided into smaller steps, such as: taking the tube, unscrewing the cap, pressing it until there is enough toothpaste etc.

Test Step – is the smallest unit of testing.

Test Scenario

Test Scenario - it is a one line statement which purpose is to inform what particular area in the application will be tested. Test scenarios are used to ensure that all process flows are thoroughly tested. For a particular area of an application a single test scenario may be enough, and for others the number may go up to a few hundred scenarios depending on the significance and complexity of the application.

Test scenarios are used to ensure that all process flows are thoroughly tested.

The terms 'test scenario' and 'test cases' are sometimes used interchangeably, however a test scenario usually consists of several steps, whereas a test case has a single step. Taking this into account, test scenarios are test cases, but they include several test cases and the sequence that they should be executed. Moreover, each test relies on the output from the previous test.

Traceability Matrix

Traceability Matrix (also referred to as Requirement Traceability Matrix - RTM) is a table that is used to trace the requirements during the Software Development Life Cycle. It can be applied in various usages: forward tracing (i.e. from Requirements to Design or Coding) or backward (i.e. from Coding to Requirements). Different user-defined templates for RTM may be used.

Traceability Matrix is a table that is used to trace the requirements during the Software Development Life Cycle.

Each requirement in the RTM document is linked with its associated test case so that testing can be done as per the mentioned requirements. Moreover, Bug ID is also included and linked with its associated requirements and test case.

The main goals for this matrix are:

• Verification that the software is developed as per the mentioned requirements.
• Identification the root cause of any bug.
• Tracing the developed documents during different phases of SDLC.