Software Testing - Documentation

Test documentation encompasses the documents that need to be created before and during the software testing process.

Software testing documents are essential for estimating the required effort, defining the scope of testing, and tracking requirements. This section details some commonly used documents in software testing, including:

• Test Plan

• Test Scenario

• Test Case

• Traceability Matrix

I. Software Test Plan

A test plan outlines the strategies for testing an application, the resources to be utilized, the testing environment, testing limitations, and the schedule of testing activities. Typically, the Quality Assurance Team Lead is responsible for creating a test plan.

A test plan includes:

• Introduction to the test plan document.

• Assumptions made during software testing.

• List of test cases for the application.

• List of functions to be tested.

• Methods used in software testing.

• List of special cases for testing.

• Resources allocated for testing the application.

• Potential risks during the testing process.

• Specific schedule for tasks and milestones.

II. Test Scenario

A test scenario ensures that all process flows are tested from end to end. Depending on the size and complexity of the project, an application may have one or more test scenarios covering hundreds of cases.

The terms 'test scenario' and 'test case' are often used interchangeably; however, a test scenario comprises multiple steps, while a test case consists of a single step. From this perspective, a test scenario is a collection of test cases executed in sequence.

III. Test Case

A test case includes a set of steps, conditions, and inputs for testing. There are various types of test cases such as functional, negative, error, logical, physical, and user interface test cases.

The main purposes of creating test cases are:

• Test cases outline the steps to ensure requirements are implemented as planned.

• Test cases maintain test data, ensuring testers know which data to use.

• Test cases serve as a fundamental knowledge base derived from requirements. When testers change roles, knowledge transfer is minimized.

• Test cases guide new testers on how to test requirements.

• Accurate test cases ensure that the QA lead knows which parts of the application are tested, which are not, which parts have more bugs, and which have fewer bugs after testing.

Test cases track the testing scope of software. While there is no formal template for test cases, the following components are always present:

• Test Case ID

• Product module

• Product version

• Revision history

• Preconditions

• Steps

• Expected result

• Actual result

IV. Traceability Matrix

A Traceability Matrix is a table used to track changes during the software development lifecycle. It can be used to view changes or trace documents forward.

Each requirement in the RTM document is linked to related test cases to ensure requirements are met. Additionally, Bug IDs are included and linked to their related requirements and test cases. The main objectives of this matrix are:

• Ensure software is developed according to requirements.

• Identify the root cause of bugs.

• Track documents developed during different stages of the SDLC.

By implementing these software testing documents, teams can ensure a comprehensive and effective testing process, enhancing the quality and reliability of the software product.