Testing! Be More Salmon! - Agile North
•Download as PPTX, PDF•
0 likes•602 views
slide deck from my "Testing! Be More Salmon!" workshop which I ran at Agile North 2016
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Testing! Be More Salmon! - Agile North
Similar to Testing! Be More Salmon! - Agile North (20)
Recently uploaded
Recently uploaded (20)
Testing! Be More Salmon! - Agile North
- 2. Duncan Nisbet Software Test Coach duncannisbet.co.uk @DuncNisbet
- 3. Feedback
- 4. The conclusion… Shared documentation != Shared understanding
- 5. The conclusion… Shared documentation ≠ Shared understanding
- 6. The conclusion… Shared documentation <> Shared understanding
- 7. The conclusion… Shared documentation does not equal Shared understanding
- 8. “Let’s give our NHS the £350 million the EU takes every week’ and ‘We send the EU £350 million a week, let’s fund our NHS instead” Vote Leave Campaign, Brexit
- 9. The premises… • Shared docs do not equal shared understanding • Misunderstanding results in incorrect assumptions • Incorrect assumptions result in an undesired product
- 10. The argument… • Testing is asking questions to squash assumptions • The earlier we ask questions, the sooner we can squash assumptions • The sooner we test the greater chance we have of delivering the desired product first time
- 13. ?
- 14. ?
- 17. The dice product challenge • You are the development team creating fantastic dice shaped products • Team: • Product Owner • Business Analyst • Developer • Tester
- 18. Round 1 – 15 mins • BA - describe the product in words (requirements) • Dev – build the product from the requirements • Test – add up the spots on the touching sides • PO – accept or reject product • No talking!
- 19. Round 2 – 15 minutes • Everyone can ask questions of Everyone • The PO can accept parts of the product
- 20. Implicit requirements • 1 cube = 1 dice • All spots on top of the dice must be odd • Dice with the same number of spots on top cannot be next to each other • Red & blue dice cannot be touching • Red dice must be facing the PO • Each iteration of the product needs to have •same explicit requirements (i.e. shape as per image) •different patterns of spots that still adhere to the implicit requirements
- 22. Expected (required system) Actual (delivered system) James Lyndsay’s #1 diagram of testing
- 24. Expected (required system) Actual (delivered system) Test Driven Development Test First Development
- 25. Expected (required system) Actual (delivered system) Need 3 Amigo sessions Frequent releases Small batches Test Driven Development Test First Development
- 27. Dream Requirements Design Build How can I test upstream?
- 28. Dream Requirements Design Build • Question the product • Break illusions • Feedback information
- 29. Dream Requirements Design Build • Discuss testability • Understand the design patterns • Understand the implications
- 30. • Make the implicit explicit • Discuss testability • Squash assumptions Dream Requirements Design Build
- 31. • Question the idea of the product • Understand the need • Understand the why Dream Requirements Design Build
- 40. Key takeaways Starting testing early helps: • Challenge assumptions early • Reduce size of work products • Deliver value sooner
- 41. Duncan Nisbet Software Test Coach duncannisbet.co.uk @DuncNisbet
- 42. END
- 43. Agile Manifesto
- 44. Agile Manifesto
- 46. • Eliminate waste • Amplify learning • Defer commitment • Deliver as fast as possible • Empower the team • Build integrity in • See the whole
- 47. Round 2 – 12 mins • BA – can ask questions of PO • Dev – can ask questions of BA • Test – can ask questions of Dev • PO – accept or reject product • Yes / No questions only
Editor's Notes
- Image credit http://www.visitwales.com/explore/wildlife-fauna/top-wildlife-days-out Tongue-in-cheek look at testing in an agile development cycle Its not only testers who test Facilitators notes Product Owners notes
- http://metro.co.uk/2016/06/27/heres-all-the-leave-campaigners-whove-backtracked-on-the-nhs-350m-promise-5969165/#ixzz4Cymy0OrP
- Just because we write something down, it doesn’t mean everyone will interpret it the same. e.g. memorable word validation – “word must not contain more than 3 repeating characters” Block of truth – 2 volunteers
- Volunteer 1 – what’s the shape behind the explosion casting the shadow? Write your answer down
- Volunteer 2 – what’s the shape behind the explosion casting the shadow? Write your answer down
- The big reveal!
- The PO has a vision of their product & it’s up to you to realise their vision. The BAs will have a representation of the vision which need to translate into product requirements The Developer will need to build the product from the requirements The Tester will ask questions of the product The PO will need to determine if they accept the delivered product or not based on their requirements
- 20 minutes with wrap up & discussion 1 role per table – silos of roles Round 1 Requirements gathering write down build instructions for product from picture no talking think about what questions you might ask Build & test build product from instructions test product by adding up touching sides No talking think about what questions you might ask Acceptance Demo built product to PO Accepted? (unlikely) No talking think about what questions you might ask Wrap up round 1 What was that like for you … PO? … tester.? … programmer? … BA? What would you like to do differently? Why? Have you got all the requirements you need?
- 20 minutes with wrap up & discussion 1 table per product – cross functional teams Round 3 Requirements gathering write down build instructions for part of product from picture Can ask yes / no questions of anyone Build & test build product from instructions test product by adding up touching sides Can ask yes / no questions of anyone Acceptance Demo built product to PO Accepted? Can ask yes / no questions of anyone Wrap up round 2 How was different to round 2 for you? … PO? … tester.? … programmer? … BA? Any more products delivered? What kind of implicit requirements did you discover?
- Core ideas Not all requirements are written down - they’re implicit Implicit requirements exist because we suck at defining everything we need / want upfront Getting software in front of the Product Owner sooner enables to say “that’s not what I want” - next thing out of their mouth will be what they want In order to get the software in front of the PO sooner, we need to deliver smaller chunks of work In order to deliver smaller chunks of work, we can’t batch our work up in a test environment We need to spread our testing throughout the development lifecycle Testing is testing, Agile is the context Testing is easier in smaller batches Forget defect prevention over defect detection We’re aiming to detect defects earlier Tester’s don’t typically prevent defects You can’t prevent a defect you haven’t detected
- James Lyndsay (Workroom Productions) http://www.workroom-productions.com/papers/SWT%20diag%201.pdf http://www.workroom-productions.com/papers/Exploration%20and%20Strategy.pdf http://testsidestory.com/2010/06/29/collateral-features/ testing & checking
- We test software to discover the true state of the system being developed
- We test dispel any illusions about what the system may or may not be doing
- http://agilemanifesto.org/
- http://agilemanifesto.org/principles.html
- https://en.wikipedia.org/wiki/Lean_software_development
- Round 2 Requirements gathering write down build instructions for part of product from picture Can ask yes / no questions of PO Build & test build product from instructions test product by adding up touching sides No talking Can ask yes / no questions of BA Acceptance Demo built product to PO Accepted? (unlikely) Can ask yes / no questions of PO Wrap up round 2 How was different to round 1 for you? … PO? … tester.? … programmer? … BA? Any more products delivered?