acceptance testing for rome

Download Acceptance Testing for ROME

Post on 25-May-2015

290 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

  • 1. Acceptance Testing for ROME Pete Castle Test & Quality Manager

2. Agenda

  • What is software testing/ Who does it?
  • Why software testing is important
  • Some fundamentals of testing
  • Test Plans & Scripts
  • Sample Testing Techniques

3. What is software Testing?

  • Software testing is anempirical technical investigationconducted to provide stakeholders with information about the quality of the product or service under testProfessor Cem Kaner-Director of Florida Tech's Center for Software Testing Education & Research
  • Empirical - derived from experiment, experience, and observation
  • Technical -Having special skill or practical knowledge
  • Investigation - A detailed inquiry or systematic examination

4. Why testing is Important

  • All Software has defects (bugs)
  • All software products are prototypes (in my view)
  • Software products are getting larger and more complicated - Vista 40% larger than XP @ over 50 million LOC
  • Software Engineering is not as mature as otherdisciplines e.g. Civil Engineering
  • Software is written by people people make mistakes
  • Software testing looks to find the most important defects as early as possible increasing confidence that the software meets specification

5. Whos involved in testing?

  • Requirements Analysts Inspections, Peer Reviews
  • Developers Code Inspection, Unit Testing
  • Testers System & Integration Testing
  • Trainers Training materials production
  • Users User Acceptance Testing
  • Project Managers Scheduling, Resourcing, Risks, Issues, Defect Stats
  • Everybody is responsible for quality - NASA

6. Fundamentals of Software Testing

  • Software testing needs planning, tests need specifying, once executed they need results recording, and post completion should be easily auditable

Plan Specify Execute Record Check 7. The importance of a planned approach

  • Important to map out a strategy that will give the greatest level of confidence in the product
  • Ad hoc testing may find errors, but may not be cost effective
  • Testing should focus on areas where defects are most likely
  • All testing should have a reason
    • Question Is a test that doesnt find an error a good test or not?
  • Essential to plan what needs to be done and then itemise how it is to be achieved.

8. Testing Mantra

  • Mantra - Spiritual conduit, words or vibrations that instil concentration in the devotee.
  • Test as early as possible
  • Gather as much knowledge of the application under test as possible
  • Look for vulnerabilities
  • Build Bug Taxonomies (Classification)
  • Use Quicktests (and publicise the fact)

9. Testing Mantra

  • You can always think of another test but should you ?
    • Concept of Good enough Testing
    • Practicality over dogma
    • Everybody has responsibility for shipping the product
  • Record all tests/defects/issues/recommendations
  • Testers are not the sole arbiters of quality
    • Testing only shows problems exist not their absence
  • Never,ever, evermake it personal
    • Defects are issues with products and process not people
    • Good working relationship is essential for good products

10. Document Hierarchy - Test Plan Test Policy Test Strategy Project Test Plan Unit Phase Integration Phase Acceptance Phase 11. What is a Test Plan - 1

  • Test plan is
    • tool to help plan the testing activity
    • product to inform others of test process
  • Includes
    • Document control
    • Objectives
    • Scope
    • Approach Schedule, Priorities, Deliverables, Resources, Responsibilities
    • Risks/Contingences
    • Sign-off/Approval

12. What is a Test Plan - 2

  • Produced by Test Lead/Project Manager
  • Published to Project/Programme
  • Not constrained by format living document
  • Enough information to be used by anyone to test the product

13. Rome Test Plan

  • Ready for review
  • Written by Tim Wells

14. Document Hierarchy -Test Scripts Test Policy Test Strategy Project Test Plan Unit Phase Integration Phase Acceptance Phase 15. Test Scripts

  • Test Script - Is a collection of test cases for the software under test (manual or automated)
  • Test Case - A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

16. Pre-conditions/Information

  • Browsers IE, Firefox, Safari
  • O/S Linux, Windows
  • Access Control Logins, Roles
  • Test Data requirements
  • Date/Time considerations
  • Other document references

17. Example Test Script - 1

  • System Test of input of numeric month into data field

Pass Data Accepted, June Displayed 06 Enter Data Month 003 005 004 002 001 Ref. Fail Data rejected. Error Message 'Invalid Month' 13 Enter Data Month Pass Data Accepted, December Displayed 12 Enter Data Month Pass Data Accepted, January Displayed 1 Enter Data Month Fail Data rejected. Error Message 'Invalid Month' 0 Enter Data Month Pass/Fail Expected Result Input Action Field/Button 18. Example Test Script - 2 Pass 61matches - paging working correctly, data displayed correctly and in reasonable time (5 secs) All UCL researchers with surnames starting Smith displayed in alphabetic order, 23 records per page List comprises Name, Department, Occupation Type All data items hyperlinked 1. Forenames = 2. Surname = Smith 3. eMail = Search Researchers REF003 2.002 Pass 427matches - paging working correctly, data displayed correctly and in reasonable time (5 secs) All UCL researchers with forenames starting Pete displayed in alphabetic order, 23 records per page List comprises Name, Department, Occupation Type All data items hyperlinked 1. Forenames = John 2. Surname = 3. eMail = Search Researchers REF003 2.001 Pass/Fail Actual Result Expected Result Inputs Function Reqs Ref. Test Ref. Search Researcher Page 19. Example Test Script - 3 SM SM SM SM SM Who 06/01/08 F Y Y Y Basic Licence Admissions - ASL Export to EMS 43 06/01/08 P Y Y Y Basic Licence Admissions - ADT Import from EMS 42 06/01/08 P Y Y Y Basic Licence Admissions - Admissions Policy 41 06/01/08 P Y Y Y Basic Licence Admissions - Criterion Setup 40 06/01/08 P Y Y Y Basic Licence Admissions - Setup Basic Licence Admissions Admissions 39 Date tested Pass/ FailCovered (Y/N) New/ Change? To test? Test Scenario Type No. 20. Test Scripts

  • Readable
  • Accessible
  • Usable by anyone standards
  • Can vary depending upon the type of testing being undertaken

21. Testing Techniques

  • Quicktests
  • Negative Testing
  • Integration Testing

22. Techniques 1- Quick Tests

  • Quicktests - Investigation more important than Confirmation
  • Aquicktestis a cheap test that has some value but requires little preparation, knowledge, or time to perform
  • Focus on common coding errors

23. Techniques 1- Quick Tests

  • Things that have failed before Defect data
    • Tab order (particularly when adding new functions)
    • Addresses (BFPO, new Post Codes)
    • Short cut keys
  • Boundaries Ages, Dates, Values, Increments, Page Breaks
  • Interrupts, Duplications, Ordering of tasks
    • Generate Order before setup no cost codes, cost centres, suppliers, budgets
    • Exit/Interrupt before completion
  • Consume resource (Dog Piling)
    • Never close a window
    • Never exit an option

24. Techniques 1- Quick Tests

  • Force all error messages
    • Informative messages - Spelling
    • Debug information?
  • Capacity/Files Files to fill all available space, large files, empty files, incorrect format
  • Dependencies e.g. same student many functions
    • Integration Quicktest
  • Comparisons screens, data, reports
    • Tools e.g. Beyond Compare, Screen Capture, Redgate Toolset, In