Building an AI-Assisted API Automation Core from QA Knowledge

Create a safe, traceable source set

The first step is curation, not prompting. I group the material by purpose: product requirements, test-case criteria, framework and CI conventions, TestOps mappings, and operational runbooks. Every extract keeps a source reference and version context so a reviewer can return to the original meaning. Duplicated or conflicting instructions remain visible instead of being silently merged into one confident answer.

Before the AI layer sees the source set, I remove credentials, personal data, internal addresses, reusable account values, and unrelated operational detail. The model receives the minimum context required for the design question. This boundary improves both security and output quality: explicit contracts, examples, and constraints give the model something it can structure and compare.

• Preserve source, version, owner, and intended audience for every extracted rule.
• Exclude tokens, private URLs, personal data, production payloads, and access instructions.
• Mark conflicts and unknowns as review items instead of resolving them through wording.
• Separate project conventions from product requirements and engineering judgment.

Ask AI for contracts, not copy-pasted code

I ask the AI layer to extract a structured intermediate model: requirement links, preconditions, positive and negative paths, suite purpose, environment inputs, evidence fields, ownership, and coverage questions. The output is designed for review and diffing. Each proposed capability cites the source rule that motivated it and states whether it belongs to shared infrastructure, a service module, or an individual scenario.

This prevents documentation-shaped code generation. A repeated phrase in several guides does not automatically become a base class, and a project-specific example does not become a universal assertion. The model is good at surfacing common vocabulary and inconsistent conventions; engineers decide which patterns deserve an interface, which stay local, and which should be rejected.

• Requirement contract: source link, condition, expected behavior, and unresolved questions.
• Execution contract: module, suite, profile, data ownership, and cleanup boundary.
• Evidence contract: sanitized request, response, timing, identifiers, and TestOps mapping.
• Review contract: AI suggestion, human decision, rationale, and approved change.

Translate the schema into framework boundaries

The reviewed schema maps naturally to a Gradle multi-project build. A core module supplies transport configuration, authentication contracts, serialization, evidence capture, and shared safety mechanisms. Focused service modules own clients, DTOs, business-state builders, domain assertions, and JUnit suites. The repository shares one foundation without turning the core into a second product that knows every endpoint and business rule.

Spring Boot composes clients, token providers, clocks, data helpers, and environment profiles. Required properties are validated at startup, secrets stay in the CI store, and missing targets fail closed. REST Assured keeps HTTP exchanges readable while the evidence layer retains sanitized request and response context. AI can propose the component map and test skeletons; the engineer owns dependency direction, configuration precedence, and every business assertion.

automation-root/
  core/              # transport, config, evidence, shared contracts
  service-a-tests/   # client, DTOs, domain assertions, JUnit suites
  service-b-tests/   # independent product-specific module
  settings.gradle.kts
  build.gradle.kts

Keep generated changes behind review gates

A candidate test follows the same quality gates as a manually authored one. QA checks that it is linked to a requirement, has a clear precondition, covers the intended positive or negative path, remains atomic, is reproducible, and states an unambiguous result. A domain reviewer validates business coverage when interpretation is required. The AI output can accelerate the first draft and critique, but it cannot mark its own case approved.

For code, I review the diff, compile the affected module, run the focused suite, and inspect the generated evidence before promotion. External writes are approval-controlled and repeatable. A failed validation leaves the system of record unchanged. This is particularly important when an assistant proposes annotations, imports, fixture changes, or suite membership that could alter reporting without changing the underlying assertion.

• AI proposes structure, missing paths, and implementation options.
• QA validates intent, oracle, test data, isolation, and evidence.
• Domain reviewers validate requirement coverage and business meaning.
• CI validates compilation, focused execution, artifacts, and mapping consistency.

Validate mappings with deterministic tooling

The final mile should be boring and deterministic. One useful pattern is a small Python utility that performs a read-only TestOps lookup, maps a test full name to its existing case identifier, scans Kotlin test files, and prepares the local annotation change. A dry-run mode shows exactly what would change before any file is edited. The reviewed mode changes only local source; it does not ask AI to create or rewrite remote cases.

This division gives each tool the job it handles best. AI synthesizes a large knowledge set, proposes contracts, and critiques gaps. The utility enforces a predictable mapping transformation. Git and CI expose the diff and execution result. Allure provides the relationship between code, case, launch, and evidence. Human reviewers remain accountable for architecture, security boundaries, coverage, and the final merge.

source knowledge -> AI-assisted schema -> reviewed framework change
                 -> dry-run mapping -> local diff -> focused tests
                 -> CI evidence -> approved merge