Status Workflow
Understand the defect lifecycle from discovery through resolution and verification.
Status Workflow
TestKase provides a set of defect statuses that describe a bug's journey from discovery through
resolution and verification. This is a recommended convention, not an enforced state machine —
the system validates only that a status is one of the allowed values (open, assigned,
in testing, deployed, closed, achieve). It does not enforce a fixed order, so you can
move a defect between any statuses your process requires.
Recommended Status Flow
open --> assigned --> in testing --> deployed --> closed --> achieve
Suggested Usage
| Status change | Who | When to Use |
|---|---|---|
| open -> assigned | Triage lead | The defect has been triaged and assigned to a team member to investigate and fix. |
| assigned -> in testing | Developer / Assignee | A fix has been made and is being verified against the reported scenario. |
| in testing -> deployed | Developer / Assignee | The verified fix has been deployed (or merged) to the target environment. |
| deployed -> closed | Tester / QA | The fix is confirmed in the deployed environment and no further work is planned. |
| closed -> achieve | Tester / QA | The fix has been fully verified and confirmed to work correctly — the terminal state for a resolved defect. |
| any -> open (Reopen) | Anyone | Re-testing revealed the fix is incomplete or reintroduced the issue. Move back to open with a note explaining what still fails. |
Because transitions are not enforced, agree on a status convention with your team and apply it consistently. A TestKase defect has no comment thread, so when you change a status add the reason to the Summary — a dated one-liner like "14 Mar: fix verified in staging, confirmed working" gives the team immediate context and is the only place that history is kept.
Example Workflow
Here is a typical defect lifecycle from discovery to resolution:
- A tester executes the test case "Verify checkout with discount code" and it fails. They create a defect: "[Checkout] Discount code applies twice when page is refreshed" with priority Major and status open.
- During the daily stand-up, the team triages the defect and sets it to assigned, giving it to a developer.
- The developer identifies the root cause (discount is applied on each page render instead of once), implements the fix, and moves the defect to in testing, then deployed once merged.
- A tester re-executes the original test case with the fix deployed. The discount code now applies correctly. The tester moves the defect to closed and finally achieve.
Reopening Defects
If re-testing reveals that a fix is incomplete or the original issue reoccurs, move the defect back to open. When reopening a defect:
- Add a note explaining what still fails and under what conditions.
- Attach new screenshots or logs that demonstrate the remaining issue.
- Update the description if the problem manifests differently than originally reported.
- Consider whether the priority should change -- a defect that was initially Minor but persists across multiple fix attempts may warrant escalation.
Because the system does not enforce transitions, it is up to your team to ensure a fix is verified before a defect reaches achieve. Have a tester re-run the associated test case(s) before marking a defect as resolved.
Linking a defect to a failed test
Defects are created on the Defects tab and linked at the test-case level. There is no create-a-defect or link-a-defect control inside a running execution: while executing, the test case drawer shows a read-only Defects ID list of the defects already linked to that test case.
Step-by-Step
- Open a test cycle and execute test cases. When you hit a failure, set the execution result to Fail and note which test case it is.
- Go to the Defects tab and click New Defect -- or open the existing defect if this bug has already been logged.
- Open the test case and expand its Traceability section.
- Click the + button beside Defects ID and select the defect. The same link can be made from the other side, in the defect's Traceability section under Test Cases.
Because the link lives on the test case rather than on an execution run, one defect can cover many failing test cases, and the link is unaffected if the cycle is later deleted.
Requirements are not linked to a defect directly -- TestKase derives that relationship from a test case linked to both (see Traceability).
Do not create duplicate defects for the same root cause. If several test cases fail because of the same underlying issue, log the defect once and link that one defect to each affected test case. This keeps your defect count accurate and avoids confusion during triage.
Best Practices for Execution-Based Defects
- Report immediately: Create the defect as soon as you encounter the failure while the context is fresh. Delayed reporting leads to missing details and vague reproduction steps.
- Search before creating: Before creating a new defect, search the existing defect list to check whether the same issue has already been logged by another tester. Linking one defect to several test cases is always better than logging it twice.
- Add execution context: Include the specific test data, environment, and browser or device you were using when the failure occurred. This context is invaluable for reproduction.