A lot of API testing still begins the same way: send one valid request, get a 200 back, and move on. The problem is that a single successful response proves almost nothing about how the API behaves when its assumptions are disturbed.
It does not tell you what happens with malformed input, boundary values, missing authentication, oversized payloads, unsupported methods, or inconsistent protocol behavior. And by the time these things are checked properly, teams are often already deep into writing and maintaining full automation suites.
That gap is what I call Automation Before Automation (ABA): an early discovery phase that happens after a request first works, but before a maintainable regression model exists.
For APIs, this means taking one known-good request and systematically challenging it:
- invalid values
- boundary conditions
- missing fields
- malformed structures
- protocol edge cases
- security hygiene checks
- early performance signals
The goal is not to replace proper automation. The goal is to generate broad, reviewable evidence quickly enough to show how the API actually behaves before you invest in long-term tests.
That is the idea behind Rentgen: a deterministic, local-first API testing tool that expands one working request into structured mutations and protocol checks, then records what the system really does.
It is not meant to prove business correctness or replace domain-specific tests. It is meant to expose validation gaps, protocol inconsistencies, weak error handling, and other early signals that teams often discover too late.
If that idea resonates, I wrote a full white paper on it here:
RENTGEN: Behavior-First API Testing Before Automation
https://qaontime.com/research/rentgen-white-paper.html
Top comments (0)