Software Testing Artifacts – Detailed Guide

Software Testing Artifacts

For any software testing project, there will be multiple software testing artifacts that are prepared by the software testing team which gets reviewed and approved by the project team during each phase of the project. We have listed out all those important software testing artifacts in this article.

1. Test Plan

The test plan is a document that describes the testing scope and activities in software testing. The formal testing of any software or product is done using this. This is the first document created as part of the software testing artifacts

A test plan is any document describing the approach, scope, resources, and schedule of the test activities to be performed.According to ISTQB

A test plan document includes:

  • Test items
  • Features to be tested
  • Which testing tasks to be done
  • Who will perform each task
  • Degree of independence
  • Test environment
  • Test design techniques
  • Entry and exit criteria
  • The rationale for choices made
  • Risks requiring contingency plans
READ  Top 10 Best Online Computer Science Degree In 2020

We can say that it is a document used to record the test planning process.

ISBTQ also defines the master test plan and phase test plan as:

Master Test Plan: A plan addressing multiple test levels is called the master test plan.

Phase Test Plan: A plan addressing one test phase is called the phase test plan.

Now, let us check the various types of the test plan, test template, and test guidelines.

software testing artifacts

Types of Test Plans

There are following different types of test plan:

Master Test Plan: It is the highest-level test plan for a project/product that unifies all other test plans.

Testing Level Specific Test Plan: This is a plan for each of the following testing levels:

Testing Type Specific Test Plan: The plans for various types of testing such as Performance test plan and security test plan are included in this type.

Test Plan Template

The below-given test plan template is based on the IEEE standard for the software test documentation. 

Although the format and content of the software test plan vary depending on the standards, processes and test management tools implementation, the IEEE is the basic standard providing a summary of what should be included in a test plan.

1. Test Plan Identifier

  • Every test plan must contain a unique identifier to identify the document. If we have a Configuration Management System, then we must adhere to it.

2. Introduction

  • An overview of the test plan should be provided in the introduction section.
  • The goal, objectives and constraints must be specified in the introduction.
READ  White Box Testing

3. References

  • Project Plan, Configuration Management Plan, and other related documents must be listed, and links to each of them should be provided.

4. Test Items

  • The software or products and items used in the project should be listed along with their respective versions.

5. Features to be Tested

  • The various features of the software or product to be tested should be listed.
  • Requirement and Design specifications of the features that are to be tested should be referenced.

 6. Features Not to be Tested

  • The features that need not be tested should be listed along with their reasons for not getting tested.

7. Approach

  • The approach or how the testing will be done should be mentioned.
  • The testing levels such as master test plan, testing types and the methods employed for testing such as manual or automated, white box, black box or grey box testing should be specified.

8. Item Pass/Fail Criteria

  • The success (pass) or failure criteria for each of the test items, whether software or product, should be specified.

9. Suspension Criteria and Resumption Requirements

  • The testing activity suspension criteria should be specified in the test plan.
  • Once the testing is resumed, the testing activities that are to be redone should be specified.

10. Test Deliverables

  • The deliverables, along with their respective, if available, should be listed. 
  • Some of them are:
    • Test Cases
    • Test Plan
    • Test Reports
    • Test Scripts
    • Defect or Bug Reports

11. Test Environment

  • The network, hardware, software, and other properties of the test environment should be specified.
  • The testing or other related tools should be listed.

12. Estimate

  • A summary of the cost and effort test estimates should be summarized and linked along with their detailed estimation.

13. Schedule

  • The summary of a schedule and a link to the detailed schedule in which key test milestones are specified should be provided.
READ  Waterfall vs Agile: Differences, Pros and Cons

14. Staffing and Training needs

  • The roles and required skills from the staff should be specified.
  • Adequate training should be provided to acquire those necessary skills.

15. Responsibilities

  • The responsibilities for each team, role and individual should be listed.

16. Risks

  • The risks that are identified should be listed.
  • Necessary mitigation and contingency plans for each risk should be specified.

17. Assumptions and Dependencies

  • All assumptions made during the entire test plan preparation should be listed.
  • All dependencies of the test plan should be listed.

18. Approvals

  • At last, the names and role of each person who needs to approve the test plan should be specified.
  • Adequate space for signature and dates should be provided.

Test Plan Guidelines

  • While making the test plan, always be specific about every detail to give no space to ambiguity. For example, while specifying the type of Operating System, mention it is edition or version as well.
  • Before final submission for approval, make sure the test plan is thoroughly revised and reviewed a few times. The quality of the test plan determines the quality of testing that will be performed by our team and us.
  • Make sure the test plan is as concise as possible and is free of any redundancy and superfluousness. Not every section from the above template is necessary, so delete any section that our plan does not need.
  • Update the test plan as frequently as needed. Older and outdated test plan documents are unnecessary. Having an outdated, unused test plan is worse than having no test plan at all.
  • Instead of using lengthy paragraphs, use lists and tables as they make it easier to understand the contents.