DEV Community: Melvin Salazar

Most Test Cases Are a Waste of Time, But Here’s What Good Testers Do Instead

Melvin Salazar — Tue, 31 Mar 2026 23:28:38 +0000

Why more testing does not mean better quality, and what actually does

There’s a quiet assumption in many software teams:
The more test cases we have, the better our quality must be.
At first glance, it sounds reasonable.
More coverage.
More scenarios.
More validation.
But after years working on complex systems, I’ve seen something very different:
A large portion of test cases add very little value.
They create activity.
They create documentation.
They create a sense of safety.
But they don’t necessarily improve quality.
And in some cases, they do the opposite.

The comfort of “we have tests”

In many teams, test cases become a form of reassurance.
You’ll hear things like:
• “We have full coverage”
• “All test cases passed”
• “Regression is complete”
And yet, defects still escape.
Not small ones—important ones.
Why?
Because many test cases are designed to confirm what we already expect, not to challenge what might be wrong.

Where test cases start losing value
Let’s be honest.
A lot of test cases follow patterns like:
• step-by-step scripts repeating UI flows
• validating expected inputs and outputs exactly as specified
• checking predictable, well-understood scenarios
• confirming behavior that rarely changes
These are not useless.
But they are often low-value once the system stabilizes.

Over time, they become:
• repetitive
• expensive to maintain
• disconnected from real risks
• rarely the source of meaningful defect discovery
And yet, teams keep adding more.
Because more feels safer.

The real problem: testing becomes mechanical

When testing becomes focused on executing predefined steps, something important is lost:
Thinking

Testers shift from:
• exploring the system
to:
• following instructions

From:
• questioning behavior
to:
• confirming expectations

And that’s where quality starts to degrade, quietly.
Because the most important defects are rarely found by doing exactly what was planned.

What good testers do differently

Strong testers don’t focus on how many test cases exist.
They focus on:
Where the system is most likely to fail, and why
Here’s what that looks like in practice.

1) They think in terms of risk, not coverage
Instead of asking:
“What test cases are missing?”
They ask:
“Where could this system cause real problems?”
That shift changes everything.
They prioritize areas where:
• decisions are made based on system output
• calculations or transformations occur
• multiple components interact
• users rely on results without questioning them
Because that’s where failures matter most.

2) They challenge assumptions, not just behavior
Most test cases validate:
“Does the system do what it’s supposed to do?”
Good testers go further:
“Should the system be doing this at all?”
They look for:
• hidden assumptions
• oversimplified logic
• unrealistic conditions
• behavior that seems correct but feels off
This is where many critical issues live.
Not in broken features—but in flawed thinking embedded in the system.

3) They explore beyond predefined paths
Test cases are, by definition, predefined.
But real-world usage rarely is.
Good testers:
• deviate from scripts
• combine scenarios
• introduce unexpected inputs
• simulate real user behavior
They explore:
• what happens at the edges
• what happens when things don’t align perfectly
• what happens when the system is used in ways no one explicitly designed for
Because that’s where systems reveal their weaknesses.

4) They focus on outcomes, not steps
A test case might say:
• input X
• perform action Y
• expect result Z

But a good tester asks:
“Does result Z actually make sense?”
Especially in systems that:
• calculate
• recommend
• simulate
• interpret data
A result can be:
• technically correct
• consistent with the logic
• fully passing tests
…and still be wrong in practice.
This is where experience and context matter more than scripts.

5) They reduce noise, not increase volume
More test cases often mean:
• more maintenance
• more execution time
• more noise in results
• more false confidence

Good testers actively:
• remove redundant tests
• simplify validation
• focus on meaningful scenarios
They understand that:
Clarity beats quantity
A small set of well-chosen tests is often more powerful than a large set of repetitive ones.

The hidden danger of too many test cases
Here’s something rarely discussed:
Too many test cases can actually reduce quality
Why?
Because they create:
• cognitive overload
• false confidence (“everything passed”)
• resistance to change (tests become fragile)
• focus on execution instead of thinking
Teams become busy maintaining tests, instead of improving understanding.
And that’s when important defects start slipping through.

