Scribd
Upload
306 views

Software Testing Documentation: Test Plan

Testing documentation involves documenting artifacts like test plans, test scenarios, test cases, and traceability matrices before and during software testing. A test plan outlines the testing strategy, resources, environment, limitations, and schedule. Test scenarios are one-line statements of what areas will be tested to ensure end-to-end process flows. Test cases contain steps, conditions, inputs and expected outcomes to track coverage and determine if the software passes or fails. The traceability matrix traces requirements to design, code, tests and bugs.

Uploaded by

Neo Kool
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
306 views

Software Testing Documentation: Test Plan

Testing documentation involves documenting artifacts like test plans, test scenarios, test cases, and traceability matrices before and during software testing. A test plan outlines the testing strategy, resources, environment, limitations, and schedule. Test scenarios are one-line statements of what areas will be tested to ensure end-to-end process flows. Test cases contain steps, conditions, inputs and expected outcomes to track coverage and determine if the software passes or fails. The traceability matrix traces requirements to design, code, tests and bugs.

Uploaded by

Neo Kool
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Software Testing Documentation

Testing documentation involves the documentation of artifacts which 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 includes the description of some commonly used documented artifacts related to
Software testing such as:

 Test Plan

 Test Scenario

 Test Case

 Traceability Matrix

Test Plan
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, the limitations of the testing and the schedule of testing activities.
Typically the Quality Assurance Team Lead will be responsible for writing a Test Plan.

A test plan will include the following.

 Introduction to the Test Plan document

 Assumptions when testing the application

 List of test cases included in Testing the application

 List of features to be tested

 What sort of Approach to use when testing the software

 List of Deliverables that need to be tested

 The resources allocated for testing the application

 Any Risks involved during the testing process

 A Schedule of tasks and milestones as testing is started

Test Scenario
A one line statement that tells 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 term test scenario and test cases are used interchangeably however the main difference being that test
scenarios has several steps however test cases have a single step. When 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 Case
Test cases involve the set of steps, conditions and inputs which can be used while performing the testing tasks. The
main intent of this activity is to ensure whether the Software Passes or Fails in terms of its functionality and other
aspects. There are many types of test cases like: functional, negative, error, logical test cases, physical test cases, UI
test cases etc.

Furthermore test cases are written to keep track of testing coverage of Software. Generally, there is no formal
template which is used during the test case writing. However, following are the main components which are always
available and included in every test case:

 Test case ID.

 Product Module.

 Product version.

 Revision history.

 Purpose

 Assumptions

 Pre-Conditions.

 Steps.

 Expected Outcome.

 Actual Outcome.

 Post Conditions.

Many Test cases can be derived from a single test scenario. In addition to this, some time it happened that multiple
test cases are written for single Software which is collectively known as test suites.
Traceability Matrix
Traceability Matrix (also known as Requirement Traceability Matrix - RTM) is a table which 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 include and linked with its associated requirements and test
case. The main goals for this matrix are:

 Make sure Software is developed as per the mentioned requirements.

 Helps in finding the root cause of any bug.

 Helps in tracing the developed documents during different phases of SDLC.

Source:

http://www.tutorialspoint.com/software_testing/testing_documentation.htm

You might also like