Your SlideShare is downloading. ×
Download presentation source
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Download presentation source


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Hit any key to continue!
    • Some test text
    • Some more test text
    • Blah blah blah
    • Blah blah black sheep
  • 2.  
  • 3. Software Testing EBS Computer Services Ltd Steve Portch
  • 4. Part Two Implementation
  • 5. The story so far…
    • Our fictitious software development company, the MegaHard 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…
  • 6. 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
  • 7. 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
  • 8. 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
  • 9.  
  • 10. 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
  • 11. 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!
  • 12. Test Stages Project Plan User Acceptance Analysis Coding Unit Test System Test Technical Acceptance
  • 13. Test stages
    • Technical Test
    • User Acceptance Test
    • Finance Test
    • Model Office
    • Implementation Test
  • 14. Launch
  • 15. The small print Supplementary slides containing the detail from the test stage summary slide.
  • 16. Technical Acceptance
    • Base functionality assumed to be system tested
    • All changes verified in Technical Acceptance
    • Tests validate functional designs
    • Checklists validate screen functionality
    • Areas with excessive errors will be rejected
    • All problems detected will be recorded
    • Test stage exits when:
      • All functionality has been delivered
      • All test cases have been executed
      • All errors have been resolved.
  • 17. Technical Acceptance
      • All code changes to be verified here
      • Use data created using I+
      • Batch processing scheduled by test team
      • Tests executed by technical test team.
    Test environment
  • 18. 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:
      • All test conditions have been executed
      • All errors have been resolved
      • Business managers agree implementation.
  • 19. User Acceptance
      • 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.
    Test environment
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. Software Testing EBS Computer Services Ltd Steve Portch
  • 25.