What changes in complex systems
In simple applications, test cases can go a long way.
But in complex, domain-heavy systems—like those used in engineering, energy, or decision-support environments—the limitations become clear.
Because quality is not just about:
• correct execution
It’s about:
• meaningful results
And meaningful results cannot be fully captured in predefined scripts.
They require:
• context
• domain awareness
• interpretation
• judgment
That’s where strong testers stand out.

So… should we stop writing test cases?
No.
Test cases still have value.
They are useful for:
• regression checks
• known scenarios
• critical flows
• baseline validation
But they should not become the center of testing.
They are a tool, not the strategy.

Final thought

If your testing strategy depends heavily on:
• the number of test cases
• the percentage of coverage
• the number of passing checks
then you may be measuring activity—not quality.

Because the most important defects are rarely found by:
doing more of the same, more times
They are found by:
• thinking differently
• questioning assumptions
• exploring uncertainty
• understanding the system deeply

So next time you hear:
“We need more test cases”
pause for a moment and ask:
“Or do we need better thinking?”
That question might lead to far better testing—and far fewer surprises in production.

What about you?
Have you seen situations where:
• many test cases existed
• everything passed
• and yet important issues still appeared?
Or do you believe strong test coverage is still the best indicator of quality?
I’d be interested to hear your perspective.

AI Won’t Replace Good Testers — But It Will Expose Weak Testing Faster

Melvin Salazar — Thu, 26 Mar 2026 23:43:07 +0000

What software quality looks like when systems are complex, domain-heavy, and too important to guess

There is a dangerous illusion growing in software teams right now:
“If we use AI in testing, quality will automatically improve.”
It won’t.
AI can speed things up.
It can help testers think faster.
It can generate ideas, test scenarios, edge cases, and even documentation.
But in complex industrial software, especially in sectors like energy, engineering, simulation, operations, and decision-support systems, AI can also make one problem worse:
It can help teams become confidently wrong, faster.
And that is far more dangerous than simply being slow.
This article is not about hype.
It is about what I believe is the real question for testers in the AI era:
Will AI improve testing — or will it expose how shallow our testing already was?

The problem is not AI. The problem is shallow validation.

In many teams, software quality is still judged by a comforting set of signals:
• tests are passing
• automation is green
• pipelines are clean
• no critical crashes were reported
And when those signals look healthy, people relax.

But in complex systems, especially domain-heavy systems, that confidence can be misleading. Because there is a big difference between:
• the software behaving consistently
and
• the software behaving correctly

That difference matters enormously in applications where software influences:
• engineering decisions
• operational planning
• production workflows
• calculations used by experts
• risk-based or cost-based choices
In those environments, the biggest failures are not always dramatic.
Sometimes the most dangerous issue is this:
The software returns an answer that looks valid, but should never have been trusted.
That is exactly where AI becomes interesting — and risky.

AI is very good at helping you test the obvious

AI is already useful in software testing.
Used well, it can significantly improve productivity.
A tester can use AI to help with:
• generating test ideas
• identifying missing edge cases
• summarizing requirements
• rewriting vague bug descriptions
• creating structured exploratory testing charters
• improving traceability between scenarios and expected behavior
• translating complex logic into clearer test conditions

That is valuable.
In fact, for manual testers working in large or domain-heavy systems, AI can act like a thinking accelerator. But here is the catch:
AI usually works best on what is already visible, documented, or inferable.
That means it is very good at helping you test:
• what is written
• what is expected
• what appears structurally logical

What it is not naturally good at is detecting when:
• the requirement is incomplete
• the business rule is subtly wrong
• the engineering assumption is unrealistic
• the output is technically valid but operationally misleading
• the software is behaving “correctly” according to logic, but incorrectly according to reality

And that is exactly why good testers still matter more than ever.

In industrial software, “correct” is often not enough

One of the biggest misunderstandings in testing is the assumption that correctness is purely technical.
In simple apps, that may be enough. But in complex industrial systems, quality often depends on a deeper question:
Does this result make sense in the real world this software is meant to support?

That is a very different kind of validation.
For example, imagine a system in the energy industry that supports:
• calculations
• engineering workflows
• scenario comparisons
• planning logic
• operational or subsurface interpretation
• data-driven recommendations

