The Thinking Toolkit of a Software Tester
Three heuristics I explored at QA Connect 2026, and why the real lesson was never about memorizing them.
Yesterday (August 15, 2026) , I had the opportunity to speak at QA Connect 2026.
My topic was:
The Thinking Toolkit of a Software Tester.
The idea for this talk came from something I have noticed throughout my testing career.
When testers face uncertainty, the difficult part is often not operating the tool.
It is deciding how to approach the problem.
You open an unfamiliar product.
Where do you start?
You observe something strange.
How do you decide whether it is actually a problem?
A developer changes a small piece of code just before release.
What deserves regression attention?
These aren’t Playwright questions.
They aren’t Postman questions.
They aren’t SQL questions.
They are testing questions.
And there isn’t always one correct answer.
That is where thinking tools can help.
During my talk, I explored three heuristics that have influenced how I approach different testing problems:
SFDIPOT, FEW HICCUPPS, and RCRCRC.
But the session wasn’t really about learning three acronyms.
It was about something more useful:
How can we give ourselves better ways to think when the answer isn’t obvious?
For those who attended the session, this article goes through the ideas again at a slower pace.
For those who couldn’t attend, here is what we explored.
What Is a Heuristic Anyway?
Before getting into SFDIPOT or FEW HICCUPPS, there is an important distinction to make.
A heuristic is not a rule.
It isn’t a procedure.
It isn’t a guarantee.
And it certainly isn’t another checklist we must complete.
I think of a heuristic as a thinking aid.
It gives us prompts when we’re dealing with uncertainty.
That matters because testing is full of uncertainty.
We rarely have perfect requirements.
We rarely have unlimited time.
We rarely understand the entire system.
We rarely know every possible consequence of a change.
So experienced testers develop ways of generating useful questions.
Some come from experience.
Some come from mistakes.
Some come from conversations.
And some come from heuristics developed and shared by other testers.
The important part is not remembering the acronym.
The important part is whether it helps you see something you weren’t seeing before.
❶I Have a Product. Where Do I Start?
Imagine this.
Tomorrow you join a new company.
The product is WhatsApp.
Your manager tells you:
“Spend the next hour testing it.”
That’s all.
No test cases.
No detailed documentation.
No predefined scenarios.
Where would you begin?
This is where SFDIPOT, created by James Bach as part of the Heuristic Test Strategy Model, can be useful.
SFDIPOT gives us seven perspectives:
Structure, Functions, Data, Interfaces, Platform, Operations, Time.
The mistake would be to treat those as seven sections that must be completed.
Instead, think of them as seven places from which we can look at the same product.
Now look at what happened.
SFDIPOT didn’t tell us: “Execute these 50 test cases.”
It changed the questions we were capable of asking.
That’s the value.
When I’m stuck, sometimes I don’t need another testing tool. I need another perspective.
❷Something Looks Wrong. Compared to What?
Now suppose our exploration reveals something strange.
Maybe an edited message loses its reactions.
Maybe an icon suddenly behaves differently.
Maybe a workflow feels unnecessarily complicated.
We say:
“This looks wrong.”
But why?
This is where another question becomes extremely useful:
Compared to what?
That question is at the heart of FEW HICCUPPS, a heuristic developed by James Bach and Michael Bolton.
It reminds us that when we evaluate software, we’re always comparing what we observe against some source of expectation.
Those sources are often called test oracles.
Requirements can be an oracle.
But they are not the only oracle.
Imagine WhatsApp Introduces Edit Message
The requirement says: “Users should be able to edit a sent message.”
You send a message. You edit it. The text changes.
Requirement satisfied? Maybe.
Testing finished? No.Suppose editing a message removes all existing reactions. Nothing in the requirement mentioned reactions. Is that still worth investigating? Of course.
Why? Because we have other sources of expectations.
❸Something Changed. What Should I Regress?
Now we reach another familiar testing problem.
It’s Thursday afternoon.
Release is Friday morning.
A developer tells you: “I fixed the login issue.”
Then comes the sentence every tester knows:
“Can you quickly do regression?”
Okay.
What exactly should we regress?
Run everything?
Only login? Authentication? Sessions? Payments? Profile? Notifications?
Different devices? Different browsers?
Teams often default to one of two approaches:
Run everything.
Or: Test only what changed.
Neither is automatically correct.
A better question is: Where is this change most likely to create meaningful risk?
This is where Karen N. Johnson’s RCRCRC heuristic can help.
It gives us six perspectives:
Look at how the conversation changed.
We stopped asking: “How many regression tests should we execute?”
And started asking: “Where did this change create uncertainty?”
That is a much more useful way to think about regression.
Three Problems. Three Thinking Aids.
This was the connection I wanted to make during the talk.
SFDIPOT helps when I’m asking:
Where could I explore?FEW HICCUPPS helps when I’m asking:
Compared to what should I evaluate what I’m seeing?RCRCRC helps when I’m asking:
Where should I focus after change?
They solve different thinking problems.
But they have something important in common.
None of them executes a test.
None of them finds a bug.
None of them decides whether something matters.
They help us do those things.
And that distinction matters.
The Heuristic Is Not the Tester
There is a danger in articles like this.
Someone could bookmark it.
Memorize every acronym.
Create three checklists.
Add them to a testing template.
And completely miss the point.
Knowing SFDIPOT doesn’t make someone a good tester.
Neither does knowing FEW HICCUPPS.
Neither does knowing RCRCRC.
Because a heuristic cannot observe the product for you.
It cannot recognize surprise.
It cannot understand your stakeholders.
It cannot decide which risk deserves today’s limited testing time.
It cannot know when one of its own prompts is irrelevant.
That’s judgment.
And judgment develops through experience, observation, mistakes, conversations, study, reflection, and deliberate practice.
A heuristic should stimulate judgment, not replace it.
What Sits Underneath All Three?
If we remove the acronyms, what remains?
A few habits that I think matter far more.
And Yes, AI Belongs in This Conversation
AI can generate test ideas.
It can create test data.
Write automation.
Analyze logs.
Explain code.
Summarize requirements.
Suggest edge cases.
All useful.
But imagine AI gives you 150 test scenarios.
Now what?
Which ones matter?
Which are duplicates dressed differently?
Which assumptions did the model make?
What important context did you fail to provide?
Which risk matters most to your customers?
Which apparently intelligent suggestion is irrelevant to this release?
And what question didn’t you think to ask AI in the first place?
Generating more possibilities doesn’t remove the need for judgment.
Sometimes it increases it.
As tools become more capable, testers need to become better at deciding what information deserves attention.
Try This in Your Next Testing Session
You don’t need to memorize any acronym from this article. Instead, try three questions.
Don’t worry about completing every letter.
Use whatever helps the investigation.
Ignore whatever doesn’t.
The heuristic serves the tester. The tester doesn’t serve the heuristic.
Final Thoughts
When I prepared The Thinking Toolkit of a Software Tester, I wasn’t trying to teach people three acronyms.
I wanted to make something else visible.
Testing often happens in situations where we don’t have complete information.
We don’t know every risk.
We don’t know every user behavior.
We don’t know every consequence of a change.
We don’t even always know what “correct” means until we start investigating.
That’s why thinking matters.
SFDIPOT can help us see a product from another perspective.
FEW HICCUPPS can help us question the basis of our judgments.
RCRCRC can help us reason about regression without blindly running everything.
But none of them is the testing.
The tester is still observing.
The tester is still questioning.
The tester is still building and revising models.
The tester is still evaluating evidence.
The tester is still making judgments under uncertainty.
The heuristics simply give that thinking somewhere to start.
So if you attended my QA Connect session and eventually forget what every letter in SFDIPOT stands for, I’m perfectly fine with that.
I would rather you remember the questions.
Where else could I look?
Compared to what?
What changed, and where did that create risk?
And perhaps the most important one: What don’t I understand yet?
Because tools will change.
Frameworks will change.
AI will change.
The products we test will change.
But uncertainty isn’t going anywhere.
And as long as we’re testing under uncertainty, our ability to observe, question, investigate, evaluate, and make informed judgments will matter.
That’s the thinking toolkit I wanted to talk about.
Not something you install.
Not something you complete.
Something you keep developing every time you test.
Further Reading
If you found this useful, you might also enjoy these articles:
If you found this helpful, stay connected with Life of QA for more real-world testing experiences, tips, and lessons from the journey!