Testing & Findings
Testing methods
How to find the limits of AI systems. Each method is backed by the real findings it has surfaced — and ranked by how much it surfaces, weighted by severity. The durable knowledge is the technique, not the patched-away bug.
Most productive methods
- 1Differential testing7 findings · 7 versions
- 2Prompt-injection & jailbreak testing4 findings · 4 versions
- 3Boundary & edge-case testing7 findings · 6 versions
Ranked by a severity-weighted yield score. Why we measure this →
28 methods
A/B testing in production
Serve two variants — prompts, models, or settings — to comparable slices of real traffic and let live outcomes decide which behaves better.
Adversarial prompting
Deliberately craft inputs designed to elicit failure — confusion, unsafe output, or broken constraints — to map the model's weak boundaries.
Benchmark evaluation
Score the model against a fixed, known-answer dataset so performance becomes a number you can track across versions and compare across models.
Bias auditing
Measure outcome disparities across a population of demographically varied inputs, reporting fairness as statistics rather than anecdotes.
Boundary & edge-case testing
Push inputs to limits — very long contexts, token boundaries, empty/extreme values — where behavior tends to degrade sharply.
Canary releases & staged rollout
Route a small slice of real traffic to a new model or prompt first, watch it closely, and widen or roll back based on what the canary shows.
Chain-of-thought faithfulness probing
Test whether a model's stated reasoning actually determines its answer, or is a post-hoc rationalization.
Chaos engineering for AI systems
Deliberately inject failures — tool timeouts, malformed tool responses, truncated context, adversarial inputs — to test whether the system degrades gracefully and recovers.
Counterfactual bias probing
Hold a prompt fixed while swapping a protected attribute (name, gender, ethnicity) — the output should not change. When it does, you've measured bias.
Differential testing
Run the same input across models or versions and treat divergence as a signal worth investigating.
Distillation & model-extraction probing
Probe whether a deployed model can be cheaply queried to reconstruct its behaviour, training data, or a usable distilled copy — a confidentiality and IP attack surface.
Distributional testing (KS test, Monte Carlo)
Sample the model many times and test the distribution of its outputs — not any single answer — for drift, miscalibration, or instability.
Drift & decay monitoring
Re-run a fixed suite against each release and over time, watching for the quiet regressions and capability decay that a one-off evaluation can't see.
Factual oracle verification
Check generated claims against a trusted ground-truth source to catch hallucinations and fabricated citations.
Glitch-token & unicode fuzzing
Feed anomalous tokens, rare unicode, homoglyphs and malformed encodings to trigger out-of-distribution behavior.
Hallucination triggering
Deliberately steer the model toward fabrication — asking about non-existent entities or beyond its knowledge — to map where it invents instead of declining.
Integration testing (MCP handshakes & tool contracts)
Exercise the seams where the model meets the rest of the system — tool and function contracts, MCP handshakes, retrieval calls, API auth — to catch connectivity and contract failures end to end.
Logic & consistency testing
Check that the model's outputs obey the rules of logic — valid inference, transitivity, symmetry, no self-contradiction — across related questions.
Metamorphic testing
Test without an oracle by checking relations between the outputs of related inputs, instead of judging any single output in isolation.
Model-graded evaluation (LLM-as-judge)
Use a strong model as an approximate oracle — grading, comparing, or fact-checking another model's output where no cheap ground-truth label exists.
Needle-in-a-haystack (long-context retrieval)
Plant a specific fact at varying depths in a long context and test whether the model can retrieve it from each position.
Perturbation testing
Apply small, meaning-preserving changes to an input — typos, spacing, paraphrase, reordering — and check that the output stays stable. When it doesn't, you've measured brittleness.
Prompt-injection & jailbreak testing
Embed adversarial instructions in user input or retrieved/tool content to test whether the model follows attacker text over its system policy.
Property-based testing
Specify invariants the output must always satisfy, then generate many inputs automatically and check the invariant on each.
Self-consistency probing
Ask the same question multiple times (or multiple ways) and measure how often the answers agree.
Smoke testing in CI/CD
A fast, shallow pass on every build — a handful of canonical prompts and health checks — whose only job is to fail loudly on gross breakage before anything deeper runs.
Threshold testing
Walk inputs across a decision boundary — refusal, classification, confidence cutoff — to find exactly where the model's behaviour flips, and whether it flips in the right place.
Unit testing the deterministic scaffold
Test the deterministic code around the model — prompt builders, output parsers, schema validators, tool wrappers — in isolation, with exact assertions, the way you'd test any software.