Most test design starts from the wrong artefact. A tester reads the built screen, or the ticket, or the code, and writes cases describing what is there. The result covers the implementation and quietly inherits every assumption the implementation made, including the wrong ones.
Coverage that means something starts one step earlier: from the requirement, before or alongside the build. TestCraft is the stage of the ReqLens pipeline that does this, and this guide covers both how to use it and why it is shaped the way it is.
What TestCraft takes as input
TestCraft does not read your codebase. It reads an elaborated requirement: the structured output of Requirement Studio, carrying acceptance criteria, business rules, data expectations, and the negative paths that the elaboration surfaced.
This matters more than it sounds. The quality ceiling of generated coverage is set by the requirement, not by the generator. A vague requirement produces vague tests no matter how good the model is, because there is nothing specific to test against.
Sparse or generic test cases are almost always a signal that the requirement lacks acceptance criteria or explicit rules. Fixing the requirement is faster than editing fifty test cases, and it fixes every downstream artefact at once.
The generation flow
- Select the scope. A requirement, a feature from the decomposed backlog, or a set of use cases. TestCraft normalises whichever you pick into a single scope definition.
- Review the proposed suite. TestCraft returns a structured suite: test cases with steps, expected results, preconditions, and a priority assigned by the rule engine rather than by guesswork.
- Approve, edit, or reject case by case. Nothing enters your suite because a model produced it. You decide, and your edits are what gets stored.
- Generate test data. Structured data sets attach to cases that need them, including parameterised variants for data-driven execution.
- Export or execute. Push to TestExecute for run tracking, or export to Xray, TestRail, Zephyr, CSV, Excel, or Gherkin.
Why priority is computed, not asked for
Ask a person to prioritise sixty test cases and you get a reasonable answer for the first ten and fatigue for the rest. Ask a model and you get plausible-sounding labels with no consistent basis.
TestCraft assigns priority through a rule engine reading properties that are actually knowable: whether the case covers a stated acceptance criterion, whether it exercises a negative or boundary path, whether the underlying requirement is flagged high risk, whether the flow touches money, identity, or data integrity.
The result is consistent across suites and, more importantly, explainable. When a Delivery Manager asks why forty cases are marked critical, there is an answer that is not "the model decided."
Reading coverage honestly
A coverage percentage is only as honest as the denominator underneath it.
| What gets counted | What it actually tells you |
|---|---|
| Test cases written | Volume of work done, nothing about risk |
| Requirements with at least one test | Whether anything is completely untested |
| Acceptance criteria with a mapped test | Whether the agreed contract is verified |
| Negative and boundary paths covered | Whether you tested the failure modes, not just the happy path |
The third and fourth rows are the ones worth reporting. A suite where every requirement has one test looks complete and can still miss every edge case that will actually break in production.
Key takeaways
- Generated coverage inherits the quality of the requirement, so fix requirements upstream rather than patching tests downstream.
- Priority computed from stated properties is explainable, priority assigned by a model is not.
- Coverage against acceptance criteria is a meaningful number, coverage against test count is not.
- Every generated case passes through human approval before it becomes part of your suite.
What this gives each role
QA Engineers get a first draft in minutes rather than a blank page, with negative paths and boundary conditions already proposed, and full editorial control over what survives.
Business Analysts get a feedback loop. If a requirement cannot produce a meaningful test, the requirement has a gap, and TestCraft surfaces that before anyone writes code.
Delivery Managers get a defensible readiness picture: what is covered, what is not, and which uncovered items carry risk, traced from requirement through test to execution result and defect.
Product Owners get a concrete answer to whether the acceptance they agreed to is actually being verified.
The principle underneath all of it
Nothing TestCraft generates enters your project without a person approving it. The model proposes, you dispose. That is not a safety disclaimer bolted on afterwards, it is the design constraint the whole pipeline is built around, and it is why the output is something you can put your name to in a release review.