Successfully reported this slideshow.
Your SlideShare is downloading. ×

Testing! Be More Salmon! - Agile North

Ad

Duncan Nisbet
Software Test Coach
duncannisbet.co.uk
@DuncNisbet

Ad

Feedback

Ad

The conclusion…
Shared documentation
!=
Shared understanding

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Loading in …3
×

Check these out next

1 of 47 Ad
1 of 47 Ad
Advertisement

More Related Content

Advertisement

Testing! Be More Salmon! - Agile North

  1. 1. Duncan Nisbet Software Test Coach duncannisbet.co.uk @DuncNisbet
  2. 2. Feedback
  3. 3. The conclusion… Shared documentation != Shared understanding
  4. 4. The conclusion… Shared documentation ≠ Shared understanding
  5. 5. The conclusion… Shared documentation <> Shared understanding
  6. 6. The conclusion… Shared documentation does not equal Shared understanding
  7. 7. “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
  8. 8. The premises… • Shared docs do not equal shared understanding • Misunderstanding results in incorrect assumptions • Incorrect assumptions result in an undesired product
  9. 9. 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
  10. 10. Shared understanding
  11. 11. ?
  12. 12. ?
  13. 13. The dice product challenge • You are the development team creating fantastic dice shaped products • Team: • Product Owner • Business Analyst • Developer • Tester
  14. 14. 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!
  15. 15. Round 2 – 15 minutes • Everyone can ask questions of Everyone • The PO can accept parts of the product
  16. 16. 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
  17. 17. Expected (required system) Actual (delivered system) James Lyndsay’s #1 diagram of testing
  18. 18. Expected (required system) Actual (delivered system)
  19. 19. Expected (required system) Actual (delivered system) Test Driven Development Test First Development
  20. 20. Expected (required system) Actual (delivered system) Need 3 Amigo sessions Frequent releases Small batches Test Driven Development Test First Development
  21. 21. Dream Requirements Design Build How can I test upstream?
  22. 22. Dream Requirements Design Build • Question the product • Break illusions • Feedback information
  23. 23. Dream Requirements Design Build • Discuss testability • Understand the design patterns • Understand the implications
  24. 24. • Make the implicit explicit • Discuss testability • Squash assumptions Dream Requirements Design Build
  25. 25. • Question the idea of the product • Understand the need • Understand the why Dream Requirements Design Build
  26. 26. Feedback Squash Assumptions Discover Information Feedback
  27. 27. Key takeaways Starting testing early helps: • Challenge assumptions early • Reduce size of work products • Deliver value sooner
  28. 28. Duncan Nisbet Software Test Coach duncannisbet.co.uk @DuncNisbet
  29. 29. END
  30. 30. Agile Manifesto
  31. 31. Agile Manifesto
  32. 32. • Eliminate waste • Amplify learning • Defer commitment • Deliver as fast as possible • Empower the team • Build integrity in • See the whole
  33. 33. 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?

×