This is really a sister post to Ask Why?. If as a tester you’re given a task, or you’re briefed about a feature, or you’re learning about a new protocol, or anything. Stop. Assuming that you haven’t just been assigned custodianship of the entire universe, you’re starting with a box. The box has boundaries (in fact the better the person assigning you the task is at their job, the clearer those boundaries usually are) and you’re being pointed at the stuff inside the box and not worrying about the stuff outside the box.
Start off by stepping outside your box and looking in from the outside. Why is it here? Who cares about it? What do they want it to do? Is it self-consistent? Does it appear to behave sensibly? Just spending half an hour outside looking in and asking obvious questions gives you the chance to cheaply find the really big bugs, both in the product and your testing plans.
And these are exactly the sort of bugs that you won’t find by “testing harder”. They’re the ones where
- there’s a fundamental assumption in the spec that isn’t correct (“Won’t American cooks be confused by an oven that only goes up to 250 degrees?”)
- there’s been scope creep and extra function that isn’t needed (“The customer needs a cheese grater, why have we created an everything-grater with multiple detachable configurable blades?”)
- the testing you’re about to do is all invalid because you’re missing context (“Why is all our testing being done in GMT for this computer chip designed especially to work in Australia?”)
Do the step-back. Ask the questions. Save yourself days of time!