WELCOME TO BETA 2 CYCLE 1 TESTING 15 February 2008

1. WELCOME TO BETA 2 CYCLE 1 TESTING 15 February 2008

2. Objectives Approach Roles and responsibilities Defect logging process DTS – Defect Logs Key Definitions Defects Classification Guidelines CRS Classifications Guidelines Defect-Life Cycle CR Life Cycle Re-testing fixes Master Data issues – logging process “New” testers Agenda

3. Testing Objectives • First level of “end-to-end” testing of RMS functionality by the RMS Support Office and Subject Matter Experts. Testing includes external interfaces and reports • Limited to a select group of users so that major defects can be resolved before UAT

4. Approach • Testing to be conducted using the pre-defined test cases and test data and results of the testing to be documented on the test cases • Documented test cases will be used as evidence of outcome of the testing • Changes to the test cases are expected – these will be maintained by the test analysts and test cases will be updated for the next phase of testing – Beta 2 Cycle 2 (Note: Test Cases will be handed over from Testing Thread to RSO at start of Beta 2 Cycle 2 - TA’s will continue to support) • Changes to the test data are also expected – this will be managed by the TA’s

5. Approach – Enterprise set-up • Master Date to be captured into the system using templates provided • Checklist provided to give guidance for testing usability of the set-up screens • Please complete the checklist where tests were conducted as testing will use to complete the usability testing where necessary NOTE: Approach for testing on CORE (i.e using test cases) will be conducted at the start of CORE testing

6. Enterprise set-up - checklist

7. Roles and Responsibilities

8. Process for logging defects • Option A • Log defect on “defect logging” spreadsheet in consultation with the relevant Business Analyst or Testing Analyst • Defect to be reviewed, acknowledged and logged onto DTS by the relevant RMS Support Office representative • Option B • Defect logged directly onto DTS by the relevant RMS Support Office representative after consultation with the user, BA / TA.

9. Spreadsheet for logging defects Access file from Desktop: Folder Beta 2 Cycle 1 Documents - email to RSO representative

10. Defect Log • Object Info • Customer – Type of Testing • Application /Component - Components of RMS Application • Object Id / Activity - Activities of the selected Component in RMS • Additional Information • Type - i.e. Functionality Error, Change Requests, Issue for Discussion • Frequency – i.e. Intermittent, Occasional, One Time, Recurring • Severity - i.e. Critical, Not Critical, Show Stopper, and Trivial

11. Defect Tracking System (DTS) • Purpose • To Log and Track the defects / CR to closure • http://203.199.198.140/webdts

12. Defect Log contd.. • Defect Description • Record observation with sufficient information • Specify Sequence and User Actions (i.e. Task) in which the defect occurred • Specify the Data for which the defect occurred • Specify the Error Message, encountered, if any • Implication • Implication of the defect

13. Key Definitions - Defects • Defects are observations that are “bugs” in the application – i.e. application does not behave in line with the signed-off requirements (PFA, UI/BR, Report Specifications, Interface Specification, batch specification documents and Approved Change Requests). Examples include • Mandatory fields are not marked in BOLD. • Application does not fetch results based on the given Search Criteria, though matching records exist • The Charges, calculated by the application, are not in line with the specified Charges calculation logic / formula • Charges determined for services are not reflected in Billing • Combo does not load all the values defined • Key columns specified, are missing in the Report • Not all controls in the UI are elaborated in the Online Help **Documentation Source is as Base-lined by the functional thread

14. Key Definitions – Defect Classifications • Showstopper defect • A defect is classified as a Showstopper, if there is no other way to perform a required operation due to which subsequent test cases cannot be tested and no workarounds are also available. • Critical defect • Testing can continue but operating without this feature will cause severe disruption to business processes in live operations. • Non Critical defect • Both testing and live operations may progress. This problem needs to be corrected, but may have only a little or no disruption to business processes in live operations • Trivial • Both testing and live operations may progress. This problem may have some impact on the user experience of the application but not on the functionality. There is no disruption to the business processes because of this issue

15. Key Definitions – Change Request • Change Requests (CRs) are observations that call for a change in the application, as against the signed-off Requirements (PFA, UI/BR, Report Specifications, Interface Specification and Batch specification documents and Approved Change Request CR No:1). • Change Requests can originate from any of the following: • Requirement Gaps identified by the users when the application is seen in totality • Changes or enhancements to an External System which is interfaced • New Legislation • Change in business process within Council • Unspecified / Undocumented Requirements

16. Key Definitions – Change Request • Examples for a CR • New fields needs to be added in one of the existing screens • A new Activity / Report to be added • A task needs to be added in an existing UI • Non- Mandatory field (s) to be made mandatory • Change of check box to a Drop Down List Box. • Changing a display only field to a editable field • Increase in precision value for any of the fields / results

17. Key definitions – CR classification • GO-LIVE A Change Request is classified as “Go-Live” only if the functionality is: • Core to Business • Business may not run without this additional functionality • No workarounds to meet the business requirements Therefore change must be implemented, tested and functioning at the time of go-live • POST GO-LIVE A Change Request is classified as “Post Go-Live” if it is Core to Business but workarounds exists, and the change can be implemented after go-live

18. Key definitions – Issue for Discussion An observation is classified as an Issue for Discussion if • Discussion needs to initiated to clarify / understand the business requirement • Discussion is required to classify the observation as a Defect or as a Change Request Note: Discussions to be held during testing sessions where Practical – please liaise with testing thread managers to co- ordinate

19. Defect Life Cycle

20. CR – Life Cycle

21. Approach for re-testing fixes • The DTS will be reviewed daily and at the start of each testing session defects that have been fixed will need to be re-tested by the RSO

22. Master Data issues – logging process • Defect logged on DTS – classified as a data issue • RSO makes changes to the testing environment and if testing continues successfully – status updated on DTS • Data Thread reviews the defect, verifying with business where necessary • Data Thread updates templates and MDC environment

23. New testers • TA’s will provide testing overview in “”Buffalo Training Room” as and when required

24. Thank you – let the testing begin !!