Software testing is usually described in two large categories: exploratory testing and automated testing. Exploratory testing is about investigation and discovery. Automated testing is about repeatable verification and regression protection. Both are well established, well documented, and widely practiced.

In real projects, however, the workflow is rarely that clean.

After implementing a new endpoint or modifying existing functionality, teams do not immediately start by building a long-term automated regression suite. First, they try to understand how the system actually behaves. They vary inputs, test boundary conditions, send invalid data, alter payload structures, observe status codes, and look for unstable behavior. Increasingly, this is not done purely manually. Teams use fuzzers, mutation tools, schema-driven generators, and AI-assisted test generation to execute hundreds of variations in minutes.

The purpose of this activity is not regression protection. The generated tests are often temporary and disposable. Their value lies in the information they reveal quickly: weak validation, inconsistent error handling, unexpected 500 responses, protocol inconsistencies, or fragile assumptions in the backend.

Despite being common, this phase has no widely accepted name. It is often grouped under exploratory testing, even though it involves automated generation and execution. It is also sometimes confused with traditional test automation, even though it does not produce long-term maintainable suites integrated into CI/CD.

This intermediate layer deserves clearer definition.

In a recent white paper, I propose the term Automation Before Automation (ABA) to describe this activity. ABA refers to the practice of automatically generating and executing exploratory, validation, robustness, and protocol-level tests before creating and maintaining traditional automated test suites. In short, it is automated exploration before automated verification.

The distinction matters because the goals are different. Traditional automated testing answers the question: how do we ensure this does not break again? ABA answers a different question: what do we not yet understand about this implementation?

Automation focuses on protecting known expectations. ABA focuses on exposing unknown behavior. Automation produces confidence over time. ABA produces information quickly.

With the rise of fuzzing technologies, property-based testing, AI-assisted generation, and automated protocol exploration tools, this intermediate phase is becoming more visible in practice. Yet without a shared vocabulary, it is often undervalued or performed informally. In some cases, teams automate too early, locking in happy-path assumptions before seriously challenging how the system behaves under imperfect input.

The white paper does not introduce a new testing technique. It attempts to formalize and characterize a testing activity that many teams already perform but rarely define explicitly. By naming and structuring it, we can reason more clearly about when it should happen, what tools belong to it, and how it complements rather than replaces traditional automation.

If this resonates with how your team works in practice, you may find the full paper useful.

Automation Before Automation (ABA): An Intermediate Phase in Modern Software Testing - https://qaontime.com/research/automation-before-automation.html

I am particularly interested in perspectives from teams using fuzzing, property-based testing, schema-driven generators, or AI-assisted test generation in early development stages. Is this truly a distinct phase, or simply a reframing of existing practices?