The software may:
• load correctly
• calculate correctly
• return stable outputs
• pass all regression checks

And still be wrong in a way that matters.
Not because of a crash.
Not because of a syntax error.
Not because a test case failed.

But because the software may quietly allow:
• unrealistic assumptions
• misleading defaults
• dangerous simplifications
• domain-invalid interpretations
• plausible but poor-quality outputs

These are the kinds of issues that often survive both automation and shallow manual testing.
Why?
Because they don’t look broken.
They look reasonable.
And that is exactly what makes them dangerous.

AI can help you test faster — but it cannot replace domain judgment

This is where I think the conversation around AI in QA often becomes too simplistic.
People ask:
“Can AI write test cases?”
“Can AI help automate test design?”
“Can AI improve test productivity?”

Yes.
Absolutely.
But those are not the most important questions.
The more important question is:
Can AI tell when the software is making a decision that should not be trusted?
And in most real-world industrial environments, the answer is:
Not reliably without human domain understanding.

Because AI does not automatically know:
• what engineers actually care about
• what users will assume from a result
• what values are realistic in practice
• what shortcuts are acceptable
• what “looks fine” but would mislead a real expert
That judgment still belongs to testers, analysts, and domain-aware quality professionals.
This is why I believe the strongest testers in the next few years will not simply be the people who use AI.
They will be the people who know when not to trust it blindly.

The real opportunity: use AI as a quality amplifier, not a quality substitute

This is the mindset shift that matters most.
AI should not be treated as a replacement for testing judgment.
It should be treated as a quality amplifier.

That means using it to improve:
• speed
• clarity
• breadth of thinking
• scenario generation
• requirement interpretation
• exploratory preparation

But not using it as a substitute for:
• domain reasoning
• engineering context
• risk assessment
• product intuition
• critical skepticism

When used properly, AI can make a good tester significantly stronger.
It can help uncover:
• missing assumptions
• scenario blind spots
• incomplete validation paths
• overlooked combinations
• weakly defined expected behavior

But it only becomes powerful when paired with a tester who knows how to ask:
• What is this software really trying to support?
• What would a real user assume from this result?
• What could silently go wrong here?
• What would be expensive, dangerous, or misleading if this were wrong?

That is not just testing.
That is quality thinking.
And quality thinking is still deeply human.

Weak testing becomes more obvious in the AI era

This is the uncomfortable truth, AI will not just improve testing, it will also expose poor testing practices faster.

Teams that already rely too heavily on:
• happy path validation
• shallow requirement interpretation
• checkbox testing
• “green means good” thinking
will likely use AI to produce more output without producing more insight.

That means they may end up with:
• more test cases
• more generated scenarios
• more structured documentation
…but still miss the same critical problems.

Because the real weakness was never the lack of test volume.
The weakness was the lack of deep understanding.
And AI cannot fix that for you, it can only reveal it.

What better testing looks like in an AI-assisted future

In my view, better testing in complex software environments will increasingly require a combination of four things:

1. Technical awareness
You need to understand:
• system behavior
• interfaces
• workflows
• failure patterns
• data dependencies

2. Domain understanding
You need to understand:
• what the software is actually for
• what “good output” looks like
• what users trust
• what outcomes would be misleading or dangerous

3. AI fluency
You need to know how to use AI to:
• accelerate thinking
• challenge assumptions
• improve test preparation
• uncover blind spots faster

4. Critical judgment
You need the discipline to ask:
“Just because this looks valid… should we trust it?”
That one question may become one of the most valuable QA skills in the AI era.

Final thought

AI will absolutely change software testing.
It already is.
But the teams that benefit the most will not be the ones that use AI the fastest, they will be the ones that use it wisely, especially in systems where software quality cannot be reduced to “test passed.”
Because in complex software, and especially in industrial or energy-related systems, the biggest quality failures are often not obvious.
They are subtle.
Quiet.
Plausible.
And expensive.

And those are still the kinds of problems that require a tester who understands more than tools.
So no, I do not think AI will replace good testers.
But I do think it will expose weak testing faster than ever before.
And that may be one of the best things to happen to quality.

What about you?

