Module 1 · Software & QA foundations

Testing Mindset and Psychology

By the Mutqan Soft QA team · · 16 min · Beginner

The testing mindset is how a tester looks at a product: with curiosity, with professional pessimism (assuming there are defects nobody has found yet) and with a critical eye that questions every claim, including one's own. A builder asks "how do I make this work?"; a tester asks "how could this fail, and for whom?".

The psychology of testing is the human side of the job: the biases that make everyone, testers included, see what they expect, and the way people react to bad news about their work.

Why it matters

A defect reaches users when nobody looked where it was, or when someone found it and the finding was argued about or ignored. The mindset decides where you look; how you deliver the news decides whether a finding becomes a fix. A tester whose findings are factual and fair is trusted, and can raise an uncomfortable risk before a release without starting a conflict.

The tester's mindset: curiosity, professional pessimism, a critical eye

A developer's main goal is to build a solution, so the natural question while building is "how do I make this work?". The testing mindset asks "how could this fail, for whom, and how would we notice?". They are mindsets, not job titles: a developer reviewing a colleague's code is using the testing mindset.

For a password reset link, the building mindset checks that a user can request the link, open it and set a new password. The testing mindset opens it twice, after it expires, after the password was changed and from a forwarded e-mail.

  • Curiosity: asking "what happens if…?" even when no test case asks it.
  • Professional pessimism: expecting defects to remain, because passing tests cannot prove there are none; it targets the software, never the people.
  • A critical eye: "it works" only means "it worked for the cases we tried".
Building and testing mindsets on one password reset link: one asks how to make it work, the other how it could fail, and both must watch for confirmation bias. Conceptual model

Building mindsettypical of developers

"How do I make this work?"

Focus:
Designing and building a solution
First tests of the reset link:
Request a link, open it, set a new password
Confirmation bias to watch:
Testing the path that was built, with the data in mind, and reading a pass as proof
What it contributes:
A working solution

Testing mindsettypical of testers

"How could this fail, for whom, and how would we notice?"

Focus:
What might be wrong with the solution, and with the requirement behind it
First tests of the reset link:
Open it twice, after it expires, after the password changed, from a forwarded e-mail
Confirmation bias to watch:
Retesting a fix with the ticket's input only, or calling a one-off failure "the environment"
What it contributes:
Information on where it fails and how much risk is left

Mindsets, not job titles: a developer reviewing a colleague's code uses the testing mindset, and a tester needs to understand how something is built.

Try it: Positive Test Generator Try it: Negative Test Generator

Confirmation bias: seeing what we expect

Confirmation bias is the tendency to look for, interpret and remember information that confirms what we already believe. Authors tend to test the path they built, with the data they had in mind, and read a pass as proof. That is how attention works, not carelessness.

Testers are not immune: retesting a fix only with the input in the ticket, or explaining a one-off failure away as "the environment", is confirming, not testing. Counter-measures:

  • Write the expected result from the test basis before you run the test.
  • Pair each confirming test with one that tries to show the opposite: an invalid input, a double click.
  • Ask "what result would prove me wrong?", and let a colleague review your test ideas.

Try it: Edge Case Generator

Independence of testing: benefits and drawbacks

The ISTQB glossary defines independence of testing as a separation of responsibilities that encourages objective testing. CTFL v4.0 describes degrees: testing by the author (none), by peers in the same team (some), by testers from another team (high) or from outside the organisation (very high). Most projects combine several degrees: for example, developers test their own components, a test team tests the whole system and business representatives do acceptance testing. Independence does not replace familiarity: developers find many defects in their own code efficiently.

  • Benefit: different backgrounds, perspectives and biases let independent testers recognise different kinds of failures, and challenge assumptions made during specification and implementation.
  • Drawback: isolation can lead to poor collaboration, communication problems or an adversarial relationship, developers may lose their sense of responsibility for quality, and testers may be seen as a bottleneck or blamed for delays.

How people receive bad news, and how to deliver it

Testers often bring bad news, and blaming the bearer is a common reaction. A defect report can sound like criticism of the product and its author, confirmation bias makes unwelcome information harder to accept, and some people see testing as destructive. The ISTQB syllabus therefore asks testers to communicate defects and failures constructively.

The tester skills lesson covered writing the report; delivering it is about the reader. Google's code review guide puts the rule simply: comment on the code, not the developer.

  • Deliver early: a blocking failure as soon as it is confirmed, not at the release meeting.
  • Start from the shared goal: "customers would be charged twice", not "your code double-charges".
  • Expect a defensive first reaction and answer with evidence, not emphasis; when unsure, ask rather than pronounce a verdict.
  • Check understanding both ways: ask the reader to restate the failure and its impact, and restate their answer before you reply.

Worked example: retesting a fix and handling pushback

Lina reported that the store app's search returns nothing when the query ends with a space. Omar resolved it with "Fixed and tested: searched coffee, results OK". That test could not fail: coffee without a space always worked.

