Common sense: the hardest thing to test
I still remember something my former Head of QA said many years ago after reviewing some engineering decisions made by teams in the company.
He sighed and said:
"Common sense is the hardest thing to find these days."
At the time, I thought it sounded a bit harsh. I understood what he meant, but I also thought it was a little unfair.
After all, what is obvious to one person is not always obvious to someone else.
After many years working in QA, I think I understand the point he was making.
The hardest thing to test is often not the product or the code. It is everything around it: the assumptions people make, the decisions nobody questions, and the things that seem too obvious to write down.
Common sense is usually the requirement nobody creates a ticket for.
We have user stories, acceptance criteria, designs, refinement meetings and documentation.
And then a team member asks:
"What happens if we actually do this?"
Silence.
Nobody thought about it yet.
Those questions are often asked by QA, especially when QA gets involved later in the process. Not because QA has all the answers, but because part of the job is looking at what happens when things are used differently from what was expected.
The ticket is ready, but are we?
The word "ready" is interesting.
Everyone uses it, but it does not always mean the same thing.
A ticket has been refined, acceptance criteria exist and everyone understands the goal.
So the team starts building.
I have seen this happen with frontend work quite often.
A developer picks up a ticket and starts working on it. The implementation looks straightforward until they discover that the API is not ready yet.
Or the backend team still needs to decide what the data should look like.
Or another team owns part of the functionality and nobody checked whether it fits their planning.
Suddenly, a ticket that was considered ready is blocked.
This does not mean someone made a bad decision. These situations happen.
It is just that "ready" can mean different things.
A ticket can be ready from a product perspective, but not ready from a delivery perspective.
Often, it only takes a few minutes of discussion to uncover these things:
"Who else needs to be involved?"
"Are there dependencies we haven't discussed?"
"Do we know how the teams will work together?"
"How are we going to test this?"
These are not questions asked to slow things down. They usually prevent people from waiting later.
The infamous "we can just quickly test this in production"
There are not many sentences that make QA nervous faster than:
"Oh, we can probably just quickly verify it in production."
Sometimes that is completely fine.
Some teams intentionally test in production. They have the right safeguards, monitoring and rollback options in place.
However, it is more concerning and also more common that "quickly check it in production" becomes the easiest option.
What I find interesting is that people who would never run a risky database query on production can sometimes feel comfortable doing a quick verification there because it sounds harmless.
But production is different.
Real users are there, as well as real data.
A quick check can create data, send emails, trigger payments or leave behind something that somebody has to clean up afterwards. It can even affect other real users.
Before doing something there, I think the most useful question is:
"What happens if this does not behave as expected?"
Testing in production is not automatically wrong.
Doing it without thinking about the consequences is where problems start.
"It is only a small change"
I think almost everyone who has worked in IT has heard this sentence:
"It is only a small change."
Usually, that is the moment where someone should ask a few more questions.
Small changes have a habit of touching things nobody expected.
It might affect:
- another system
- another team
- an integration
- reporting
- a mobile application
- an assumption that has existed for years
This becomes harder as companies grow because fewer people have the complete picture.
A developer can understand their part perfectly while having no visibility into what depends on it somewhere else.
That is normal. Nobody can know everything.
So the goal should be to create enough space for people to ask questions before something reaches users.
Assuming another team knows
Another classic situation:
"We already informed them."
That's great.
How?
Was it a Slack message? A ticket? A meeting?
And did the right people actually understand what they needed to do?
Cross-team problems are often not caused by people refusing to communicate.
More often, everyone believes the communication happened somewhere else.
Sharing information is not always the same as creating understanding.
A team knowing that something is changing does not automatically mean they know what action they need to take or when they need to take it.
Automation is not always the answer
QA can fall into the same trap.
We make assumptions too.
Sometimes we build something because it is interesting or technically satisfying, not because it solves the biggest problem.
Automation is a good example.
Automation is valuable, but I have seen teams spend months building checks that nobody runs or trusts afterwards or even that they only catch low impact issues.
The questions I usually ask are:
- How often will this actually run?
- How much effort does it take to maintain?
- What problem does it solve?
- What happens if this feature breaks?
I have been guilty of this myself.
Building automation can be satisfying. Creating a clean framework or improving a pipeline feels good.
But sometimes you end up with something technically impressive that nobody really needed.
There is nothing wrong with the automation itself. The mistake was deciding that automation was the answer before understanding the problem.
QA does not own common sense
One thing I have learned is that QA should not be the only role asking these questions.
Quality is created throughout development.
Developers, designers and product managers all influence how something behaves for users.
QA should challenge assumptions and help teams think about risks.
But everyone involved owns the result.
I have seen more problems caused by people being afraid to ask simple questions than by people asking too many of them.
The best teams I have worked with were not the ones where QA found everything.
They were the ones where people felt comfortable raising concerns before something became a problem.
When process replaces thinking
I actually like processes.
Good processes remove confusion and help teams work together.
The problem starts when completing the process becomes more important than understanding why it exists.
I have seen situations where every box was checked, every meeting happened and every document existed, but people still had different expectations about what was being built.
Everyone followed the process, but somehow we still ended up with different expectations. There was no thinking behind it.
A process should help people make better decisions. It should not become something people complete just because it exists.
The strongest teams I have worked with are not the ones with the most rules.
They are the ones where people feel responsible for the outcome and are comfortable asking questions.
Final thoughts
After all these years, I understand much better what my former Head of QA meant.
I don't think he meant that people lack common sense.
Software systems rarely stay simple for long. As more teams and dependencies are added, assumptions become much easier to miss.
After seeing enough bugs, delays, incidents and unexpected behaviour, you start recognising patterns.
You start asking:
"Who else needs to know about this?"
"What happens if someone uses this differently?"
"Are we sure this is how it should work?"
"Are we solving the right problem?"
Those questions are not about being negative or slowing people down.
They come from experience.
A few extra questions before starting are usually much cheaper than fixing things afterwards.
Maybe that was what my former Head of QA meant.
Not that people lack common sense. More that, in software, we sometimes get so focused on delivering something that we forget to ask the obvious questions.
After all these years, that is still the question I try to ask first:
"Wait... should we really do it this way?"
Alex Hovenkamp