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.
Senior engineer insight
The shift that stuck with me was realising that good testers don't just look for bugs — they build a mental model of how the system could be abused, misunderstood, or pushed to a boundary its authors never imagined. At KiwiFirst Bank I watched a colleague find a critical payment duplication bug not because she was following a test case, but because she noticed the submit button didn't disable on click and asked "what if the network is slow?" That question alone changed how the whole team approached UI state.
Most common grad mistake: adopting the language of scepticism ("I'm questioning everything!") without the discipline to focus that scepticism on risky areas first, so you spend two hours on cosmetic edge cases while a payment flow goes untested.
From the field
A QA team at a Wellington fintech had a new grad join mid-sprint. The team assumed she'd follow the test cases written for the happy path and flag any obvious failures. Instead, on her second day she asked why the Revenue NZ number validation accepted inputs with spaces — the spec said "numeric only" but nobody had tried copy-pasting from a PDF. Turns out most government documents insert a space between digit groups. The validation was silently rejecting legitimate Revenue NZ numbers for hundreds of customers filing on mobile, and everyone had missed it because every tester typed the number manually. The team rewrote their mobile test approach and started explicitly asking "what does real input data look like?" before writing a single test case.
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.
Why teams fail here
- Testers are onboarded as "script runners" — they're handed test cases on day one and never encouraged to question the requirements that produced them, so the investigative instinct is trained out early.
- Sprint pressure kills curiosity — when "done by Friday" is the metric, exploratory thinking feels like a luxury, so teams skip it and ship with only happy-path coverage.
- Adversarial culture between dev and QA means testers stop raising "what if" questions because they've been burned by responses like "that will never happen" — so the important edge cases stop being voiced.
- Grad testers mistake confidence for competence — they know the five mindset shifts intellectually but default back to comfortable checklist behaviour under pressure, because applying a mindset is harder than following a script.
Key takeaway
Your job isn't to prove the software works — it's to discover what the team hasn't yet imagined could go wrong, before a real user finds it for you.
8 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Testing Mindset at the Grad level.
Q1. What is a "testing mindset" and how is it different from a development mindset?
Strong answer: A developer's primary goal is to build something that works — they design for success. A tester's mindset is adversarial — we try to find what does not work, under what conditions, and why. Where a developer asks "does this work?", a tester asks "how could this break?", "what are the edge cases?", "what assumptions has this code made?", and "what happens when those assumptions are wrong?" Both mindsets are valuable; teams that have both produce better software than teams dominated by either alone.
Q2. A developer tells you "I tested this myself, you do not need to check it." How do you respond?
Strong answer: I acknowledge that developer testing is valuable and say something like: "That is great — I can build on that. Can you tell me what you tested so I do not duplicate your work and I can focus on what you have not covered?" Developer testing and QA testing are complementary: developers know the code paths they wrote, but testers approach the software from the user's perspective, without knowing the implementation. Testing our own work is inherently limited — we avoid the inputs that would trigger the bugs we accidentally wrote. This is not a character flaw; it is human cognitive bias.
Q3. You find a bug 30 minutes before a production release. What do you do?
Strong answer: I report it immediately to the team lead or product owner with the severity, reproduction steps, and impact on users. I do not make the go/no-go decision myself — that is a business decision. My job is to provide clear, accurate information so the team can decide: fix now (if it is a critical bug and the fix is low-risk), go live and fix urgently (if impact is low and the fix is complex), or delay the release. I document the defect regardless of the decision. If the team decides to go live with a known bug, I make sure it is captured in a bug tracker with the agreed resolution timeline.
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.