Introduction to AI-Powered Testing

“AI-powered testing” covers two very different things, and mixing them up causes most of the confusion in this space:

1. Using AI to help test software: drafting test cases, generating test data, writing automation code, triaging failures, driving a browser.
2. Testing software that contains AI: checking that an application built on a large language model (LLM) behaves acceptably, safely and consistently.

This path covers both. This lesson sets up the mental model, the vocabulary and a clear line between what teams do routinely today and what is still being worked out.

What an LLM actually does

An LLM is a model trained on large amounts of text to predict likely continuations of a sequence of tokens (word fragments). Given a prompt, it generates a response one token at a time. Several practical consequences follow for testers:

• It produces plausible output, not verified output. An LLM can write a convincing test that asserts the wrong thing, or reference an API method that does not exist. This is usually called hallucination.
• Output can vary between runs. Sampling settings such as temperature introduce randomness, and even at low temperature, providers do not generally guarantee identical outputs. Treat responses as non-deterministic.
• It only knows what it was trained on and what you give it. Training data has a cut-off date, and the model has no knowledge of your private codebase or requirements unless you put them in the prompt or connect it to them through tools.
• Context is limited and costly. Each model has a maximum context window, and providers typically charge per token.

The model has no built-in notion of “correct”. That judgment is still your job, which is good news for testers: evaluating output against requirements is exactly the skill AI assistance needs.

The landscape

Established practice

These are widely used, low-risk when combined with human review, and covered in the next lessons:

• Drafting test ideas and cases from requirements, user stories or API specs, then reviewing and pruning them.
• Writing and refactoring automation code with an AI coding assistant in the editor: scaffolding page objects, converting a test between frameworks, explaining an unfamiliar codebase.
• Generating test data: realistic names, edge-case strings, JSON payloads matching a schema, with the output validated before use.
• Summarising and explaining: turning a long stack trace or log into a hypothesis, or explaining a failing test to a new team member.
• Testing LLM applications with evaluation suites: golden datasets, assertion-based checks, reference-based metrics, LLM-as-judge with calibration, and human review.

Emerging practice

These are real and actively developing, but tooling, reliability and best practice are still settling:

• Agentic testing: an AI agent given a goal (“verify a user can reset their password”) that plans steps, drives a browser through tools and reports findings.
• Model Context Protocol (MCP) servers that connect AI assistants to browsers, test management systems, logs and databases.
• AI-based self-healing that updates broken locators or steps automatically.
• Autonomous test generation at scale from crawling an application.

The oracle problem does not go away

A test needs an oracle: a way to decide whether the output is correct. AI makes generating actions and inputs cheap, but it does not automatically supply trustworthy oracles. If an LLM writes both the code and the tests from the same misunderstanding, both will agree and both will be wrong.

Practical consequences:

• Anchor generated tests in an independent source of truth: the requirement, the API contract, a domain expert.
• Prefer assertions you can verify mechanically (status codes, schemas, exact values from a specification) over assertions the model “thinks” are right.
• Check that a new test can fail. Break the code deliberately, or run the test against a known-bad version.

Risks to manage

Over-trust

Generated code looks finished. Reviewers skim it. The most common failure mode is not dramatic; it is a test that runs green while asserting almost nothing. Review AI-written tests at least as strictly as a junior colleague’s first pull request.

Data exposure

Prompts may contain source code, customer data, credentials or unreleased product details. Before using any AI tool at work:

• Check your organisation’s policy and which tools are approved.
• Understand the provider’s data retention and training terms for the plan you use.
• Never paste production personal data, secrets or tokens into a prompt. Use synthetic data.

Non-determinism in your pipeline

If an LLM call sits inside a test (for example, to judge output), the test itself becomes probabilistic. That is manageable with multiple samples and thresholds, covered in Testing LLM Applications, but it must be designed, not discovered.

Cost and latency

Model calls cost money and time. A suite that makes thousands of model calls per run can become slow and expensive. Cache, sample and run expensive evaluations on a schedule rather than on every commit where appropriate.

A simple decision framework

Before adding AI to a testing task, ask:

Question	If yes	If no
Can a human quickly verify the output?	Good fit for AI drafting	Be cautious; verification cost may exceed savings
Is the task repetitive but varied (many similar cases, data variants)?	Good fit	Hand-writing may be just as fast
Is a wrong answer cheap to catch and fix?	Good fit	Keep a human in the loop at every step
Does the prompt need sensitive data?	Use synthetic data or an approved internal tool	Proceed with normal care
Is the result going to gate a release?	Use deterministic checks; AI as advisory only	AI can lead

What changes for the tester’s role

AI assistance shifts effort from typing to judging. The valuable skills become:

• Writing precise specifications and prompts, because vague input yields vague tests.
• Reviewing generated tests for real coverage, determinism and meaningful assertions.
• Designing oracles and evaluation criteria, especially for AI features themselves.
• Understanding risk well enough to know where automation, AI-assisted or not, is not enough.

These are the skills of a senior tester. AI makes them more important, not less.

Practice exercise

Classify each task below as a good fit for AI assistance today (with review), emerging (use cautiously, advisory only) or a poor fit. Give a one-line reason for each.

1. Drafting boundary-value test cases for a password policy from its written rules.
2. Letting an agent decide whether the release candidate is ready to ship.
3. Generating 50 varied but schema-valid JSON order payloads for an API test.
4. Having an agent explore a staging site overnight and list suspected bugs.
5. Writing assertions for a pricing calculation when no specification exists.

Show a model answer

1. Good fit. The rules are an explicit oracle, and a reviewer can quickly check the cases against them. Watch for missed boundaries.
2. Poor fit. A release decision needs accountable judgment and deterministic evidence; an agent’s verdict is non-deterministic and can be wrong.
3. Good fit. Validate every payload against the JSON Schema before use; reject anything that fails.
4. Emerging. Useful as a source of leads, but each suspected bug must be reproduced and confirmed by a person; expect false positives.
5. Poor fit. With no specification, the model will invent expected values. Clarify the rules with the product owner first; the missing oracle is the real problem.

Key takeaways

• “AI testing” means both using AI to test and testing AI; keep them distinct.
• LLMs produce plausible, non-deterministic output with no built-in notion of correctness.
• Established: drafting tests and data with review, coding assistants, summarisation, evaluation suites for LLM apps.
• Emerging: agents, MCP-driven workflows, AI self-healing and autonomous generation; use them as advisory.
• The oracle problem remains; anchor tests in independent sources of truth and confirm they can fail.
• Manage over-trust, data exposure, non-determinism and cost deliberately.