Most software teams believe the testing workflow is simple. A developer implements a feature, someone explores it, automated tests are written, CI/CD executes them, and the software is released.
Reality is usually different.
Before teams invest time building maintainable automated test suites, they almost always spend time trying to understand how the system behaves. They modify inputs, test boundaries, send invalid values, experiment with protocols, trigger error conditions, and intentionally attempt to break things.
Increasingly, these activities are not performed manually. They are assisted by fuzzers, mutation engines, schema-driven generators, AI-assisted tooling, and automated exploratory systems capable of generating hundreds or thousands of test variations in minutes.
Yet this phase has never had a widely accepted name.
It is usually called exploratory testing. Sometimes it is called automation. Occasionally it is called fuzzing. In practice, it is something that sits between all of them.
The phase nobody talks about
Imagine a developer creates a new API endpoint.
A single request returns 200 OK. The JSON looks correct. The implementation appears complete.
At this point most teams do not immediately start building large regression suites. First they try to understand what they have actually built.
What happens if a required field disappears?
What happens if a number becomes a string?
What happens when a payload becomes too large?
What happens if authorization is missing, malformed, expired, duplicated, or inconsistent?
These questions are exploratory by nature. But increasingly they are answered through automation.
This is the gap that Automation Before Automation (ABA) attempts to describe.
What is ABA?
Automation Before Automation (ABA) is the practice of automatically generating and executing exploratory, validation, robustness, and protocol-level tests before creating and maintaining traditional automated test suites.
In simpler terms:
ABA is automated exploration before automated verification.
The goal is not regression protection.
The goal is discovery.
ABA attempts to answer a different question:
What should we automate?
Traditional automation answers:
How do we continuously verify it?
Where Rentgen fits
Rentgen was built around exactly this phase.
It starts with a single working cURL request and automatically generates variations designed to expose validation weaknesses, inconsistent behavior, robustness issues, protocol problems, and unexpected responses.
Rentgen is not trying to replace automated test frameworks.
It is not trying to replace CI/CD pipelines.
It is not trying to replace long-term regression suites.
Instead, it helps teams understand how an API behaves before they invest time building and maintaining automation around assumptions that may never have been challenged.
Some generated scenarios will reveal nothing.
Good.
Some will expose ugly implementation details that would otherwise reach production.
Better.
Why this matters
The software industry spends enormous effort discussing exploratory testing and automated testing as if they are the only two phases that matter.
But modern tooling increasingly creates a third layer.
A layer where exploration is automated.
A layer where hundreds of scenarios can be generated before a single maintainable test case exists.
A layer where teams learn what is fragile, what is robust, and what deserves long-term automation investment.
Whether the industry ultimately adopts the term or not, the activity already exists.
Most modern teams are doing it.
They just do not have a name for it yet.
Learn more
The full ABA whitepaper introduces the concept, defines its characteristics, compares it to traditional automation, discusses associated tooling categories, and presents a real-world case study.
Read the complete paper:
Automation Before Automation (ABA): An Intermediate Phase in Modern Software Testing