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.
Know what changed. Know what to test again.
Use explicit product and implementation traceability to focus regression effort where new evidence is needed.