🧪 Test Management: Xray & Zephyr

Test Management: Xray & Zephyr: An aircraft keeps two separate logbooks: fault records (what broke, when, how it was cleared) and maintenance checklists (which check, before whic

An aircraft keeps two separate logbooks: fault records (what broke, when, how it was cleared) and maintenance checklists (which check, before which flight, performed by whom). Both are mandatory and neither substitutes the other. Jira alone keeps the first book; add-ons like Xray or Zephyr add the second. The question worth pausing on: you already keep bugs in Jira, so what would you lose by writing test cases there as plain issues too? What you lose is relationship: a flat issue list cannot express that one test case is RUN many times, that each run has its own result, and that the result belongs to a release. A test definition and a test run are different things. Compare: you write a test class and it runs every night. The class exists once; the run records number in the hundreds. Whatever the distinction is between a JUnit report and test source code, that is the distinction between a Test issue and a Test Execution issue. The real gain for QA is the traceability matrix: once the chain from a requirement to its tests, from tests to their latest run results, and from failed runs to the bugs they produced is in place, the question "what was tested in this release and which requirement was never verified" is answered by one screen instead of guesswork.

🧭 What You Will Learn in This Tab

We will cover why Jira alone does not do test management; the new issue types Xray/Zephyr introduce (Test, Test Set, Test Plan, Test Execution, Precondition) and how they relate; the traceability matrix; how automation run results flow into Jira; and a comparison of the two tools with the criteria behind the "which one" decision.

🎬 A Test Case's 50 Runs: The Difference Between Definition and Result

Test Definition: TC-42

The scenario "a coupon is applied once per order" is defined ONCE: TC-42. But this definition will be run DOZENS of times in the future -- with every release, every regression pack. In this film you will watch how the definition SEPARATES from its runs.

Step 1 -- Run against build 2026.8.1: PASS. This result does not belong to TC-42 ITSELF, it belongs to this SPECIFIC run of TC-42 against build .1 -- the definition stays unchanged.

Step 2 -- The SAME test definition runs again against build 2026.8.2: FAIL. The definition never changed, only the PRODUCT it ran against did -- and this run gives birth to bug SHOP-142.

Step 3 -- After the fix, the SAME definition runs a third time against build 2026.8.3: PASS. TC-42 now has THREE separate run records in its history: PASS, FAIL, PASS -- all results of the same definition at different times.

Finale (the contrast) -- If this information were kept in a flat issue list, there would be ONE record for TC-42 -- its latest state would show "PASS" and the FAIL against build .2 would be completely lost. Thanks to Test Execution records, the question "how many times, in which builds, did this scenario fail" is never lost -- this is the raw material of the traceability matrix.

1️⃣ H1. Bug Tracking Is Not Test Management

TC-42 was run three times against three different builds (PASS, FAIL, PASS), but this information is kept as a single record in a flat issue list. What information is lost?

Nothing is lost, the latest state is enough

Which build it failed against, and which bug that failure produced, is lost