Be More Salmon - Testbash
•Télécharger en tant que PPTX, PDF•
1 j'aime•352 vues
Slides from my "Be More Salmon" talk at Testbash Manchester. This version really focuses on the "shared documents do not equal shared understanding" idea from Jeff Patton
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (17)
Similaire à Be More Salmon - Testbash
Similaire à Be More Salmon - Testbash (20)
Dernier
Dernier (20)
Be More Salmon - Testbash
- 2. Duncan Nisbet Software Testing Guide duncannisbet.co.uk @DuncNisbet
- 3. Why Salmon?
- 13. The argument… Shared documentation != Shared understanding
- 14. The argument… Shared documentation ≠ Shared understanding
- 15. The argument… Shared documentation <> Shared understanding
- 16. The argument… Shared documentation does not equal Shared understanding
- 18. The argument… • Shared docs do not equal shared understanding • Misunderstanding results in incorrect assumptions • Incorrect assumptions result in an undesired product
- 19. The conclusion… • Testing is asking questions to squash assumptions • The earlier we ask questions, the sooner we can squash assumptions, provide fast feedback & have a greater chance of delivering the desired product first time
- 21. ?
- 22. ?
- 25. Expected (required system) Actual (delivered system) James Lyndsay’s #1 diagram of testing
- 26. Expected (required system) Actual (delivered system) James Lyndsay’s #1 diagram of testing
- 27. Expected (required system) Actual (delivered system) Test Driven Development Test First Development
- 28. Expected (required system) Actual (delivered system) Need BDD 3 Amigo sessions Frequent releases Small batches Test Driven Development Test First Development
- 29. Design Of Everyday Things – Donald Norman
- 31. Dream Requirements Design Build How can I test upstream?
- 33. Dream Requirements Design Build As a … I want … So that …
- 34. Dream Requirements Design • Question the product • Break illusions • Feedback information
- 35. Dream Requirements Build • Discuss testability • Understand the design patterns • Understand the implications
- 36. Dream Design Build • Discuss testability • Squash assumptions • Make the implicit explicit
- 37. Requirements Design Build • Question the idea of the product • Understand the need • Understand the why
- 40. Dream Requirements Design Build Dream Requirements Design Build
- 41. Dream Requirements Design Build Dream Requirements Design Build Dream Requirements Design Build
- 42. Dream Requirements Design Build Dream Requirements Design Build Dream Requirements Design Build Dream Requirements Design Build
- 43. Dream Requirements Design Build Dream Requirements Design Build Dream Requirements Design Build Dream Requirements Design Build Dream Requirements Design Build
- 45. Understand
- 46. Assumptions
- 52. Continuous
- 55. END
- 56. Many thanks to: Leigh Rathbone & the SD gang, Chris Thacker, Dan Ashby, Ash Winter, Gwen Diagram, Mark Winteringham & of course Mrs Nisbet duncannisbet.co.uk @DuncNisbet Feedback : http://bit.ly/TestbashSalmon
Notes de l'éditeur
- 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
- Salmon swim upstream to spawn In this analogy, I liken the idea of salmon leaping up waterfalls to testers leaping out of their test phase, so they can provide value earlier in the development lifecycle. Although the analogy came to me whilst working with teams in a waterfall context, the idea is to be development lifecycle agnostic.
- Software is currently written by humans, generally for humans We each bring our own background stories, ideas & biases to our development team & these have a major impact on how we work together & ultimately deliver software – this means the situation, or context, we work in changes for each project we are involved in. We use past experiences & ideas to fill in gaps in the messages we receive & this sometimes leads us to the wrong conclusions
- I should imagine that the majority of you have leapt to a conclusion about what the missing letter is. What about if I add some colour?
- This is confirming your thoughts, I am right? A bit more colour…
- That’s sealed the deal hasn’t it
- Hands up who had DICTIONARY? These are the colours of the Oxford English Dictionary Hands up who had something different? What about if I take some of the colours away & start on a different path..
- Lets add a white rectangle
- Is this ringing any bells with anyone?
- Lets play Pictionary! LEAVE THIS SLIDE UP WHILST WE PLAY PICTIONARY
- 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”
- Need 2x 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
- Even though you’re reading the same document, the way you interpret it will be different from another person reading the same document & even the person who wrote it!
- 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 to discover where the delivered actual delivered software either meets or misses expectations. Where the delivered software misses expectations, we need to explore the behaviour & impact of the unexpected software.
- Programming practices in Agile have done wonders to help deliver software that more closely meets expectations, but they’re still not challenging the expectations to see if the delivered solution solves the problem
- We need to understand if the delivered solution fulfils the need & solves the problem. We can do this through close collaboration to ensure we fully understand what the need or problem is before we start developing the solution.
- Opening train doors on the outside – why? Central locking was not introduced until 1970’s – before this time the doors could be opened by anyone at any time. I liken this to us as Testers getting our hands on the software & asking “why does it do this? It doesn’t make sense” It made sense to someone at some point, we just weren’t privy to the conversation. Design of Everyday Things https://www.amazon.co.uk/Design-Everyday-Things-revised-expanded/dp/0262525674 https://en.wikipedia.org/wiki/Slam-door_train
- In a staged delivery cycle like Waterfall, the software flows downstream with the majority of testing occurring on the build This is typically where most testing occurs – we ask questions of the software itself
- Activities in each stage are typically completed by particular roles
- We should have much closer collaboration, with different roles completing different aspects of the tasks. Specifically, testing tasks shouldn’t be left until the end. If testing is asking questions of a product / system, you can ask different questions at different stages of the lifecycle
- Testing is less linear in agile. Reduce the size of the work so you can complete it in a shorter time frame – chunk down
- Spread your testing across the entire development cycle. Start testing sooner in the iteration, avoid all testing at end Break your development / testing activities down into smaller chunks
- Spread your testing across the entire development cycle. Start testing sooner in the iteration, avoid all testing at end Break your development / testing activities down into smaller chunks
- Spread your testing across the entire development cycle. Start testing sooner in the iteration, avoid all testing at end Break your development / testing activities down into smaller chunks
- Spread your testing across the entire development cycle. Start testing sooner in the iteration, avoid all testing at end Break your development / testing activities down into smaller chunks
- Spread your testing across the entire development cycle. Start testing sooner in the iteration, avoid all testing at end Break your development / testing activities down into smaller chunks
- In conclusion
- Start with the WHY to understand the need / problem
- We test dispel any illusions about what the system may or may not be doing
- Understand what the right thing to solve the problem is before launching into development “There’s nothing more wasteful than building the wrong thing right” to paraphrase Drucker
- Reduce the size of the work products
- Aim to start testing as early as possible in the development lifecycle – you don’t need to wait for software to be delivered to a test environment to start testing
- Discover & call out your pain points sooner rather than later so that you can react accordingly – do the hard stuff first.
- Get information back to decision makers as soon as possible
- Strive to test at each stage of the development cycle – there’s always some testing that can be performed somewhere
- 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”