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.