Agile Testing

2,476
-1

Published on

dbg Agile Testing Presentation, demonstrating the use of Test Charters, Exploratory Testing, Session Based Testing and Testing Tours. With thanks to James Bach, Lisa Crispin, Janet Gregory and James Whittaker

Published in: Technology, Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,476
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
55
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Fixing a bug in a Live Environment can cost 10 to 100 times the amount in lost business, development effort and technical cost in Live, than if it is found in the Development or Testing Phases. Generally, if a defect is found later in the release schedule it is going to be more expensive to fix down the line. This is an critical factor in pretty much all IT projects, but is perhaps more keenly felt in more traditional waterfall projects where a fix deadline, payment milestones or SLA’s are not met.
  • Mars Climate Orbiter failed partly due to a software error where the thrusters that controlled the rate of descent where expecting data in Metric (newtons), but was supplied in Pound Force (the standard US measurement) NASA LOST £125 million
  • Agile Testing

    1. 1. Introduction to Agile Testing www.dbg.co.uk Prepared by Daniel Billing PUBLIC
    2. 2. Agenda • Why Test? – Some Questions – The Cost of Testing • Agile Testing Techniques • Workshop – Testing Tours
    3. 3. A few questions? • QA and Testing is all about asking questions, so here are a few for you to think about... – Why Test? – What do you believe Testing is? – What do you believe Testing should be? – What are your problems with Testing? – What could be done to improve the process of Testing?
    4. 4. 0 20 40 60 80 100 120 Cost of Fixing Bugs The Cost of Testing
    5. 5. The Cost of Testing
    6. 6. The Cost of Not Testing (or doing enough)
    7. 7. Agile Testing Techniques
    8. 8. Features of Agile Testing • Technique agnostic • Flexible and rapid – reduce the feedback loop • Should be continuous, ideally using a robust automated framework • No longer a ‘testing phase’, where code is thrown over the Testing fence • Testers are no longer ‘Quality Police’ • Providing information and suggestions on quality • Integration with the development process • Reusable, lightweight documentation styles and tools
    9. 9. Agile Testing Techniques • TDD (Test Driven Development) • Automated Functional Testing • Exploratory Testing – Session Based Testing – Test Charters – Testing Tours
    10. 10. Exploratory Testing • Manual • Simultaneous learning, test design and execution • Cognitive engagement with the process • Use of deductive reasoning • Less preparation up front, important bugs are found quickly • Can be difficult to measure/quantify – "a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.“ Cem Kaner
    11. 11. Test Charters • A way of recording Exploratory Testing effort • Defining a mission statement for testing – a statement of test objectives • Capturing test metrics
    12. 12. Session Based Testing • Developed by James Bach www.satsifice.com • Combines Exploratory Testing with some accountability • A fixed, uninterrupted period of time spent testing – no more than two hours • Clear focus • Includes Test Session information: – Charter. – Area tested. – Detailed notes on how testing was conducted. – A list of any bugs found. – A list of issues (open questions, product or project concerns) – Any files the tester used or created to support their testing – Percentage of the session spent on the charter vs investigating new opportunities. – Percentage of the session spent on: • Testing - creating and executing tests. • Bug investigation / reporting. • Session setup or other non-testing activities. – Session Start time and duration. • Debrief within the test team, and results parsing
    13. 13. Testing Tours • Developed by Dr James Whittaker – Formerly of Microsoft, now at Google – www.googletesting.blogspot.com • Uses a ‘Tourist’ analogy – Allows freedom to discover – Requires structure to ensure coverage – Uses ‘districts’ to allow testers to organise tests effectively • Business District – where things get done • Historical District – legacy code, out of date functions • Tourist District – areas that novice users (tourists) will be attracted to, but experienced users (citizens) won’t visit • Entertainment District – Nice to haves, and supportive features (once all the key features are tested) • Hotel District – where software is ‘at rest’, maybe background tasks, batch processes • Seedy District – Potential areas of vulnerability, ‘unsavoury’ functions and code
    14. 14. Testing Tours • The Guidebook Tour – doing everything that is in the handbook, down to the letter • The Money Tour – areas of the system that draw users, or have a high financial impact on the business; executing sales team demos against the software • The Landmark Tour – testing the key features • The Intellectual Tour – How do we make the software work as hard as possible? How do we stretch it to its limits? • The FedEx Tour – testing the software by focussing on data management • The After Hours Tour - Maintenance tasks, data back up and archiving, batch processing • The Garbage Collector Tour – Taking the shortest route possible to reach your goal, collecting ‘garbage’ as you go
    15. 15. Workshop
    16. 16. Testing Tours Workshop 1. Choose a Testing Tour 2. Choose a high profile web application to test 3. Plan your test charter – what are you going to test? 4. Run your tests – find bugs! 5. Record your test charter 6. Report back to the group
    17. 17. Testing Tours Workshop – The Test Tour you have chosen – Test Charter – What are you going to Test? Your testing mission statement! – Area tested. – What functionality is under test? – Detailed notes on how testing was conducted. – A list of any bugs found. – A list of issues (open questions, product or project concerns) – Any files the tester used or created to support their testing – Percentage of the session spent on the charter vs. investigating new testing opportunities – Percentage of the session spent on: • Testing - creating and executing tests. • Bug investigation / reporting. • Session setup or other non-testing activities. – Session Start time and duration. – Feedback to the Group at the end! IMPORTANT
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×