Testing Mindset
The difference between a good tester and a great tester isn't tools or certifications. It's how they think. Learn the five mindset shifts that separate professionals from button-clickers.
1 The Hook
In 2019, a major NZ bank launched a new mobile app. The developers had written thousands of unit tests. The automation suite was green. But on launch day, customers discovered that if you tapped "Transfer" twice quickly, the app sent the money twice.
A developer's mindset asks: "Does the transfer feature work when used correctly?" A tester's mindset asks: "What happens if a real human uses this wrong?" The bank lost millions in reversal fees. One tester with the right mindset would have caught it in five minutes.
Tools change. The mindset doesn't.
2 The Rule
A tester's job is not to prove the software works. It's to find the ways it doesn't.
This sounds negative, but it isn't. Developers build. Testers protect. Both want the same outcome: quality software. The difference is the path to get there.
3 The Analogy
A bouncer at a nightclub.
The bouncer isn't there to ruin people's night. They're there to keep the venue safe. They check IDs, watch for trouble, and ask questions. A good bouncer is curious ("Why is that person nervous?"), sceptical ("Is this ID real?"), and user-focused ("Will this person's behaviour affect everyone else?"). A tester does the same for software.
4 Watch Me Do It
Here are the five mindset shifts every beginner needs to make. Read them. Then practise applying them.
🔄 1. Builder → Breaker
Developers ask: "How do I make this work?" Testers ask: "How could this fail?" When you look at a login form, don't just enter valid credentials. Enter nothing. Enter a SQL injection. Paste a novel into the password field. Copy-paste the email with a trailing space. The system should handle all of it gracefully.
🔍 2. Checker → Investigator
A checker follows a list and ticks boxes. An investigator follows curiosity. If the spec says "users can search by city," the checker searches for "Auckland" and moves on. The investigator searches for "ā" (macron), "auckland" (lowercase), "AUK" (abbreviation), and leaves it blank. Curiosity finds what checklists miss.
🧡 3. Developer Thinking → User Empathy
Developers know how the system is supposed to work. Real users don't. A stressed parent uses one hand on a phone at 11pm. A tradesperson wears gloves. A screen-reader user can't see your beautiful icons. Ask: "What would my grandmother do here?" If the answer is "get confused," that's a bug.
⚠️ 4. All Bugs Are Equal → Risk Thinking
Not every bug needs fixing immediately. A typo in the footer? Low risk. A payment button that double-charges? Critical. Ask four questions: How many users are affected? Can they lose money or data? Is it easy to reproduce? Will fixing it break something else? This is how you prioritise like a senior tester.
🤝 5. Blame → Collaboration
A bug is not a developer's failure. It's information. The best testers say: "I found an issue in the login flow. Here's exactly how to reproduce it. Let me know if you need help verifying the fix." Developers will seek you out. Toxic testers say: "Your code is broken." Developers will avoid them.
Real example: Observing actual user behaviour reveals the mindset in action
A tester watches a real user interact with a booking app. The user doesn't follow the spec. They scroll instead of clicking "Next". They use autocomplete wrong. They copy-paste an address with extra spaces. They hit submit twice because nothing happened (they missed the loading spinner). The tester's mindset shifts: "What would a real user do?" Every action the user took revealed a gap between expected behaviour and real behaviour.
5 When to Use It / When NOT to Use It
✅ Apply the mindset when...
- You first look at a new feature
- You are writing test cases
- You are doing exploratory testing
- You are reviewing requirements
- You are deciding what to test first
❌ Don't let it become...
- Cynicism ("Everything is broken")
- Perfectionism ("I must find every bug")
- Adversarial behaviour ("Us vs. Them")
- Paralysis ("There are too many possibilities")
Before you apply this technique, ask:
- Do you have time to think creatively about edge cases, or just run scripted tests?
- Are you testing a feature you trust, or one you're sceptical about?
- Do you understand the user's mental model of how this should work?
- Can you balance thorough thinking with moving forward quickly?
6 Common Mistakes
🚫 Thinking "finding bugs = being negative"
I used to think: Finding bugs meant I was criticising the developer.
Actually: Bugs are neutral information. The earlier you find them, the cheaper they are to fix. You're saving the team money and reputation.
🚫 Only testing the happy path
I used to think: If the feature works when I do everything right, it's fine.
Actually: Real users make mistakes. They mistype, click twice, refresh at the wrong time, and use old browsers. The happy path is the least interesting thing to test.
🚫 Treating every bug as critical
I used to think: Every bug I found was urgent.
Actually: A typo in an error message and a payment failure are not the same. Learn to assess risk. Report everything, but prioritise honestly.
🚫 Assuming developers will think like you
I used to think: The developer will automatically test all the edge cases I'm thinking of.
Actually: Developers focus on happy paths; they assume best-case scenarios. Your job is to think like the user who hits the edge cases.
When this technique fails
Testing mindset fails when you go into analysis paralysis and find so many edge cases that nothing ships. It also fails when you assume the user's mental model without actually watching a real user. The mindset is powerful, but balance curiosity with pragmatism. Focus on risky areas first.
7 Now You Try
Scenario: An NZ pizza delivery app has a "Reorder Last Order" button on the homepage. Apply the five mindset shifts. Write down one test idea for each shift.
Example for Shift 1 (Breaker): "What if the last order was from a restaurant that has since closed?"
Suggested test ideas:
| Shift | Test Idea |
|---|---|
| 1. Breaker | What if the last order was from a restaurant that has closed? |
| 2. Investigator | What if the user has never ordered before — what does the button do? |
| 3. User Empathy | What if the user is ordering for someone with a severe allergy — does it warn them? |
| 4. Risk Thinking | What if the old price is no longer valid — could the user be undercharged or overcharged? |
| 5. Collaboration | How would I report this if the reorder places the wrong address — what evidence do I need? |
Tip: There are no "right" answers here. The exercise is about generating questions, not finding the one true bug.
8 Self-Check
Click each question to reveal the answer.
Q1. Why is "user empathy" important for testers?
Real users are not like developers. They make mistakes, use old devices, and don't read instructions. Testing only the "correct" path misses how most people actually use software.
Q2. A developer says "nobody would ever do that." How should a tester respond?
"Users do unexpected things every day. Can we make sure the system handles it gracefully?" This is collaborative, not confrontational. It focuses on protection, not blame.
Q3. What's the danger of only testing the happy path?
You miss the bugs that affect real users. The happy path is what developers already tested. The value of a tester is finding what happens off the happy path.