Prev Contents 1 2 3 4 5 6 7 8 9 10 11 12 Next

Sample Test Plan

Chapter 2 - Scope and Objectives

2. SCOPE AND OBJECTIVES

2. SCOPE AND OBJECTIVES

2.1. Scope of Test Approach - System Functions

2.1.1. INCLUSIONS

The contents of this release are as follows :-

Phase 1 Deliverables

New & revised Transaction Processing with automated support
New Customer Query Processes and systems
Revised Inter-Office Audit process
Relocate Exceptions to Head Office
New centralised Agency Management system
Revised Query Management process
Revised Retrievals process
New International Reconciliation process
New Account Reconciliation process

2.1.2. EXCLUSIONS

When the scope of each Phase has been agreed and signed off, no further inclusions will be considered for inclusion in this release, except:

(1) Where there is the express permission and agreement of the Business Analyst and the System Test Controller;
(2) Where the changes/inclusions will not require significant effort on behalf of the test team (i.e. requiring extra preparation - new test conditions etc.) and will not adversely affect the test schedule.

[See Section 9.1.]

2.1.3. SPECIFIC EXCLUSIONS

Cash management is not included in this phase
Sign On/Sign Off functions are excluded - this will be addressed by existing processes
The existing Special Order facility will not be replaced
Foreign Currency Transactions
International Data Exchanges
Accounting or reporting of Euro transactions

Reference & Source Documentation:

1. Business Processes Design Document - Document Ref: BPD-1011
2. Transaction Requirements for Phase 1 - Document Ref: TR_PHASE1-4032
3. Project Issues & Risks Database - T:\Data\Project\PROJECT.MDB
4. The System Development Standards - Document Ref: DEVSTD-1098-2
5. System Development Lifecycle - Document Ref: SDLC-301

2.2. Testing Process

The diagram above outlines the Test Process approach that will be followed.

a.	Organise Project involves creating a System Test Plan, Schedule & Test Approach, and requesting/assigning resources.
b.	Design/Build System Test involves identifying Test Cycles, Test Cases, Entrance & Exit Criteria, Expected Results, etc. In general, test conditions/expected results will be identified by the Test Team in conjunction with the Project Business Analyst or Business Expert. The Test Team will then identify Test Cases and the Data required. The Test conditions are derived from the Business Design and the Transaction Requirements Documents
c.	Design/Build Test Procedures includes setting up procedures such as Error Management systems and Status reporting, and setting up the data tables for the Automated Testing Tool.
d.	Build Test Environment includes requesting/building hardware, software and data set-ups.
e.	Execute Project Integration Test - See Section 3 - Test Phases & Cycles
f.	Execute Operations Acceptance Test - See Section 3 - Test Phases & Cycles
g.	Signoff - Signoff happens when all pre-defined exit criteria have been achieved. See Section 2.4.

2.2.1. Exclusions

SQA will not deal directly with the business design regarding any design / functional issues / queries.

The development team is the supplier to SQA - if design / functional issues arise they should be resolved by the development team and its suppliers.

2.3. Testing Scope

Outlined below are the main test types that will be performed for this release. All system test plans and conditions will be developed from the functional specification and the requirements catalogue.

2.3.1. Functional Testing

The objective of this test is to ensure that each element of the application meets the functional requirements of the business as outlined in the :

Requirements Catalogue
Business Design Specification
Year 2000 Development Standards
Other functional documents produced during the course of the project i.e. resolution to issues/change requests/feedback.

This stage will also include Validation Testing - which is intensive testing of the new Front end fields and screens. Windows GUI Standards; valid, invalid and limit data input; screen & field look and appearance, and overall consistency with the rest of the application.

The third stage includes Specific Functional testing - these are low-level tests which aim to test the individual processes and data flows.

2.3.2. Integration Testing

This test proves that all areas of the system interface with each other correctly and that there are no gaps in the data flow. Final Integration Test proves that system works as integrated unit when all the fixes are complete.

2.3.3. Business (User) Acceptance Test

This test, which is planned and executed by the Business Representative(s), ensures that the system operates in the manner expected, and any supporting material such as procedures, forms etc. are accurate and suitable for the purpose intended. It is high level testing, ensuring that there are no gaps in functionality.

2.3.4. Performance Testing

These tests ensure that the system provides acceptable response times (which should not exceed 4 seconds).

2.3.5. Regression Testing

A Regression test will be performed after the release of each Phase to ensure that -

There is no impact on previously released software, and
to ensure that there is an increase in the functionality and stability of the software.

The regression testing will be automated using the automated testing tool.

2.3.6. Bash & Multi-User Testing

Multi-user testing will attempt to prove that it is possible for an acceptable number of users to work with the system at the same time. The object of Bash testing is an ad-hoc attempt to break the system.

2.3.7. Technical Testing

Technical Testing will be the responsibility of the Development Team.

2.3.8. Operations Acceptance Testing (OAT)

This phase of testing is to be performed by the Systems Installation and Support group, prior to implementing the system in a live site. The SIS team will define their own testing criteria, and carry out the tests.

2.4. System Test Entrance/Exit Criteria

2.4.1. Entrance Criteria

The Entrance Criteria specified by the system test controller, should be fulfilled before System Test can commence. In the event, that any criterion has not been achieved, the System Test may commence if Business Team and Test Controller are in full agreement that the risk is manageable.

All developed code must be unit tested. Unit and Link Testing must be completed and signed off by development team.
System Test plans must be signed off by Business Analyst and Test Controller.
All human resources must be assigned and in place.
All test hardware and environments must be in place, and free for System test use.
The Acceptance Tests must be completed, with a pass rate of not less than 80%.

Acceptance Tests:
25 test cases will be performed for the acceptance tests. To achieve the acceptance criteria 20 of the 25 cases should be completed successfully - i.e. a pass rate of 80% must be achieved before the software will be accepted for System Test proper to start. This means that any errors found during acceptance testing should not prevent the completion of 80% of the acceptance test applications.

Note: These tests are not intended to perform in depth testing of the software.
Resumption Criteria
In the event that system testing is suspended resumption criteria will be specified and testing will not re-commence until the software reaches these criteria.

2.4.2. Exit Criteria

The Exit Criteria detailed below must be achieved before the Phase 1 software can be recommended for promotion to Operations Acceptance status. Furthermore, I recommend that there be a minimum 2 days effort Final Integration testing AFTER the final fix/change has been retested. [See section 9.3]

All High Priority errors from System Test must be fixed and tested
If any medium or low-priority errors are outstanding - the implementation risk must be signed off as acceptable by Business Analyst and Business Expert
Project Integration Test must be signed off by Test Controller and Business Analyst.
Business Acceptance Test must be signed off by Business Expert.

Prev Contents 1 2 3 4 5 6 7 8 9 10 11 12 Next