1. Focusing exploratory testing on capabilities instead of features leads to deeper insights and prevents tunnel vision.
   1. When exploring user stories, try to focus on the user value part (‘In order to…’) rather than the feature description (‘I want …’)
2. Nine emotions heuristic "shaded figs"
   1. The scary path– if this path was followed it would really tear the house down, and everything else with it
   2. The happy path – the key example, positive test, that de scribes the straightforward case.
   3. The angry path – with the angry path we are looking for tests which we think will make the application react badly
   4. The delinquent path– consider the security risks that need testing
   5. The embarrassing path – think of the things that, should they break, would cause huge embarrassment all round.
   6. The desolate path – provide the application or component with bleakness.
   7. The forgetful path– fill up all the memory and CPU capacity so that the application has nowhere left to store anything.
   8. The indecisive path– simulate being an indecisive user, unable to quite settle on one course of action
   9. The greedy path– select everything
   10. The stressful path– find the breaking point of the functions
   11. for specification workshops
3. When planning your testing activities, look at the competition for inspiration
   1. the cheapest mistakes to fix are the ones already made by other people
   2. look for patterns and categories rather than individual problems
      1. try to identify similar categories of problems in your software that could be caused by the same root causes
4. Breaking down complex examples into several smaller and focused groups leads to more modular software, which reduces future maintenance costs
   1. Look for missing concepts
   2. Group by commonality and focus only on variations
   3. Split validation and processing
   4. Summarize and explore important boundaries
5. Don’t describe how you will be testing something, keep the discussion focused on what you want to test instead
   1. It’s much faster to discuss what needs to be done instead of how it will be tested in detail
   2. focused on what needs to be tested
6. Apply a three-layer approach to automation
   1. Divide business-oriented decisions, workflows and technical interactions into separate layers
7. Decouple coverage from purpose
   1. Thinking about coverage and purpose as two separate dimensions helps teams reduce duplication between different groups of tests, and leads to more focused, faster automation
   2. Decide on purpose first, and let the purpose drive the choice of the format in which you capture the test
   3. Business-oriented tests should be written in a language and format that allows teams to discuss potential problems with business domain experts
8. Make developers responsible for checking
   1. When the same people are responsible for implementing and changing code and automating the related tests, tests are generally automated a lot more reliably and execute much faster
9. Book: "Fifty Quick Ideas To Improve Your Tests"
   1. twitter: @gojkoadzic @TommRoden and @DavidEvans66
   2. https://www.amazon.com/Fifty-Quick-Ideas-Improve-Tests-ebook/dp/B00XVFFK7E