Know What to Retest
From commit to retest scope. Without guessing.
Reqode is building a traceable workflow that uses explicit product and implementation relationships instead of relying only on file names, tags, or manual regression lists.
1. Commit changes code
Repository sync identifies the source files changed by a commit in the mapped code branch.
2. Files resolve to software units
File ownership and Unit dependencies identify the implementation responsibilities touched by the change.
3. Units resolve to requirements
Unit ↔ Specification relations connect the implementation change to the product behavior it may affect.
4. Requirements resolve to tests
Related Test Cases are marked as needing re-validation so QA receives a focused and explainable retest scope.
Needs Retest is about evidence freshness
The Test Case may still describe the correct behavior, but a code change means its previous execution result is no longer sufficient evidence for the affected implementation.
A new relevant execution refreshes that evidence and gives the team an explicit reason for removing the retest signal.
Outdated is about test design
When the linked Requirement revision changes, a Test Case can become Outdated because its content may need review or redesign.
When implementing code changes, Needs Retest means the test design may remain valid, but the execution evidence needs to be refreshed.
A retest signal should explain itself
The value is not only the flag. Teams need the path that caused it.
Commit evidence
See which commit and changed file initiated the impact path.
Engineering path
Follow the software unit ownership and relevant dependencies behind the affected behavior.
Product path
See the connected Requirement and Test Case that justify why re-validation is needed.
Focused regression for AI-assisted development
As AI coding agents increase the frequency and volume of changes, manual regression selection becomes harder to sustain. Reqode turns its requirement ↔ code ↔ test graph into a practical control: run the tests connected to what actually changed, while keeping the reason visible.
This workflow is currently in development. Final behavior will follow the implemented commit, branch, dependency, and result-lifecycle rules.
Retest signals with an inspectable reason
The planned Needs Retest indicator highlights test cases affected by an implementation change, showing where earlier results need fresh execution evidence.
An Outdated signal has a different meaning: the source requirement changed and the test design needs review. Open the signal to inspect its reason before choosing whether to rerun or update the case.
Screenshot to add
Retest indicators and their reasons
Capture a tight crop of the Test Cases table with a Needs Retest badge and an Outdated indicator. Open the retest reason with its linked change evidence. Keep the case names and badges readable; omit the full application shell.
Explore the workflow
Review test scope and keep test design aligned with changed requirements in FieldDesk.
Interactive presentation to add
Select retests
Find the relevant regression scope after a code change.
- Inspect the changed unit and linked requirements.
- Open affected cases with retest signals.
- Review the reason and select cases for a run.
Execute the selected checks
Once the team has selected the relevant cases, organize a test run. An external QA agent can use QA MCP to read that prepared context and record its execution results.
Know what changed. Know what to test again.
Use explicit product and implementation traceability to focus regression effort where new evidence is needed.
