How AI Is Changing Software Testing in 2026
A practical field guide to evaluating probabilistic features, retrieval, agents, permissions, and failure recovery without abandoning proven QA fundamentals.
Key takeaways
- AI quality is measured against criteria and risk, not one exact expected sentence.
- Retrieval, prompts, tools, permissions, and recovery must be tested as separate system boundaries.
- Human review and curated evaluation datasets complement automation; neither is sufficient alone.
The test oracle has changed
Traditional software is usually deterministic at the level QA observes: given the same state and input, a tax calculation or validation rule should return the same result. A language model is probabilistic. Two answers can use different words and both be acceptable, while a fluent answer can still be dangerously wrong. Exact string matching is therefore too strict for wording and too weak for meaning.
Consider a support assistant asked how to refund an order. A useful oracle includes factual correctness, relevance, required policy steps, tone, and whether the answer stays within the customer’s permissions. The expected result is a rubric, not a paragraph. Deterministic checks still protect the surrounding system: the right customer record was retrieved, currency was formatted correctly, and no refund occurred without confirmation.
- Separate hard invariants from qualities that need scoring or review.
- Define unacceptable outcomes before debating ideal phrasing.
- Record model, prompt, context, tools, parameters, and output so a failure can be investigated.
Test factuality, relevance, and instruction-following separately
A response can be factual but irrelevant, relevant but unsupported, or helpful while ignoring a critical instruction. Treat these as different dimensions. For a résumé assistant, a factuality check asks whether every claimed skill exists in the source résumé. Relevance asks whether the rewrite addresses the target role. Instruction-following asks whether the system preserved dates, avoided inventing metrics, and used the requested format.
Hallucination tests need adversarial cases: missing source information, conflicting documents, misleading premises, and questions whose correct answer is “the supplied material does not say.” A system that confidently fills gaps is not rescued by polished prose. Capture the unsupported claim and the evidence available at generation time.
Vary prompts, context, and repetition
One successful prompt proves little. Run semantically equivalent inputs with spelling errors, reordered constraints, indirect wording, long context, and irrelevant details. Repeat important cases to estimate consistency. You are looking for unstable decisions, not identical sentences.
Create small families of cases around a risk. For an interview coach, ask the same question directly, embed it in a long conversation, request an answer in bullets, and include a conflicting user preference. Verify that the core advice and safety boundary remain stable. When a change improves one variant but breaks another, the family makes the regression visible.
- Paraphrase the user intent without changing its meaning.
- Move key instructions to the beginning and end of the context.
- Test empty, oversized, stale, contradictory, and multilingual inputs.
- Repeat high-risk cases enough times to expose intermittent failures.
Retrieval and RAG need their own evidence
A retrieval-augmented generation flow can fail before the model writes anything. The right document may not be indexed, chunk boundaries may remove a qualification, ranking may prefer an older policy, or the model may ignore retrieved evidence. Evaluate retrieval and generation independently so a vague “bad answer” does not hide the failing layer.
For each evaluation case, identify the documents that should be found, acceptable alternatives, forbidden sources, and the answer supported by them. Test tenant isolation, access revocation, document updates, duplicate versions, citations, and “no evidence found” behavior. A citation is useful only when it points to text that actually supports the claim.
Agents introduce actions, permissions, and recovery
An agent can choose tools, pass arguments, observe results, and try again. The final message may look correct even when it called the wrong tool, exposed another user’s data, duplicated an action, or left partial state. Inspect the trajectory as well as the outcome.
Test least-privilege access, confirmation before consequential actions, argument validation, idempotency, timeouts, partial failures, and audit logs. For an application-tracking agent, deny access to one record, make the save call time out after committing, and return malicious text from a tool. The agent should not broaden its permissions, repeat the write blindly, or follow instructions found inside untrusted tool output.
- Verify which tool was selected and why its arguments were allowed.
- Simulate dependency failure before, during, and after a side effect.
- Confirm the user can understand, stop, and recover a multi-step action.
- Check that retries do not create duplicate messages, payments, or records.
Use evaluation datasets and human judgment together
Start with a versioned dataset of real tasks, critical boundaries, known failures, and difficult edge cases. Give every case a reason for inclusion and an explicit rubric. Use deterministic assertions for structure and policy invariants, model-assisted scoring only where its limitations are understood, and human review for ambiguous or high-impact quality.
Do not reduce a multidimensional feature to one average score. Track severe failures separately and review slices such as language, account type, document length, and permission level. A release that raises average helpfulness while leaking restricted context is not an improvement.
What should a QA engineer do next?
Keep the fundamentals: requirement analysis, equivalence classes, boundaries, state transitions, exploratory testing, observability, and precise defect reports. Add enough prompt design, retrieval concepts, basic scripting, data analysis, and security thinking to test the new boundaries. Use AI to draft variations, summarize logs, or suggest missing cases—but verify every artifact against the product and risk.
A useful first project is a 25-case evaluation set for one narrow AI feature. Define five hard invariants, five adversarial inputs, five retrieval cases, five prompt variations, and five recovery scenarios. Run it repeatedly, review failures with the team, and turn escaped defects into permanent regression cases.