From Monday Momentum, adapted for readers outside my team.
Most testing asks whether the software did what the story said. Empathetic testing asks a harder question: did it work for the person who needed it, in the situation they were actually in?
In Full Stack Testing, Gayathri Mohan names empathetic testing as one of seven first principles of testing: see the product through the eyes of the people who rely on it. Acceptance criteria are a starting point, not the finish line.
Get closer to the user earlier
Much of that understanding forms in design and prototyping sessions, which usually belong to product managers, product owners and designers. Quality and technical leads should ask to join them, then carry the user’s view back to the rest of the team.
When user needs collide with complexity or deadlines, testing should bring the user’s perspective forward, challenge assumptions, and make the human impact of the trade-off visible.
Try this
Before calling one story done, look through three lenses:
- Person: who is trying to accomplish what?
- Context: what pressure, device, environment or missing knowledge are they carrying?
- Consequence: if the design confuses or blocks them, what happens next?
Turn one discovery into something durable: an acceptance criterion, a test, a clearer error, or telemetry that shows the user’s outcome.
One guardrail
Empathy is not guesswork. Ground it in customer conversations, internal feedback, support requests, observed workflows and production evidence, and label what is still an assumption.
A feature is not done when it passes its tests. It is done when it works for the person who needs it.
Related: Test at the lowest level