See which requirements are proven, and which have holes
Link every requirement to the test cases that cover it, and coverage stops being a number you count. You see the requirement, its cases, and the one that never ran.
Built in and included · or linked from your tracker
A guest can complete checkout without creating an account.
- Add to cart as a guestpassed
- Checkout without an accountpassed
- Shipping address validatedpassed
- Declined card is handledfailed
- Guest order confirmation emailnot run
“Is this feature tested?” is not a pass rate
A tool can tell you four hundred tests ran and three hundred and ninety passed. It still can't tell you whether the thing you are shipping is covered. Link each requirement to the cases that verify it, and the answer becomes a lookup: “proven, except one case that hasn't run.”
Coverage you can act on, not just count
See what is proven
Each requirement shows the cases that cover it and how they last ran.
Find the holes
The requirements with no cases are a short, specific list you can act on.
Catch the untested
A requirement can be fully linked and never run — coverage shows that apart.
Answer the release
“Is this covered?” stops being the loudest voice in the room.
Know what a change touches
Edit a requirement mid-sprint and see exactly which cases are now suspect.
Hand an auditor evidence
Each requirement, its cases and their results — recorded as you go, not rebuilt after.
Keep them here, or link where they already live
Requirements are first-class here — or a link to the issue you already wrote. Either way they map to the cases that verify them, and mixed setups are normal: requirements in Jira, defects in GitHub, tests here.
Built in, in folders
Real objects in TestKase, organised in folders — no tracker to adopt first.
Attachments to 50 MB
Mockups, specs and screenshots ride with the requirement they describe.
Or linked from your tracker
Link to a Jira, GitHub or GitLab issue so the text stays where it is maintained.
Frequently asked questions
No. Requirements are first-class objects in TestKase — folders, attachments, and mapping to the test cases that verify them — and they are included rather than sold as a module. Several tools in this category assume a tracker so thoroughly that requirements management is unavailable without one; here it works either way.
Link. A copied requirement is out of date the first time somebody edits the original, and a stale requirement is worse than none because it still looks authoritative. Link to Jira, GitHub or GitLab issues and the text stays where it is maintained.
Which requirements have test cases, which have none, and which have cases that have never been run. The third group is usually the surprise — a requirement can be fully linked and still entirely unverified, because linking and executing are different acts.
Read the guide: Requirements traceability matrix guide →It is usually a warning. Coverage measures links, not testing, and the fastest route to a hundred per cent is attaching whatever cases exist to whatever requirements exist. The useful view is the inverse: the requirements with no cases at all, which is a short, specific and actionable list.
More than one, almost always. A requirement worth writing has a happy path, at least one boundary and usually a failure mode, and each of those is a case. When you see a requirement with exactly one case attached, it is worth checking whether it was covered or merely linked — the two look identical in a coverage report and are not the same thing at all.
Jira, GitHub and GitLab, plus the built-in objects. Defects can be filed to more destinations than that; requirement linking is this narrower set. Links are made deliberately, not inferred — nothing guesses which requirement a case belongs to, which is why coverage is only as good as the linking discipline behind it.
Yes, and that combination is common — requirements in Jira, defects in GitHub, tests here. What matters is that each object lives in exactly one place and is linked from the others, rather than being duplicated and drifting.
It can be false, it is one thing rather than several joined by 'and', it names the boundary and failure behaviour rather than only the happy path, and it still makes sense read alone months later. Requirements with those properties produce cases; the rest produce meetings.
No to both. Test cases and test cycles carry version history here; requirements do not, and there is no sign-off state on a requirement. If your process needs to prove what a requirement said on a particular date or record approval against a revision, keep it in a tracker that does that and link to it.
Find out which requirements have no tests
It is a shorter list than you expect, and it is the one thing coverage reporting tells you that you could not have guessed.