Have you used AI in testing in a way that actually improved quality, not just speed?
Or have you seen situations where software passed every check, but still didn’t make sense in the real world?
I’d love to hear your experience.

How I Discovered a Serious Bug Without Automation: The Importance of Domain Knowledge Over Tools in Software Testing

Melvin Salazar — Wed, 25 Mar 2026 00:08:04 +0000

The moment that changed how I see testing

There was no failing automated test. No alert. No monitoring signal.
Everything looked “green.” And yet, there was a major bug.
Not obvious.
Not visible to tools.
But serious enough that, in production, it would have caused wrong decisions based on incorrect data.
I didn’t find it with automation.
I found it by understanding the domain.
Value ranges, units, order of magnitude, etc., are some of the things that domain knowledge can provide accurately, and that automation can “missed it”.

The illusion of “covered = safe”

In modern software teams, we often equate:
“We have automation” → “We are safe”

We measure:

test coverage
number of automated checks
number of tests passing

And when everything passes, we assume the system is working correctly.
But here’s the problem:

Automation validates what we expect
Domain knowledge questions what we assume

Automation is excellent at checking:

known scenarios
predefined inputs
expected outputs

But it rarely challenges:

whether the logic itself makes sense
whether the business rules are correctly interpreted
whether the outputs are meaningful in real-world context

What actually happened

While reviewing a workflow in a complex system, I noticed something subtle:
The system was producing results that were:

technically valid
numerically consistent
fully passing automated checks

But…
They didn’t make domain sense.
From a purely technical perspective, everything was correct.
From a domain perspective, something was off.
The values were within acceptable ranges set in the automated system… but unrealistic given the context.
That’s when I dug deeper.

Why automation didn’t catch it

The automated tests were doing exactly what they were designed to do:

validate calculations
confirm outputs match expected formulas
ensure no crashes or failures

And they passed.

Because:

the formulas were implemented correctly
the inputs were syntactically valid
the outputs matched the coded logic

The system was behaving as implemented, not necessarily as intended.

Automation verified:
“Does the code do what it was programmed to do?”
It did NOT verify:
“Does this result make sense in the real world?”

The role of domain knowledge

What made the difference was not a tool.
It was context.
Understanding:

how the system is used in practice
what realistic outputs should look like
how variables interact in real scenarios

allowed me to ask a simple but powerful question:
“Even if this is technically correct… is it actually right?”
That question doesn’t come from tools, it comes from experience and domain understanding.

The real bug

After deeper research and analysis, the issue became clear:

A business rule had been interpreted too simplistically
Edge conditions were technically handled, but not realistically modeled
The system was producing results that were valid mathematically, but incorrect operationally

This kind of bug is dangerous because:

it doesn’t crash the system
it doesn’t raise alarms
it produces plausible but wrong results

These are the bugs that automation often misses.

What this taught me

1) Automation is powerful — but limited
Automation is essential.
It gives speed, consistency, and confidence.
But it is only as good as:

the assumptions behind it
the scenarios it encodes

It cannot question the meaning of results.

2) Domain knowledge is not optional.
Without domain knowledge:

you validate behavior
but not correctness

With domain knowledge:

you validate intent
you challenge assumptions
you detect what “doesn’t feel right”

3) The best testers think beyond test cases.
Great testing is not:

executing steps
checking expected outputs

It is:

asking better questions
exploring beyond predefined scenarios
understanding how the system behaves in reality

Why this matters today

In a world moving fast toward:

AI-generated tests
high automation coverage
rapid delivery pipelines

There is a growing risk:
We optimize for speed, but lose depth
The more we rely on tools, the more valuable human insight becomes.
Especially in:

complex systems
domain-heavy applications
decision-critical software

Final thought

Automation will continue to evolve.
AI will accelerate testing.
But one thing remains true:
Tools can verify logic.
Only understanding can validate truth.
The most critical bugs are not always the ones that break the system.
Sometimes, they are the ones that quietly produce the wrong answer.
And those are the ones you only catch when you truly understand what you’re testing.

If you’re a tester
Don’t just ask:
“Did the test pass?”
Ask:
“Does this result make sense?”
That question might lead you to your most important bug.