Testing Fact Sheet

advertisement
FACT SHEET
Testing
Central Budget Management System Redevelopment Project
This fact sheet describes the testing approach for the Central Budget Management System
Redevelopment Project. Testing of the system ensures the solution is fit for purpose, meets the defined
requirements of the business and complies with whole- of- Government IT standards.
Test Plan
The Test Plan outlines the scope of testing and related activities to be carried out for each test stage. The Test
Plan provides transparency about the testing process and is shared with all the stakeholders involved to
ensure they understand their roles and responsibilities. The Plan also outlines the Exit Criteria for each testing
stage, ensuring quality of the solution is managed closely.
Testing Stages
Testing of the CBMS-R Solution will be conducted in stages which align with industry best practice referred to
as the V-Model. Testing starts with Unit Testing at the bottom of the ‘V’ and continues upward through each
testing stage.
V-Model is a verification and validation model: each testing stage must satisfy pre-determined Exit Criteria
before moving on to the next stage of testing.
The stages of the V-Model (starting at the top) are as follows:

Coding  Unit Testing
The Contractor Development Team tests individual software components to verify that the requirements
from the design phase have been correctly interpreted and that the components operate as expected.

Design  Scenario Testing
The Contractor Test Team performs a range of scenarios to ensure the Solution operates as expected and is
in accordance with the design. Each scenario comprises a set of logically related activities or business
process steps to achieve a defined business process result (or ’to enable a defined business process’) .

Requirements  System Integration Testing (SIT)
The Finance Test Team conducts testing of all the customised and standard system functions to verify that
they meet the CBMS Solution Functional Requirements. Integration tests are end-to-end and include crossmodule and cross-system scenarios.

Business needs  User Acceptance Testing (UAT)
UAT is conducted by end-users who perform end to end processing and exercise business scenarios. UAT is
designed to confirm that the CBMS Solution meets the defined Functional Requirements, is fit for purpose
and can be used for the Budget process. CBMS Users will be contacted closer to UAT to determine
appropriate testers.
CBMS-R Project FACT SHEET - Testing |
1
User Acceptance
Testing
Business Users,
Business Analysts
Business Needs
Requirements
System Integration
Testing
Finance Project Team
Designers,
Architects
Design
Coding
Scenario Testing
Developers
Unit Testing
System
Non-Functional Requirement (NFR) Testing
The Finance Project Team and subject matter experts will also test the way the system operates, rather than
specific functional behaviours. For example, how many users can use the system at once, how long it takes to
complete a task (system performance), compliance with accessibility guidelines, and the system’s security and
vulnerability. This testing is performed in parallel with the SIT and UAT stages.
As the CBMS Solution is used by all Commonwealth entities, they will be asked to test the compatibility and
connectivity of their systems with the CBMS as part of the NFR testing and again, as part of the go-live
readiness activities.
Incident Management
During testing, any instances where the system does not function as expected will be logged as an incident.
These are classified by priority and criticality and are typically resolved prior to and during UAT as they arise.
Some cosmetic and minor defects that do not inhibit the system’s performance or functionality may remain for
future remediation.
Testing Schedule
The testing schedule has been developed to reflect the amount of time required to test, document and address
any issues that arise prior to moving on to the next stage.
Unit
Testing
Scenario
Testing
Systems
Integration
Testing
User
Acceptance
Testing
System
Ready
Go Live
Due by Oct 2015
Due by Nov 2015
Due by
2nd quarter 2016
Due by
3rd quarter 2016
Due by
3rd quarter 2016
Due for 2017/18
Budget Process
Non-Functional Requirement Testing
Performance Testing, Accessibility Testing,
Security & Vulnerability Testing,
Failover & Availability Testing,
Connectivity & Desktop Compatibility Testing
Core Testing Stages
(due dates include contingency)
Due by 3rd quarter 2016
Further information and support
If you have any questions or concerns please contact CBMS-R:
Internet:
CBMS Redevelopment Project
Email:
CBMS Redevelopment
Phone:
02 6215 3988
CBMS-R Project FACT SHEET - Testing |
2
Download