Académique Documents
Professionnel Documents
Culture Documents
INTRODUCTION
To aim of this phase of the project is to implement a new X System platform that will enable:
This programme will result in significant changes to the current departmental and inter-office
processes. The functionality will be delivered on a phased basis.
Phase 1 will incorporate the following facilities :
This document is to serve as the Draft Test Approach for the Business Systems Development
Project.
Preparation for this test consists of three major stages:-
• The Test Approach sets the scope of system testing, the overall strategy to be adopted,
the activities to be completed, the general resources required and the methods and
processes to be used to test the release. It also details the activities, dependencies and
effort required to conduct the System Test.
• Test Planning details the activities, dependencies and effort required to conduct the
System Test.
• Test Conditions/Cases documents the tests to be applied, the data to be processed, the
automated testing coverage and the expected results.
• The functionality, delivered by the development team, is as specified by the business in the
Business Design Specification Document and the Requirements Documentation.
• The software is of high quality; the software will replace/support the intended business
functions and achieves the standards required by the company for the development of new
systems.
• The software delivered interfaces correctly with existing systems, including Windows 98.
[Detailed objectives are listed later in this document.]
The above V Model shows the optimum testing process, where test preparation commences as
soon as the Requirements Catalogue is produced. System Test planning commenced at an early
stage, and for this reason, the System test will benefit from Quality initiatives throughout the
project lifecycle.
The responsibility for testing between the Project & Software Qualtiy Assurance (S.Q.A.) is as
follows:
2.1.1. INCLUSIONS
The contents of this release are as follows :-
Phase 1 Deliverables
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.
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.
• 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.
• 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.
[For details of the acceptance tests to be performed see
X:\Testing\Phase_1\Testcond\Criteria.doc]
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.
• 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.
5. RESOURCES
5.1. Human
5.2. Hardware
One seperate, controlled system will be required for the initial phase
of testing, setup as per one standard, complete office environment.
In order to maintain the integrity of the test environment his network
will not be accessible to anybody outside this project. The printers are
also exclusively for use by the test network.
Hardware components required
• 1 Network Controller
• 6 Networked PC's (See below)
• 1 DAP Workstation
• 1 Motorola 6520
• 1 Alpha AXP Server
• 1 Batch Waste Printer
• 1 HP LaserJet 4v Printer
PC Specifications
The 6 PC's required for the test environment will include the following:
1 x P100, 1Gb HD, 16Mb RAM [Current Minimum Specification]
3 x P166, 1.5Gb HD, 32Mb RAM [Current Standard Specification]
1 x P333, 2.5Gb HD, 64Mb RAM [Current Maximum Specification]
These specifications are the various specifications currently in use in different branches.
1 x Pentium running Windows NT is also required as the Test center for controlling and executing the
automated testing.
5.3. Software
Test IMS environments
Test IMS region X will be required for System Testing. Additional or amended
data will be populated where required.
IMS Support
Provide System Test Support
Support IMS Regions
Resolve Spooling Issues (if necessary)
Bookkeeping Integration & Compliance (if necessary)
Resolve queries arising from remote backup
Bookkeeping Support
Provide Bookkeeping Technical support, if required.
Resolve queries, if required.
Technical Support
Provide support for hardware environment
Provide support for Test software
Promote Software to system test environment
Access Support
Provide and support Test Databases
9.2. Assumptions
• Software will be delivered on time.
• Software is of the required quality.
• The software will not be impacted by impending Y2K compliance changes to the external
software infrastructure - i.e. any external software changes will have to be compatible with this
application.
• All "Show-Stopper" bugs receive immediate attention from the development team.
• All bugs found in a version of the software will be fixed and unit tested by the development
team before the next version is released.
• Functionality is delivered to schedule.
• Required resources available.
• All service agreements will be met.
• The automated test tool will function & interface correctly with the software.
• All documentation will be up to date and delivered to the system test team.
• Functional and technical specifications will be signed off by the business.
• All service agreements will be met.
• The Intranet will be fully functional prior to project commencement.
11. APPENDICES
11.1. Purpose of Error Review Team.
Ensure maximum efficiency of the development and system testing teams for the release of the new
office software through close co-operation of all involved parties.
This will be achieved through daily meetings whose function will be to
• Agree status of each raised Error
• Prioritisation of valid Error's
• Ensure that enough documentation is available with Error's.
• Agree content and timescale for software releases into System test.
• Ensure one agreed source of Error reporting information.
• Identify any issues which may affect the performance of system testing.
Print off Account and Customer records and check field detail Bookkeeping - Input Checking at
against applic input forms/branch summary report tx's field level
V
Test Input
forms/Amend rpt
(ii) EFFORT.
- No. of SQA Man Days Test Planning
- No. of SQA Man Days Reviewing Test Plans
- No. of SQA Man Days Executing Tests
(iii) VOLUME.
- No. of Tests Identified
(iv) QUALITY.
- No. of Tests Passed First Time
- Percentage of Tests Passed First Time
- No. of Error's Raised During Regression Testing
- No. of Error's Generated as a Result of Incorrect Fixes
- No. of Error's Raised by Category (A/B/C)
- No. of Error's Raised by Reason Code
- No. of Error's Raised by High Level Business Function
(v) TURNAROUND.
– Average Error Turnaround Time
12.2. Diagrams:
Click on the small image to view the main diagram. (Note Actual sizes approx. 1040 x 780)
http://bazman.tripod.com/planframe.html
_____________________________________
Test Plan Sample _
Table of Contents
1. Introduction
2. Resource Requirements
Hardware
Software
• Test Tools
Staffing
• Responsibilities
• Training
5. Test Deliverables
6. Dependencies/Risks
7. Entrance/Exit Criteria
1. Introduction
The focus of the -Project name- is to support those new features that will allow
easier development, deployment and maintenance of solutions built upon the
-Project name-. Those features include:
This release of the -Project name- will also include legacy bug fixing, and
redesigning or including missing functionality from previous release
Related Documents
2. Resource Requirements
Hardware
Software
[List of software requirements: primary and secondary OS]
Test Tools
Apart from manual tests, the following tools will be used:
-
-
-
Staffing
Responsibilities
[List of QA team members and there responsibilities]
Training
[List of training's required]
Media Verification
[The process will include installing all possible products from the media and
subjecting them to basic sanity testing.]
5. Test Deliverables
6. Dependencies/Risks
Dependencies
Risks
7. Milestone Criteria