How to Write a Software Testing Plan

Whether a software development team is building a new application or making revisions to an existing application, there is one phase that is absolutely necessary before final release to the customers. That phase is called testing and its purpose is to identify defects and make corrections. But as applications become bigger and integrate with other systems, testing can turn into a nightmare. The best way to control testing activities is to write a detailed test plan that includes relevant test cases for all new functionality in the application. As software development involves multiple people, the test plans should be written by those with the most expertise in a specific area.

Types of Testing

The first thing to consider when preparing a test plan is to determine what kind of testing is needed and who will prepare the associated plan. Test types include unit, integration, system, alpha, beta, acceptance, regression, etc.  For example:

  • Test Plans for Unit, Integration, and System testing can be assigned to the development team because they are responsible for the application code.
  • Test Plans for alpha, beta, and acceptance testing can be the responsibility of the Business Analysts because they write the Business Requirements based on customer input.
  • Test Plans for Regression testing are different than other types of testing. They deal with existing functionality, not new development. Comprehensive test plans can be written by customer representatives who are very familiar with how the application worked before changes were made to the code.

What to Include in the Test Plan

A test plan has multiple test cases that test specific parts of the application. All the test cases relate to the requirements that were prepared by the Business Analysts. Each test case should include the following basic information:

  • Identification Number
  • Name of Test Case
  • Business Requirement ID
  • Input Data
  • Steps to execute test
  • Desired result
  • Name of Tester
  • Indicator for pass/fail
  • Test cycle number

Depending on the application, other information can be included:

  • Severity (e.g. high, medium, low)
  • Operating system (e.g. Windows, UNIX, Linux, Android)
  • Browser (e.g. Explorer, Foxfire, Safari)
  • Language (e.g. English, French, Chinese)
  • Platform (e.g. desktop, tablet, mobile)
  • Defect number (if there is a defect management system)
  • Comments

Unit, System, and Integration test plans can include module, components, class names, and references to design documents.

The test plan can be created using a word processing table, test plan template or a spreadsheet. Each line represents a different test case to be performed on the application. The following is simple Acceptance Test Plan Sample.

[raw]

Test Plan: Business Requirement #3 & #4: Login and Logout Procedures

ID #

Test Case Name

BR ID

Input Data

Steps to Execute

Desired

Result

Tested By

Pass/Fail

Test Cycle

T-1

Log in

(successful)

BR-3

ID: 456

PW: abc

1.Type ID

2.Type PW

3.Click Log in button.

User goes to home page.

Jane

Pass

1

T-2

Log in

(unsuccessful)

BR-3

ID: 456

PW: XXX

1.Type ID

2.Type PW

3.Click Log in button.

Error message displays.

Jane

Pass

1

T-3

Log out

BR-4

None

1.Click Log out button.

Return to log in page.

Jane

Pass

1

[/raw]

However, if the testing effort is very large, some teams may use a database to record the test cases. Then individual testers are assigned records from the database to use as their test plan. Once a plan is written, accurate recording of test results is vital in identifying the defects that need to be fixed before release of the application.

To allow for consistency and accuracy, organizations will generally use a Test Plan Template  and Test Case Spreadsheet to facilitate the documentation of testing.

 

Leave a Reply

Your email address will not be published. Required fields are marked *