Hit any key to continue Some

Hit any key to continue! • • Some test text Some more test text Blah blah Blah black sheep

Software Testing EBS Computer Services Ltd

Part Two Implementation

The story so far… • Our fictitious software development company, the Mega. Hard Corporation, have developed a business software package. • The sales team have found a customer who wants to buy the package. • However, it needs to have some changes to fit in with their existing systems. • The client now faces the implementation challenge…

Business Objectives • Verify business requirements are met by the product and any associated changes • Make sure that the product is can be used by the staff at implementation • Minimise future support costs • Ensure quality at launch

However… • Estimating on software projects ranges from poor to unbelievably bad • The budget will always run out • People make mistakes • Someone will always want to change the design or objectives • The launch date is always politically motivated and cannot be moved

How to succeed • • Start testing early Ensure testing has a high priority Record and resolve all errors Develop test plans that simulate all required business activities and execute them rigorously using user testers under business-like conditions • Don’t just repeat the suppliers’ system testing • Don’t over-test

Why do I need to test? It is virtually impossible for a software developer to foresee how the customer will really use a program. Instructions for use may be misinterpreted; strange combinations of data may be used and output that seems clear to the tester may be unintelligible to a user in the field. Roger S. Pressman. Software Engineering – A practitioner’s approach

Test Objectives • Verify that the components required to execute the business processes are in place and have been implemented correctly • Confirm that all systems processes can be executed as in production • Minimise the risk of failure in the systems when they are implemented. Make certain it will work on day one!

Test Stages Analysis Coding Unit Test System Test Technical Acceptance Project Plan User Acceptance

Test stages • • • Technical Test User Acceptance Test Finance Test Model Office Implementation Test

Launch

The small print Supplementary slides containing the detail from the test stage summary slide.

Technical Acceptance 1. Base functionality assumed to be system tested 2. All changes verified in Technical Acceptance 3. Tests validate functional designs 4. Checklists validate screen functionality 5. Areas with excessive errors will be rejected 6. All problems detected will be recorded 7. Test stage exits when: 4 All functionality has been delivered All test cases have been executed 4 All errors have been resolved. 4

Technical Acceptance Test environment • • All code changes to be verified here Use data created using I+ Batch processing scheduled by test team Tests executed by technical test team.

User Acceptance • • • Test conditions are business processes Tests designed and executed by business users Test systems run as in production Documentation and results retained for audit All problems detected will be recorded Test stage complete when: 4 4 4 All test conditions have been executed All errors have been resolved Business managers agree implementation.

User Acceptance Test environment • • • Use data converted from production Normal daily operating schedule Executed by operations staff All batch processing run No paper unless necessary External interfaces Inbound are simulated as required Outbound verified by printed report.

Finance Acceptance • Objective – Validate that, by running the system in real time and with closely controlled data, that the financial and audit requirements of the system are correctly implemented • Exit criteria – All planned tests have been executed – No major defects remain and an agreed plan is in place for the resolution of low severity problems

Finance Acceptance Testing • Test that the financial controls and interfaces to other systems are correct • This is done by writing detailed test scripts that exercise all the financial operations of the system which are executed by experienced finance personnel with systems staff support • Defects are recorded formally across the project for quality analysis and planning purposes

Model Office • Objective – Validate that, by running the system in real time and with real data, that the systems, user training and associated infrastructure are ready for production • Exit criteria – All major business processes have been exercised, user training has been proven , and integration with outside services is complete. No major defects to be resolved

Model Office Testing • Verify that the business operation is capable of supporting live running • This is done by creating test scripts that describe business events from the customer view, using real data and in real time • Defects are recorded formally across the project for quality analysis and planning purposes

Software Testing EBS Computer Services Ltd