Test cases and traceability
Test cases prove acceptance criteria. Their results, reported by CI, coding agents or people, decide whether the criteria are met; Traceability follows every requirement to its criteria, tests, work and code.
For: Tester, Team developer, Project lead
How results drive criteria
- A test case verifies one or more acceptance criteria — of requirements, or acceptance lines of design records such as
FDR-1A2B3C/AC2; only active tests count. - Any failing active test makes its criteria Not met; when all active tests of a criterion have passed, it becomes Met.
- Blocked or not-run tests leave the criterion as it is. People can still verify a criterion by hand.
- A story or task cannot be moved to Done while a test of a criterion it covers is failing.
Regression sets and UAT sessions
Test sets (Test Cases → Test sets) keep what to run and what is left. A regression set belongs to the solution: CorPole fills it with the tests of what changed since a date — changed requirements, work finished since then, changed design records — riskiest first (failed last time, flaky, not run since the change, Authority), each with why. A UAT session belongs to an initiative: its requirement criteria become scenarios the business tries, with the role who tries each; write them in the business's words and without real personal data.
Record each item as passed, failed or blocked. A test item is also recorded as a run of the test, so its criteria follow; a scenario without a test is the business accepting the criterion, so only a person who may verify criteria records it and the criterion takes the result with the session as evidence. Close the set with its outcome; items not run are counted. The initiative page lists its UAT sessions. Agents use get_regression_candidates, propose_test_set, get_test_set and report_test_set_result.
History, flaky tests and quarantine
Every run is kept. The test page shows the last 14 days as a strip of runs and says whether the test is passing, failing, regressed (passed, then started failing), recovered or flaky (passed and failed by turns, at least two flips). The Test Cases list counts flaky tests and filters them.
A person who verifies criteria can quarantine a flaky test until it is fixed, with a reason and an optional review date. It keeps running and its runs are kept, but it is no evidence: its failures do not make criteria Not met or block Done, and while it is quarantined its criteria cannot be Met by their tests — one that was Met by tests goes back to Pending. Release it when it is stable; its latest result counts again. Agents read the history with get_test_history and ask the person to confirm quarantine_test in their client.
Where results come from
| Source | How |
|---|---|
| CI | POST /api/test-results with a service token (Agents → Agent tokens) that has the propose permission. Tests are named by code or automation reference. Report skipped tests too, and send complete: true for the whole suite: a test that passed and is now skipped or missing raises DRF-06. |
| Coding agent | propose_test_case registers the tests it writes; report_test_result reports runs. |
| People | The Passed / Failed / Blocked buttons on the test case page, for manual and UAT tests. |
Code links
Connect the GitHub or GitLab repositories under Solution settings → Repositories and CI. Change requests (pull or merge requests) and commits that mention a story, task, defect or record code in the title, description, branch name or commit message are linked to it. Opening a story's change request moves it to Code review; merging it moves it to Verification. Links can also be added by hand or by agents (link_code).
On GitHub, with the webhook events Pull request reviews and Workflow runs (or Check suites), a review asking for changes is written into the history of the cited work and reaches the people behind it, and so their agent; the CI result of each change request shows next to it in the agent's work context. A CI failure on work in Code review is announced too. A defect that goes to Code review without a test that failed on it gets a warning: fixes start from a test that reproduces the bug.
A change request closed without merging sends its work back from Code review to In progress. The repository kit also sends test results from CI: on GitHub corpole-tests.yml (upload JUnit reports as an artifact named junit), on GitLab the CI include. Results go to CorPole after every run, including skipped and missing tests.
Two traceabilities
Solution → Traceability shows what the solution is today, proven and located: each design record’s criteria, the tests that prove them, the code modules it describes and the requirements it realizes. Initiative → Traceability shows why a change is made and how far it has come: the objective each requirement serves, its criteria, tests and UAT, the work and the code — for the initiative chosen at the top.
Traceability gaps
No test: a criterion nothing proves. No work: a criterion no story or task covers. No code: covering work without a change request or commit. Failing: a test of the criterion fails.