Why the World Is Doomed While You Write Test Cases

There is no chance to save the Amazon forests, the endangered species, or the clean air around us while we keep creating test cases for the sake of creating test cases. Somewhere along the way, we lost the plot on building quality products. We set ourselves a monstrous list of abstract test cases, billions of steps deep, and then we rush to hand that repetitive burden to automation.

Bill Gates said it best: “The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”

Read that second rule again. That is what most QA teams do every single day. To save the world you don’t need to fly to the Amazon. You need to stop writing test cases before the specification exists.

The One Distinction Everyone Blurs

Before we argue, let’s pin down two words the industry uses interchangeably and shouldn’t:

Test Case: A set of input values, execution preconditions, expected results, and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.
Specification: A detailed and precise description of a system’s behavior, features, and constraints. It serves as a basis for designing, developing, and testing the system. Specifications can include functional requirements, non-functional requirements, and design specifications.

Catch the difference? A specification is the exact description of what we design, then build, then test. It exists before the first programmer types a single line of code.

It may never be formalized, but it is always there in someone’s head. The developer implements their interpretation of it. The tester tests their interpretation of it. When those two interpretations disagree, you find it during testing. When both interpretations disagree with the real specification, you find that out the worst possible way: when the customer opens the product.

Answer These Questions Honestly

Stop for a moment and answer for your own project:

Are there formalized specifications at all?
Are they up to date, and how exactly do you keep them current?
How many of your specification checks are automated?

I am willing to bet that on most projects the specifications are either ignored or riddled with gaps around functionality that already ships. This isn’t the exception anymore. It has quietly become the rule.

The Seven Costs You Are Already Paying

When the specification is missing, the test suite tries to become the specification. It fails at the job, and here is the bill you pay for it. Each item is a mistake I have watched teams repeat, and each carries a visible cost:

No single source of truth. Specifications live in three chat threads, a stale wiki, and one senior engineer’s memory. So the team burns hours arguing “bug or feature?” and onboarding a new hire takes weeks instead of days.
You formalize nothing before coding. So you cannot honestly estimate the priority or complexity of building a feature, testing it, or automating those tests. Every estimate is a guess dressed as a number.
One test case can cover any number of specifications. So “412 test cases passing” tells you nothing about coverage. The metric looks precise and means nothing.
A test case name never reflects everything it checks. So finding the one case that covers a specific rule turns into a scavenger hunt through step lists.
You don’t automate checks on the format and content of the specs themselves. So redundant or contradictory rules can only be caught by a human reading everything, which no human does.
Your QA specialist is the knowledge base. So the day they resign, the test suite becomes an unreadable artifact nobody can safely change.
Editing an old test case means holding hidden conditions in your head. So every edit risks silently breaking coverage you forgot was there, and the fear of that breeds apathy and slowdown.

Notice the shape of the problem. None of these are testing failures. They are all specification failures wearing a testing costume.

Shift Left Means Shift to the Spec

On most projects I’ve worked on, the requirements were described most accurately at the moment someone sat down to automate the tests. Think about how backwards that is. By then the feature is already built and the money is already spent. Automation at that stage does nothing to move the product closer to what the customer wanted. It just laminates whatever exists: at best it protects the current behavior from change, at worst it locks the implementation in place and blocks improvement.

Building a shed from scrap wood is cheaper and faster than drawing a blueprint first, right up until the roof leaks. Then you start counting the boards, the nails, and the weekends you threw away. Skipping the specification feels cheaper at the start for the same reason, and it fails for the same reason.

The foundation is the specification. Test cases are built on top of it. Test cases are secondary.

Here is the question that exposes the whole illusion. If I write 100 test cases, what fraction of the functionality have I covered? If I write 1,000, have I covered all of it? What number guarantees “enough”? When a feature changes, how many of those cases must I rewrite? Without a specification, every one of those answers is a shrug.

With a specification, the answers are arithmetic. You know precisely what must be checked and how. You can automate the whole chain, from validating the specifications themselves to collecting real coverage metrics. Gojko Adzic lays out exactly how to do this in his book Specification by Example, and the approach works even for specialists with no coding background. It also shows how to keep living documentation alive off the back of those specifications, so the spec never rots into another stale wiki.

Why We Keep Skipping the Step That Would Save Us

I keep asking myself why we don’t just write the specifications. We all say we want to “shift testing left,” yet the actual work of shifting left is formalizing the spec, and instead we shift left by automating test cases. We move the wrong thing.

My best guess is that the industry expects constant change, and constant change is the symptom of weak planning. When you plan badly, an exact blueprint feels like wasted effort, so you skip it and pay later.

This isn’t only your problem or your team’s problem. Running actions and checks against a guessed interpretation instead of a real specification wastes machine time on a massive scale. That waste is why we keep buying more servers and more power to brute-force our way through inefficient suites. The carbon footprint of that decision is the air you breathe when you step outside.

If you are still worried we’re living in the Matrix, relax. Humanity never has enough computing power. No machine could ever be built to withstand the full force of our inefficiency.

Start Before the First Line of Code

You cannot save the rainforest from your keyboard, but you can stop magnifying inefficiency with automation, and that is where the waste actually compounds. Pick your next feature. Before anyone writes a line of code, write the specification, then build the test cases on top of it, then automate the check on the spec itself.

Write specifications. Follow specifications. Make the world better.