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 Phasehas 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.
[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.
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.
