Download presentation source

349 views

Published on

  • Be the first to comment

  • Be the first to like this

Download presentation source

  1. 1. Hit any key to continue! <ul><li>Some test text </li></ul><ul><li>Some more test text </li></ul><ul><li>Blah blah blah </li></ul><ul><li>Blah blah black sheep </li></ul>
  2. 3. Software Testing EBS Computer Services Ltd Steve Portch
  3. 4. Part Two Implementation
  4. 5. The story so far… <ul><li>Our fictitious software development company, the MegaHard Corporation , have developed a business software package. </li></ul><ul><li>The sales team have found a customer who wants to buy the package. </li></ul><ul><li>However, it needs to have some changes to fit in with their existing systems. </li></ul><ul><li>The client now faces the implementation challenge… </li></ul>
  5. 6. Business Objectives <ul><li>Verify business requirements are met by the product and any associated changes </li></ul><ul><li>Make sure that the product is can be used by the staff at implementation </li></ul><ul><li>Minimise future support costs </li></ul><ul><li>Ensure quality at launch </li></ul>
  6. 7. However… <ul><li>Estimating on software projects ranges from poor to unbelievably bad </li></ul><ul><li>The budget will always run out </li></ul><ul><li>People make mistakes </li></ul><ul><li>Someone will always want to change the design or objectives </li></ul><ul><li>The launch date is always politically motivated and cannot be moved </li></ul>
  7. 8. How to succeed <ul><li>Start testing early </li></ul><ul><li>Ensure testing has a high priority </li></ul><ul><li>Record and resolve all errors </li></ul><ul><li>Develop test plans that simulate all required business activities and execute them rigorously using user testers under business-like conditions </li></ul><ul><li>Don’t just repeat the suppliers’ system testing </li></ul><ul><li>Don’t over-test </li></ul>
  8. 10. Why do I need to test? <ul><li>It is virtually impossible for a software developer to foresee how the customer will really use a program. </li></ul><ul><li>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. </li></ul>Roger S. Pressman. Software Engineering – A practitioner’s approach
  9. 11. Test Objectives <ul><li>Verify that the components required to execute the business processes are in place and have been implemented correctly </li></ul><ul><li>Confirm that all systems processes can be executed as in production </li></ul><ul><li>Minimise the risk of failure in the systems when they are implemented. </li></ul>Make certain it will work on day one!
  10. 12. Test Stages Project Plan User Acceptance Analysis Coding Unit Test System Test Technical Acceptance
  11. 13. Test stages <ul><li>Technical Test </li></ul><ul><li>User Acceptance Test </li></ul><ul><li>Finance Test </li></ul><ul><li>Model Office </li></ul><ul><li>Implementation Test </li></ul>
  12. 14. Launch
  13. 15. The small print Supplementary slides containing the detail from the test stage summary slide.
  14. 16. Technical Acceptance <ul><li>Base functionality assumed to be system tested </li></ul><ul><li>All changes verified in Technical Acceptance </li></ul><ul><li>Tests validate functional designs </li></ul><ul><li>Checklists validate screen functionality </li></ul><ul><li>Areas with excessive errors will be rejected </li></ul><ul><li>All problems detected will be recorded </li></ul><ul><li>Test stage exits when: </li></ul><ul><ul><li>All functionality has been delivered </li></ul></ul><ul><ul><li>All test cases have been executed </li></ul></ul><ul><ul><li>All errors have been resolved. </li></ul></ul>
  15. 17. Technical Acceptance <ul><ul><li>All code changes to be verified here </li></ul></ul><ul><ul><li>Use data created using I+ </li></ul></ul><ul><ul><li>Batch processing scheduled by test team </li></ul></ul><ul><ul><li>Tests executed by technical test team. </li></ul></ul>Test environment
  16. 18. User Acceptance <ul><li>Test conditions are business processes </li></ul><ul><li>Tests designed and executed by business users </li></ul><ul><li>Test systems run as in production </li></ul><ul><li>Documentation and results retained for audit </li></ul><ul><li>All problems detected will be recorded </li></ul><ul><li>Test stage complete when: </li></ul><ul><ul><li>All test conditions have been executed </li></ul></ul><ul><ul><li>All errors have been resolved </li></ul></ul><ul><ul><li>Business managers agree implementation. </li></ul></ul>
  17. 19. User Acceptance <ul><ul><li>Use data converted from production </li></ul></ul><ul><ul><li>Normal daily operating schedule </li></ul></ul><ul><ul><li>Executed by operations staff </li></ul></ul><ul><ul><li>All batch processing run </li></ul></ul><ul><ul><li>No paper unless necessary </li></ul></ul><ul><ul><li>External interfaces - </li></ul></ul><ul><ul><ul><li>Inbound are simulated as required </li></ul></ul></ul><ul><ul><ul><li>Outbound verified by printed report. </li></ul></ul></ul>Test environment
  18. 20. Finance Acceptance <ul><li>Objective </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Exit criteria </li></ul><ul><ul><li>All planned tests have been executed </li></ul></ul><ul><ul><li>No major defects remain and an agreed plan is in place for the resolution of low severity problems </li></ul></ul>
  19. 21. Finance Acceptance Testing <ul><li>Test that the financial controls and interfaces to other systems are correct </li></ul><ul><li>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 </li></ul><ul><li>Defects are recorded formally across the project for quality analysis and planning purposes </li></ul>
  20. 22. Model Office <ul><li>Objective </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Exit criteria </li></ul><ul><ul><li>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 </li></ul></ul>
  21. 23. Model Office Testing <ul><li>Verify that the business operation is capable of supporting live running </li></ul><ul><li>This is done by creating test scripts that describe business events from the customer view, using real data and in real time </li></ul><ul><li>Defects are recorded formally across the project for quality analysis and planning purposes </li></ul>
  22. 24. Software Testing EBS Computer Services Ltd Steve Portch

×