System test procedure specification 001

WEBREP — system test plan
Version 1.06

Preface

The reason for producing a system test plan is that it identifies features from the functional specification that need to be tested and gives a complete framework for the testing of these features. By using consistent testing and recording techniques for the entire system, the chances of errors in the system not being discovered and corrected are minimised.

1.2 Background 4

1.3 Scope 4

3. Features to be tested 5

3.1 Functionality 5

4. Features not to be tested 6

4.1 Data entry apart from user data entered at WEBREPInterface.exe 6

5.3 Performance testing 7

5.4 Multiple site 7

Test documentation 8

Test data 8

9.1 Hardware 8

9.2 Software 8

11.1 System test group 9

12. Schedule 9

System test procedure specification 001 10

Procedure steps 11

1. Introduction

1.1 Objectives

Identifying the responsibility for testing each part of the system that needs to be tested
Identifying what parts of the system are to be tested

1.2 Background

1.3 Scope

This test plan is for the 4phones WEBREP system being developed by the WEBREP project team. System testing will comprise functionality, security, performance, multiple site, disaster recovery and regression testing.

1.4 References and documents

ANSI/IEEE Std 829 — 1998, IEEE standard for software test documentation
WEBREP regional buying patterns data entry prototype — cp_9.htm
WEBREP E-Commerce website development — start and end dates — cp_11.htm

1.5 Distribution

2. Test items

WEBREP data flow diagram — cp_4.htm
WEBREP functional hierarchy diagram — cp_5.htm

2.1 Program modules

Type	Name
Executable	WEBREPinterface.exe
Report File	RegionalBuyingPatterns.rpt
Report File	RegionalProductGrowth.rpt

3. Features to be tested

3.1 Functionality

The functionality provided by WEBREPinterface.exe, RegionalBuyingPatterns.rpt and RegionalProductGrowth.rpt is as specified in the Business Requirement Report document.

Covering test items: TI101, TI102, TI103, TI104, TI105, TI106, TI107, TI108…etc

3.2 Security

3.3 Performance

3.4 Multiple site

Multiple Site issues can arise such as multiple users logging in under the same user name, or multiple sites running the same report concurrently.

Covering test items: TI401, TI402, TI403, and TI404

3.5 Disaster recovery

4. Features not to be tested

4.1 Data entry apart from user data entered at WEBREPInterface.exe

The web login verifies the username and password and has been tested in the other E-Commerce project modules. Data validation for WEBREPInterface.exe occurred during the unit testing of this module, however the functionality related to the security and user data entered in WEBREPInterface.exe will be tested in 3.2

4.2 Other modules of E-Commerce project

The WEBREP module functions independently of the other 4Phones E-Commerce project modules, such as WEBIN and WEBORD, as data for the reports is extracted directly from the 4Phones financials system

5. Approach

5.1 Functionality

5.2 Security testing

5.3 Performance testing

Report generation times
Capability of the system to perform with limited bandwidth.

5.4 Multiple site

5.5 Recovery testing

5.6 Regression testing

6. Item pass/fail criteria

7. Test deliverables

Generated from the testing phase of development for this system will be the following list of documents:

Test documentation

System test plan

Test data

Copies of database tables.

8. Suspension criteria

8.1 Suspension

The system test will be suspended if the WEBREPInterface.exe program is causing corruption to the indexes or data of the 4Phones financials system or generating operating system faults on the test platforms. Additionally, if the WEBREPInterface.exe or reports are generating a load on the system hardware that affects other 4Phones users (such as excessive network traffic) the system test will be suspended.

8.2 Resumption

9. Environmental needs

9.1 Hardware

9.2 Software

Clients — Microsoft windows XP with service pack 2

Tools

10. Responsibilities

10.1 System test group

Tony Meyer — business analyst
Greg Carr — business analyst

10.2 Development team

11. Staffing and training needs

11.1 System test group

Test Manager — Greg Carr

Senior Test Analyst — Tony Meyer

12. Schedule

13. Risks and contingencies

14. Testing tasks

In the following table, the tasks to be completed, the order that they are to be completed and the people responsible for their completion are outlined.

Table 1: Testing timetable and responsibilities

15. Approvals

Appendix A