The QA Mindset

A developer demos Basketly's new quantity box: type 3, press Update, the cart shows 3. "Works!" they say. A tester watches the same demo and thinks: what if I type 0? What if I press Update twice? What if my train enters a tunnel halfway? That difference in the questions you ask is the QA mindset.

The rule

Ask "how could this break?" before "does it work?"

A builder's natural question is "does it work?" and a single happy example answers it. A tester's first question is "how could this break for a real person?" and that needs many examples, most of them unhappy.

The mindset has four parts:

• Curiosity: you want to know what really happens, not what should happen.
• Healthy scepticism: "it works on my machine" is a claim, not evidence.
• User empathy: real people are tired, rushed, on slow phones and prone to double-tapping.
• Constructive voice: you attack the product, never the person. A good bug report describes behaviour and impact, and helps the team fix it.

That last point matters as much as the first three. A tester who finds great bugs but reports them rudely makes developers defensive, and defensive teams hide problems.

The shortcut

Run every input through the five what-ifs: Nothing, Too much, Wrong, Twice, Interrupted. Each one is a quick prompt for a family of failures.

The five what-ifs turn "try to break it" from a vague mood into a checklist you can run in two minutes on any field, button or flow.

Drills

Answer fast — trust the rule.

Remember

• Ask "how could this break?" before "does it work?"
• Five what-ifs: Nothing, Too much, Wrong, Twice, Interrupted.
• Attack the product, never the person.