Lina designs her confirmation test from the defect and the requirement instead. The trailing space is fixed, but a leading space, as in a pasted product name, still fails. When Omar calls it an edge case, she does not argue: she agrees with the fact, adds what she observed and hands the open question to the product owner.

SEARCH-212  Search returns 0 results when the query ends with a space

Omar:  Fixed and tested: searched "coffee", results OK. Resolved.

Lina, confirmation test on build 5.2.1, staging, account test01
  "coffee"          24 results    regression check
  "coffee "         24 results    the reported case: fixed
  " coffee"          0 results    new: space before the word
  "coffee  beans"    6 results    same as "coffee beans"
  "   "             "Enter a search term"
  Result: fix confirmed for SEARCH-212; leading space logged as SEARCH-219

Omar:  A leading space is an edge case, nobody types that.
Lina:  True, people rarely type it. It appears when a product name is
       pasted from a chat or an e-mail. Should leading spaces be ignored
       like trailing ones? I have asked the product owner on SEARCH-219.

Try it: Edge Case Generator

Common mistakes

  • Aiming professional pessimism at people: doubting the product is the job, doubting a colleague is not.
  • Believing only developers have confirmation bias, then retesting a fix only with the input in the ticket.
  • Reporting "no defects found" as "there are no defects".
  • Fighting for a rejected defect to save face instead of adding evidence or accepting the decision.
  • Treating independence as distance: testing in isolation and seeing developers as opponents.

The QA perspective

The mindset pays most before code exists: in refinement (where the team discusses upcoming stories) and in reviews, a "how could this fail?" question costs one sentence. While testing, watch your own bias: take expected results from the test basis, and design confirmation tests from the defect, not from the fix comment.

Agree with the team how findings are raised and which degree of independence each kind of testing gets. When a finding meets resistance, separate fact from decision: you make the evidence and the risk clear; the people responsible decide whether to fix, defer or accept it, usually in defect triage.

Practice exercise

Spot the bias and respond constructively

Your task

Each situation below shows a bias or a human reaction from this lesson. Name it, then write what you would say or do instead.

Material
1. After two days of testing a feature without finding a defect, you are
   about to write "No defects, ready for release" in the status report.
2. Your defect comes back "Rejected: cannot reproduce". Your first draft
   reply: "It fails every time for me, check again."
3. The testers see each build only at the end of the sprint. Developers
   increasingly say "QA will catch it" when a change has no unit tests.
4. In the stand-up the team lead says: "Testing is holding up the
   release again."
Steps
  1. Decide whose bias or reaction it is: yours, the reader's or the team's.
  2. Name the effect with the terms of this lesson.
  3. Write one verifiable sentence or action about the product or the process, not a person.
Show the model answer
Model answer

1. Your own confirmation bias: passing tests do not show there are no defects. Write "No defects found in (areas tested). Not tested: (list). Remaining risk: (one line)", after adding a few tests that try to break the feature.

2. The reader's reaction, and yours: "cannot reproduce" often means a different build, data or environment, and the draft answers a fact with a feeling. Reply with facts: "Build 4.1.2 on staging, account test07, data from step 2; recording attached. Can we look at it together?"

3. The team's: a drawback of independence. Isolated testers become a safety net, and developers feel less responsible for quality. Propose that testers join refinement and test each build as it arrives, and that developers write unit tests for their changes.

4. The team's reaction: blaming the bearer of bad news, with testers seen as a bottleneck. Give facts, not a defence: "Everything is tested except refunds, which arrived yesterday. Two open defects block card payments; releasing with them is the product owner's decision."

Frequently asked questions

Is professional pessimism the same as being negative?

No. It is a working assumption about the product: there are defects you have not found yet, so you keep looking until the remaining risk is known. It says nothing about the people who built the product, and a good tester reports what works as clearly as what fails.

Should developers test their own code?

Yes. Developers find many defects in their own code efficiently, and the ISTQB syllabus says independence is not a replacement for familiarity. Independent testing is added on top, where different eyes and different biases are worth the cost, for example at system and acceptance level or for high-risk features.

How can I notice my own confirmation bias?

Look for the signs: you wrote the expected result after seeing the screen, you retested a fix only with the input from the ticket, every test passed and none tried an input that should be rejected, or you explained a failure away without investigating it. A colleague reviewing your test ideas, or testing in a pair, catches what you cannot see yourself.

References

Tools

Practise with Mutqan tools

Negative Test Generator

Generate negative test cases for form fields and APIs: empty, null, wrong type, too long, injection, invalid format.

Test Design

Positive Test Generator

Generate positive (happy-path) test cases that confirm each requirement and valid input combination works.

Test Design

Edge Case Generator

Generate edge cases for strings, numbers, dates, files, lists and concurrency from a field definition.

Test Design

Go deeper

Your progress on this topic

Part of the QA Roadmap

Before this topic