Blog
How independent verification works, what changes when agents write software, how to run test management in Jira Cloud without the bloat, and how to migrate without losing your history. Written by the people building TestWarden.
An audit asks you to reconstruct what was tested, on which version, with what result and who decided. Six linked records make that a lookup instead of an archaeology project.
A green job means a process exited zero. A quality gate needs complete reports, an exact build identity and a decision that reads both. Here is how the pieces fit.
When AI writes more code than anyone can retest, you need a principled way to choose. Here is what each selection method knows, what it cannot know and how to avoid false confidence.
A rerun that turns red to green is information, not absolution. The arithmetic of retries, a PASS-FAIL-PASS timeline and four gate policies, compared on the same attempts.
When the agent writes the code and the tests, a green check is the agent agreeing with itself. Here is a concrete architecture that does not depend on trusting it.
Most release checklists record that someone looked. This one asks what was looked at, which build it described and who can see it later.
An AI that knows testing in general knows nothing about your tests. Quality Memory is the recorded history that lets advice cite what actually happened, without training a model on your data.
Xray, AIO Tests, Zephyr and TestRail answer “what did we test?”. A different layer answers “is it enough?”. You can keep the first and add the second without migrating.
Eight properties separate evidence from a pile of green badges. Use them as a release-meeting checklist and see how missing, stale, conflicting and wrong-build evidence change readiness.
A contract names the obligations; a policy judges the evidence; the build identity decides what counts. A staff engineer’s guide to getting those three right.
A complete runbook for moving AIO Tests cases into TestWarden: export, mapping, preview, row validation, import, reconciliation, and what to keep in AIO instead.
For platform and engineering leaders: the architecture of a verification control plane, the line between evidence producers and decision authority, and an adoption path that keeps every tool you own.
Two worked examples for developers and DevOps: a failing report and a misattributed pass. What HELD contains, why the fix creates a new decision for a new build, and why history is kept.
How to evaluate Xray, AIO Tests, Zephyr Scale, TestWarden or anything else: an interactive scorecard, a trial protocol and the questions that separate demos from daily use.
The object model behind TestWarden’s verification history: what is recorded as authoritative fact, what is advisory interpretation, how tenancy and immutability work, and why this is not model retraining.
Export, check, map, preview, import, reconcile. What the Xray adapter brings (cases, steps, priority, labels) and what stays behind (executions, sets, plans, attachments).
Export from the Zephyr Scale library, save as CSV, map headers and steps, preview and reconcile. Includes the historical-data limits and what stays in Zephyr Scale.
For QA leads: the data-integrity problem behind test execution history, how version pinning solves it, what it does not solve, and a trial you can run on any tool.
A working definition of independent software verification, the five duties that must be separated, how it applies when AI agents write the code, and a rubric for judging whether a tool is genuinely independent.
For engineering leaders adopting coding agents: an interactive workflow of self-validation versus independent verification, why agent-written tests are useful but not clearance, and an honest account of what independence cannot catch.