Software Test Documents

What are the documents that are used for Software Testing ? (Or) What are the reports we create during Testing?

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 Script
• Test Suite
• Test fixture or test data
• Test Harness

Lets discuss concerning every document intimately below:

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.

Test script

A take a look at script may be a procedure, or programming code that replicates user actions. at first the term was derived from the merchandise of labor created by automatic regression take a look at tools. legal action are a baseline to make take a look at scripts employing a tool or a program.

Test suite

The most common term for a set of take a look at cases may be a take a look at suite. The take a look at suite usually additionally contains additional elaborated directions or goals for every assortment of take a look at cases. It positively contains a neighborhood wherever the tester identifies the system configuration used throughout testing. a gaggle of take a look at cases can also contain necessity states or steps, and descriptions of the subsequent tests.

Test fixture or test data

In most cases, multiple sets of values or knowledge area unit accustomed take a look at constant practicality of a selected feature. All the take a look at values and changeable environmental parts area unit collected in separate files and keep as take a look at knowledge. it's additionally helpful to produce this knowledge to the shopper and with the merchandise or a project.

Test harness

A test harness should allow specific tests to run (this helps in optimising), orchestrate a runtime environment, and provide a capability to analyse results.
The typical objectives of a test harness are to:

• Automate the testing process.
• Execute test suites of test cases.
• Generate associated test reports.

A test harness may provide some of the following benefits:

• Increased productivity due to automation of the testing process.
• Increased probability that regression testing will occur.
• Increased quality of software components and application.
• Ensure that subsequent test runs are exact duplicates of previous ones.
• Testing can occur at times that the office is not staffed (e.g. at night)
• A test script may include conditions and/or uses that are otherwise difficult to simulate (load, for example)

An alternative definition of a test harness is software constructed to facilitate integration testing. Where test stubs are typically components of the application under development and are replaced by working component as the application is developed (top-down design), test harnesses are external to the application being tested and simulate services or functionality not available in a test environment. For example, if you're building an application that needs to interface with an application on a mainframe computer but none is available during development, a test harness may be built to use as a substitute. A test harness may be part of a project deliverable. It’s kept outside of the application source code and may be reused on multiple projects. Because a test harness simulates application functionality - it has no knowledge of test suites, test cases or test reports. Those things are provided by a testing framework and associated automated testing tools.