0% read on this device
Browse the curriculum

Start Here

Vision

First Principles

Operating Model

Domain Model

Agent Factory

Runtime Architecture

AI Engineering

Autonomous Workflows

Verification & Delivery

Factory Platform

Quality Engineering

Security & Governance

Case Studies

Labs

Interview Practice

Research Journal

Reference

Curriculum/Verification & Delivery/A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
Verification & Delivery16 min readchapterQuick Read

Software Testing Strategy for Agentic Change

Define a complete testing system for changes produced or maintained by agents.

Status: Review readyRisk: highLifecycle: plan · execute · verifyContent reviewed 2026-08-30Maturity guide →
Claim boundaryThis is curriculum guidance. It does not by itself prove a production implementation.
study mode

A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.

Quick Read

The chapter in one pass.

~4 min
  • Purpose: Define a complete testing system for changes produced or maintained by agents.
  • Best for: Quality engineers, senior developers, architects, and agent engineers.
  • Prerequisites: Quality and Evidence Architecture.
  • Reading time: 16 minutes.
  • You will learn: How to select complementary test methods, control flaky tests and test data, measure fault sensitivity, and preserve independent evidence.
  • Keep three ideas: passing existing tests is weak evidence; test selection follows risk and change impact; and agent-authored tests must be challenged independently.
Whiteboard exercise

Reconstruct and defend this chapter’s architecture.

Reconstruct the architecture, name each boundary, and defend the tradeoffs.

verificationdelivery16 min chapter
Open the source exercise

Design the test portfolio for a payment API schema change with a browser client, batch consumer, performance SLO, and accessibility requirement. Add one flaky test and one incomplete dependency map.

3. Enduring Principle

Build a risk-based test portfolio

MethodPrimary claimCommon blind spot
UnitLocal logic behaves under controlled inputsIntegration and configuration
IntegrationComponents and dependencies cooperateFull user journey
End-to-endCritical workflow functionsFault localization and speed
ContractProducer and consumer expectations remain compatibleInternal behavior
Property-basedInvariants hold across generated inputsIncorrect properties
MutationTests detect introduced faultsEquivalent or costly mutations
FuzzParsers and boundaries withstand unexpected inputBusiness correctness
Performance/loadLatency, throughput, and resource limitsFunctional intent
AccessibilityInteraction remains usable across access needsProduct value
Visual regressionRendered appearance does not drift unexpectedlySemantic correctness
Security testingKnown abuse classes and policies holdUnknown threats

The Quality Contract chooses methods from change risk, affected behavior, architecture boundaries, data, reversibility, and production impact. No single pyramid or percentage is universally sufficient.

Perform test-impact analysis

Map changed code, APIs, schemas, configuration, dependencies, and behavior to relevant tests. Selection records why a test was included or omitted. High-risk changes run broader suites; low-risk changes may use targeted suites plus periodic full validation. A model may recommend impact, but deterministic dependency and ownership data should constrain it.

Govern agent-generated tests

Require tests to fail against the relevant pre-change behavior or a deliberate fault when feasible. Review assertions for observable outcomes rather than implementation details. Separate the agent that proposes behavior from the validator that evaluates coverage and fault sensitivity.

Treat test infrastructure as production infrastructure

Version fixtures and test data, isolate tenants, remove secrets, define cleanup, track flaky behavior, and retain environment identity. Quarantining a flaky test is visible debt with owner and expiry, not a silent pass.

Bind results to exact subjects

A test receipt identifies source commit, artifact, environment, command, selected tests, exclusions, retries, duration, raw result, and verifier. Rerunning until green without preserving failures destroys evidence.

8. Notes and lessons learned

Test quantity is an activity metric. The important question is whether independent methods can detect the plausible faults introduced by this exact change.

9. Interview and discussion questions

  1. How do you validate an agent-generated test?
  2. When is targeted test selection safe?
  3. What should happen to a flaky required gate?
  4. How do unit, contract, and end-to-end evidence complement each other?
  5. Which test failures should affect agent trust?
External review

Review this chapter.

Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.

  • Claim
  • Boundary
  • Failure
  • Evidence