Exact source
The words behind the work.
A document selection links directly to implementation and verification. Follow the connection back to its source.
Explore requirements traceability →
Connected docs, tasks, and test management.
Yetea
Keep the why
connected to the work.
Connect the exact requirement to the tasks that implement it and the Test Cases that verify it, so product, engineering, and QA can follow the same thread.
Free early access. No credit card required.
Docs explain the why. Tasks track the work. Tests record the evidence.
Illustrated example · Order cancellation
A customer can cancel an order before dispatch. Once dispatched, the order cannot be cancelled.
01 / The living product thread
Follow one idea.
Keep every connection.
A requirement should not lose its meaning when it becomes work. Here is how the thread stays intact.
Illustrated workflow · fictional example data · not a screenshot of an application graph view.
01 / The idea
Start with the reason.
Write the requirement where the team can understand it. Keep the exact words that explain what should happen.
An exact selection. Not just the top of a document.
DOCUMENT Exact source
Order cancellation requirements
Cancellation before dispatch
A customer can cancel an order before dispatch. Once dispatched, the order cannot be cancelled.
02 / The work
Give the idea accountable work.
Connect the requirement to the tasks that implement it. Product can see which work represents the original intent.
People create and link the work. The source stays here.
DOCUMENT Exact source
Order cancellation requirements
Cancellation before dispatch
A customer can cancel an order before dispatch. Once dispatched, the order cannot be cancelled.
TASK A
Add the cancel-order action.
↔ Exact source · Cases A + BTASK B
Reject cancellation after dispatch.
↔ Exact source · Case B03 / The tests
Give the same idea test coverage.
Link Test Cases directly to the requirement, and to the tasks they verify. QA sees the intent, not just the ticket title.
Source ↔ both cases. Task A ↔ cases A + B. Task B ↔ case B.
DOCUMENT Exact source
Order cancellation requirements
Cancellation before dispatch
A customer can cancel an order before dispatch. Once dispatched, the order cannot be cancelled.
TASK A
Add the cancel-order action.
↔ Exact source · Cases A + BTASK B
Reject cancellation after dispatch.
↔ Exact source · Case BDirect source ↔ Test Cases · independent of task links
TEST CASE A Not yet run
An undispatched order can be cancelled.
Expected: The cancellation succeeds and the order is marked Cancelled.
↔ Exact source · Task ATEST CASE B Not yet run
A dispatched order cannot be cancelled.
Expected: Cancellation is rejected and the order remains Dispatched.
↔ Exact source · Tasks A + B04 / The return
The why is one link away.
From the work, return to the exact requirement. Ask the question where the answer belongs.
Follow the source link back from Task B. Keep the discussion on the task.
DOCUMENT Exact source
Order cancellation requirements
Cancellation before dispatch
A customer can cancel an order before dispatch. Once dispatched, the order cannot be cancelled.
TASK A
Add the cancel-order action.
↔ Exact source · Cases A + BTASK B
Reject cancellation after dispatch.
↔ Exact source · Case BDirect source ↔ Test Cases · independent of task links
TEST CASE A Not yet run
An undispatched order can be cancelled.
Expected: The cancellation succeeds and the order is marked Cancelled.
↔ Exact source · Task ATEST CASE B Not yet run
A dispatched order cannot be cancelled.
Expected: Cancellation is rejected and the order remains Dispatched.
↔ Exact source · Tasks A + B↖ Task B → the exact highlighted words above
DISCUSSION ON TASK B Fictional comments
DeveloperWhat should the customer see if dispatch has already started?
Product ownerExplain that the order has been dispatched. Keep the order unchanged.
QAI'll cover that response in the rejection case.
05 / The evidence
Done is a status. Tested is evidence.
Run the linked tests. See the recorded result and the Test Case revision that was executed. Keep a failure connected to the work needed to fix it.
A tester records the results and creates the linked defect. Task status stays a human decision.
DOCUMENT Exact source
Order cancellation requirements
Cancellation before dispatch
A customer can cancel an order before dispatch. Once dispatched, the order cannot be cancelled.
TASK A
Add the cancel-order action.
↔ Exact source · Cases A + BTASK B
Reject cancellation after dispatch.
↔ Exact source · Case BDirect source ↔ Test Cases · independent of task links
TEST CASE A Results below
An undispatched order can be cancelled.
Expected: The cancellation succeeds and the order is marked Cancelled.
↔ Exact source · Task ATEST CASE B Results below
A dispatched order cannot be cancelled.
Expected: Cancellation is rejected and the order remains Dispatched.
↔ Exact source · Tasks A + BTask B workflow: Done Team's decisionQA evidence: × Failed
RUN 01 Initial run
Cancellation checks — initial run.
Case A · executed revision 1✓ Passed
Case B · executed revision 1× Failed
The dispatched order was still cancelled.
↳ A tester creates the linked defectPrevent cancellation after dispatch.
06 / The shared picture
One idea. A shared picture of what happened.
Product can follow implementation and coverage. Developers can recover the intent. QA can point to the result. The team stays connected to the same source.
Later, after the team's fix, QA records Run 02. Run 01 is kept, not rewritten.
DOCUMENT Exact source
Order cancellation requirements
Cancellation before dispatch
A customer can cancel an order before dispatch. Once dispatched, the order cannot be cancelled.
TASK A
Add the cancel-order action.
↔ Exact source · Cases A + BTASK B
Reject cancellation after dispatch.
↔ Exact source · Case BDirect source ↔ Test Cases · independent of task links
TEST CASE A Results below
An undispatched order can be cancelled.
Expected: The cancellation succeeds and the order is marked Cancelled.
↔ Exact source · Task ATEST CASE B Results below
A dispatched order cannot be cancelled.
Expected: Cancellation is rejected and the order remains Dispatched.
↔ Exact source · Tasks A + BTask B workflow: Done Team's decisionQA evidence: ✓ Passed
RUN 02 After the fix
Cancellation checks — after the fix.
Case A · executed revision 1✓ Passed
Case B · executed revision 1✓ Passed
Run 01 remains in history: Case A passed; Case B failed. Both executed revision 1.
Earlier Run 01 · retained failure evidence
RUN 01 Initial run
Cancellation checks — initial run.
Case A · executed revision 1✓ Passed
Case B · executed revision 1× Failed
The dispatched order was still cancelled.
↳ A tester creates the linked defectPrevent cancellation after dispatch.
02 / Inside Yetea
The connections are real.
See them in Yetea.
Actual product captures. A separate fictional example: a single-use password-reset requirement in Sample Release.
Connected task
Evidence beside the decision.
Linked Test Cases give this task a QA signal. The team, not the test result, controls its workflow status.
Recorded result
A record you can return to.
The run retains its result and executed Test Case revision. Editing a case later can make current task evidence stale without erasing this record.
Explore test management →
03 / One shared reference
Same idea.
Three ways to follow it.
See where your idea went.
Follow a requirement into its linked tasks and Test Cases. See what represents the idea and where connected evidence is still missing.
Recover the reason behind the task.
Return to the source requirement, inspect linked tests, and clarify the work in context.
Test the intent, not a second-hand brief.
Read the requirement, inspect linked implementation work, and retain Test Run results beside the connected work.
The rest of delivery belongs here, too.
Boards and configurable workflows. Cycles, milestones and releases. Document history and contextual discussion. Test Suites, runs and results. Reporting and approvals.
Reviewed AI assistance supports authoring when configured. Your team stays in control.
Explore the full productA few things worth knowing.
Can a task link to the exact part of a document?
Yes. Link a document block or selected phrase to a task. Navigate from the document to the work, and from the task back to the exact source.
Are Test Cases connected directly to requirements?
Yes. Test Cases link directly to document sources. They can also link to multiple tasks; QA does not have to reach the requirement through a task.
Does a passing test automatically complete a task?
No. Verification provides evidence. Workflow completion and release decisions remain with your team.
What happens when a Test Case changes after execution?
The executed revision is retained. Editing the Test Case can make linked task evidence stale. This is not automatic impact analysis for every document edit.
Can I bring existing work?
Supported task CSV and compatible QA CSV/XML imports can help you bring an existing library. These are not a one-click migration of an entire tool's history.
Early access is currently free. See pricing and current access
Ship confidently. Breathe easy.
Keep the context.
Lose the guesswork.
Bring product, engineering, and QA around the same requirement, and the work and evidence connected to it.