Psychology of Testing
Independence, cognitive bias, and the tester mindset. Why the same code reviewed by developers found 3 bugs, and an independent tester found 17.
1 The Hook
A development team at an Auckland logistics company had just finished a major release: a new route optimisation module for delivery drivers across the North Island. Before handover, the developers did their own code review and ad-hoc testing. They found three bugs: a typo in a log message, an off-by-one error in a loop, and a missing null check. Confident, they passed the build to QA.
An independent tester spent two days with the module. She found seventeen bugs. Some were subtle: the optimisation algorithm produced incorrect results when a delivery address had a Māori macron in the street name. Others were severe: under certain conditions, the system would assign two drivers to the same route, leaving another suburb unserved. One bug corrupted the driver schedule database if the optimisation ran after 11:59 p.m.
The developers were not careless. They were biased. They knew how the code was supposed to work, so they unconsciously avoided the paths that would break it. They saw what they expected to see. The tester brought a fresh perspective, no assumptions, and a deliberate goal of finding failure. That difference is not about skill. It is about psychology.
2 The Rule
Degrees of Independence
ISTQB recognises that testing benefits from independence — but independence is not binary. It exists on a spectrum:
- No independence: The author of the code tests their own work. Fast, but highly susceptible to bias.
- Low independence: Another developer in the same team tests the code. Some fresh perspective, but shared context and assumptions remain.
- Medium independence: Testers within the same organisation but outside the immediate development team. Different goals, different metrics, less shared context.
- High independence: Testers from a separate company or department, or external auditors. Maximum objectivity, but potentially less domain knowledge.
More independence generally finds more defects but may come with communication overhead and slower feedback. The right level depends on risk, regulation, and team structure.
Cognitive Bias in Testing
Testers and developers are both human, and humans are biased. Two biases are particularly relevant:
- Confirmation bias: The tendency to search for, interpret, and remember information that confirms pre-existing beliefs. A developer who believes their code works will test paths that prove it works. A tester who believes a feature is simple may under-test it.
- Inattentional blindness: The failure to notice unexpected stimuli when attention is focused elsewhere. If you are looking for font colour bugs, you might miss that a button does nothing when clicked. Testers must deliberately vary their focus.
Constructive Communication
Testing is not about proving developers wrong. It is about building a better product. How findings are communicated matters as much as the findings themselves:
- Focus on the product, not the person. “The login form rejects valid email addresses” not “Your regex is wrong.”
- Start from shared goals. “We both want customers in Christchurch to complete their orders smoothly.”
- Provide evidence, not accusation. Screenshots, logs, and reproduction steps build trust.
- Collaborate on severity. A tester’s “critical” might be a developer’s “edge case.” Discuss impact on real users.
3 The Analogy
You have spent a week writing an essay for a university assignment. You read it over before submitting. It looks good. The arguments flow. The spelling seems fine. You hand it in.
Your friend reads the same essay and spots five typos, a paragraph that contradicts itself, and a reference to a source you forgot to cite. How did you miss all that?
You missed it because you knew what you meant to say. Your brain filled in the gaps. When you read “teh” your brain saw “the” because that is what you intended. When a sentence was ambiguous, your brain supplied the correct meaning because you already knew it. This is confirmation bias and inattentional blindness in action.
Your friend had no prior knowledge of your argument. She read what was actually on the page, not what you meant to write. She was independent. She was objective. She found what you could not.
Software testing is identical. The developer knows the intent. The tester reads the code and the behaviour without that mental model. That independence is why testers find bugs developers miss.
4 Watch Me Do It
Here are three examples of how to communicate testing findings without blame, and why the phrasing matters.
| Blame-oriented (Avoid) | Product-oriented (Use) | Why It Works |
|---|---|---|
| “You broke the checkout flow.” | “The checkout flow fails when a voucher code is applied after the shipping method is selected. I have attached a screen recording.” | It describes the behaviour, not the author. It provides evidence. It invites collaboration rather than defensiveness. |
| “This is a stupid bug. Anyone could have seen it.” | “The password reset email is not sent when the user has a .co.nz domain. I tested with gmail.com and it worked, so the issue may be domain-specific.” | It avoids judgment, narrows the scope, and gives the developer a starting point for investigation. |
| “Your code does not handle Unicode.” | “I found that names with macrons (e.g., Māori names) are truncated in the customer export. This affects compliance with accurate record-keeping. Happy to pair on a fix.” | It frames the issue in business terms (compliance), offers help, and respects the developer’s time. |
5 When / When-not
| When Independence Is Essential | When Developers Testing Their Own Code Is Appropriate |
|---|---|
| When the code is complex, safety-critical, or financially significant. A bug in a medical device or a bank transfer module needs an independent eye. | During development, for rapid feedback. A developer running unit tests after every change is efficient and appropriate. The key is that this is not the only testing. |
| When the developer has deep emotional or time investment in the feature. The more attached they are, the harder it is to see flaws. | When the change is trivial: a CSS colour change, a copy update, or a config tweak. The risk of bias finding a typo is low. |
| When regulatory or contractual requirements demand independent verification. Many government and finance projects in NZ require this. | In early prototyping, when the goal is learning rather than quality assurance. You do not need a separate tester for a hackathon demo. |
| When the same bugs keep escaping to production. If users are finding what developers missed, independence is not optional. | When no tester is available. A developer doing their best with a checklist is better than no testing at all. Just be transparent about the limitation. |
Before you apply this technique, ask:
- Are you aware of your own biases and actively working against them?
- Do you have the context and access needed to test independently, or will you just repeat the developer's assumptions?
- Can you communicate findings constructively, without blame or judgment?
6 Common Mistakes
✗ Adversarial tone
Correction: A tester who frames findings as scores in a battle (“I found 12 bugs in your code”) destroys trust and slows the team. Testing is a service to the team, not a competition. Replace score-keeping with collaborative problem-solving. “Together we found 12 issues before customers did.”
✗ Assuming malice
Correction: “They must have known this was broken and shipped it anyway” is a common tester thought. It is almost never true. Developers want to ship quality. Bugs escape because of time pressure, complexity, missing requirements, or genuine oversight. Assume good intent. It changes how you communicate and how you are received.
✗ Going lone wolf without communicating findings
Correction: A tester who logs 50 bugs in silence and then dumps them on the team on Friday afternoon is not helping. Testing is most valuable when findings are shared early and often. A daily stand-up update (“I found two issues in the payment flow, sharing details after the meeting”) gives the team time to respond and prevents last-minute surprises.
When this technique fails
Your independence work becomes useless if you fail to recognise your own biases. A tester who is biased towards believing the code works (confirmation bias) will unconsciously avoid paths that break it, repeating the developer’s mistake. Similarly, if you report findings without evidence or constructive framing, your independence is negated by poor communication that the team dismisses or resents.
7 Now You Try
Each bug report below is blunt or defective. Rewrite it into a constructive, product-oriented report. Click to see a suggested rewrite.
Original: “The search is broken. You guys never test anything.”
Rewrite: “The product search returns no results when a filter is applied after a keyword search. Steps: 1) Search for ‘tramping boots’. 2) Apply ‘Size 10’ filter. Expected: filtered results. Actual: blank page. Browser: Chrome 120, Windows 11. Screenshot attached.”
Original: “Your API is garbage. It crashes on every second request.”
Rewrite: “The booking API returns HTTP 500 on approximately 50% of requests during concurrent load. I reproduced this with a simple script sending two simultaneous requests. The stack trace points to a race condition in the seat allocation logic. Log file and reproduction script attached.”
Original: “This UI is terrible. Did a child design it?”
Rewrite: “The checkout page has three consecutive modals that block navigation. During user testing, 4 of 5 participants tried to use the browser back button and were trapped. Suggest combining the shipping and payment steps or adding a visible ‘previous’ button. Video clips attached.”
8 Self-Check
Q1: Why do developers often miss bugs in their own code?
Developers suffer from confirmation bias and inattentional blindness. They know the intended behaviour, so they unconsciously test paths that confirm their assumptions. They may not think to test edge cases that contradict their mental model. An independent tester has no such preconceptions and approaches the system with the explicit goal of finding failure.
Q2: What is the difference between low independence and high independence in testing?
Low independence means another developer in the same team tests the code. They share context, tools, and assumptions with the author. High independence means a tester from a different department, company, or external auditor tests the code. They bring fresh perspective and less shared bias, but may need more time to understand the domain.
Q3: A tester finds a bug and wants to report it constructively. What are three things they should include?
1) Clear reproduction steps so anyone can recreate the issue. 2) Evidence such as screenshots, logs, or screen recordings. 3) Impact framed in user or business terms rather than technical blame — e.g., “customers in rural NZ cannot complete checkout” rather than “your code is broken.”
9 Interview Prep — Junior Q&A
Kiwi employers ask junior testers these questions. Have short, confident answers ready.
Q. "What is the difference between a developer testing their own code and an independent tester?"
A developer testing their own code knows how the code is supposed to work, so they unconsciously avoid paths that break it — confirmation bias. An independent tester has no such preconceptions and actively looks for failure. Studies show independent testers find 3-5 times more defects. Both are necessary: the developer finds fast, but the tester finds deep.
Q. "How would you report a bug you found without offending the developer who wrote it?"
I would focus on the product and behaviour, not the person. Instead of "Your code is broken," I would say, "The checkout form rejects valid email addresses ending in .co.nz. Here are screenshots and reproduction steps." Then I would offer to help investigate. Testing is about building a better product, not proving developers wrong.
Q. "Can you give an example of confirmation bias affecting testing?"
Sure. I once tested a password reset feature. The happy path worked fine, so I felt confident. Then an independent tester found that the reset email was never sent if the user had a .co.nz domain — but they silently moved forward anyway. I had unconsciously tested only the paths I expected to work. That taught me to deliberately test edge cases, not just the ones that confirm my assumptions.