AI Can Generate the Tests. QA Still Has to Define “Correct.”

An AI coding agent can generate twenty tests before you finish your coffee. It can add edge cases, run the suite, and report a green check.

But there is a question those green checks cannot answer on their own:

Who decided what the correct behavior was?

If the requirement is ambiguous, an AI can produce a large, convincing test suite that verifies the wrong interpretation. More tests do not fix a missing definition of quality.

This is becoming a practical QA problem, not a distant prediction about the future of testing.

The testing gap is already visible

Two 2026 industry surveys point to the same tension: AI is spreading through development and testing, while teams are still struggling to keep quality controls aligned with the speed.

  • SmartBear's 2026 State of Software Quality and Testing surveyed 1,436 US and UK practitioners and leaders using AI in development. It found that 46% of teams had shipped AI-written code that later failed in production. Only 46% said they validate the specification before AI generates code. SmartBear, September 30, 2026.
  • Applause's 2026 State of Digital Quality reported that more than 92% of respondents use AI in testing, while 29% said the number or severity of defects had increased. 86% considered human involvement extremely important to functional testing. Applause, September 30, 2026.

These are industry surveys, not controlled experiments, and they do not prove AI caused every defect. They do show that generating and running tests is not the same as establishing that a product behaves correctly.

A review published on November 5, 2026, synthesizing 113 peer-reviewed studies, also identifies semantic correctness, non-deterministic outputs, maintainability, verification, and evaluation consistency as persistent challenges in generative-AI software engineering. Yang Lu, Generative AI for Software Engineering, 2026.

The missing piece: a test oracle

A test oracle is the source of truth that tells us what the expected result should be.

Consider this requirement:

Apply a 10% discount to orders over $100.

An agent can turn that sentence into tests immediately. But it still has to guess:

  • Is the threshold strictly greater than $100, or greater than or equal to $100?
  • Is the discount calculated before tax and shipping?
  • Can a coupon be combined with another promotion?
  • How should the result be rounded?
  • What happens if the order contains an excluded item?

If the agent guesses differently from the product owner, the tests may pass while the product is wrong.

Before asking AI to generate tests, turn the requirement into observable rules.

For example:

Acceptance contract

  • The threshold is evaluated against the eligible item subtotal before tax and shipping.
  • The discount applies only when that subtotal is greater than $100.00.
  • The discount is 10% of the eligible subtotal.
  • The discount is rounded to two decimal places using the product's documented rounding rule.
  • Shipping is calculated separately.

Now the boundary is explicit. The test suite has something independent to check against.

A small example: test the boundary, not the implementation

Here is a simple pytest example. The expected values come from the acceptance contract, not from asking the AI what its own code should return.

from decimal import Decimal import pytest @pytest.mark.parametrize( ("subtotal", "expected_discount"), [ (Decimal("99.99"), Decimal("0.00")), (Decimal("100.00"), Decimal("0.00")), (Decimal("100.01"), Decimal("10.00")), ], ) def test_save10_discount(subtotal, expected_discount): assert calculate_discount(subtotal) == expected_discount

The important case is exactly $100.00. It catches the difference between > and >=.

You can ask an AI agent to add more cases, but first make it explain which acceptance rule each case protects. If it cannot map a test to a requirement, the test may be noise.

A practical workflow for AI-assisted QA

I use a five-step mental model for reviewing generated tests.

1. Write the expected behavior first

Keep acceptance criteria separate from implementation details. Describe inputs, outputs, boundaries, permissions, and failure behavior.

A useful prompt is:

Do not write tests yet. First list ambiguities in this requirement. Ask which decisions need a product or QA answer. Do not invent expected behavior.

This is often more valuable than immediately asking for test code.

2. Generate tests from the contract

Once the rules are clear, ask the agent for:

  • Happy-path examples.
  • Boundary values immediately below, at, and above thresholds.
  • Invalid and missing inputs.
  • Permission and role combinations.
  • State transitions and retry behavior.
  • Failure cases that matter to real users.

Ask it to reference the exact acceptance criterion for every test.

3. Challenge the tests

A green test suite can still be weak. Try mutation testing: deliberately change a condition, remove a validation, or reverse a comparison. A useful test should fail when the behavior it protects is broken.

For the discount example, changing subtotal > 100 to subtotal >= 100 should make the $100.00 test fail.

Also check for tests that only repeat the implementation's assumptions. A test that copies the same mistaken condition from the code is not independent evidence.

4. Keep human judgment where the expected result is subjective

Not every requirement has a deterministic answer. Accessibility, usability, relevance, tone, and the quality of an AI-generated response may need human evaluation.

An LLM-as-a-judge can help with these cases, but only when its rubric is explicit and checked against human-labelled examples. A score from another model is not ground truth.

For a practical discussion of this approach, see LLM-as-a-judge: building an AI grader you can actually trust.

5. Measure evidence, not test volume

Avoid treating the number of generated tests or line coverage as proof of quality. Track a few signals that tell you whether the suite protects users:

  • Requirements with at least one meaningful test.
  • Important mutations that the suite detects.
  • Flaky-test rate.
  • Defects escaping to production.
  • Time needed to diagnose a failed test.
  • Cases where a human reviewer rejects an AI-generated expected result.

These measures are imperfect, but they are closer to product risk than counting how many tests an agent created.

What this changes for QA engineers and developers

AI can reduce the time spent writing repetitive test code. That does not remove the need to understand users, identify risk, challenge assumptions, or decide what counts as correct.

The valuable work moves toward:

  • Turning vague requirements into testable contracts.
  • Finding missing states and edge cases.
  • Choosing realistic test data.
  • Evaluating generated tests independently.
  • Testing workflows that do not have one obvious expected output.
  • Explaining why a release is safe enough to ship.

Developers need these skills too. A developer who can generate code and tests quickly but cannot explain the expected behavior is still relying on luck.

The point is not to keep humans involved in every keystroke. It is to keep a clear owner for the quality decision.

When an AI agent writes and passes the tests, who owns the expected result on your team — the developer, QA, product, or nobody?