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