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. Record an actual result or comment when changing a defect's status — a brief note like "Fix verified in staging -- confirmed working" gives the team immediate context.
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.
Defects from Execution
The most common way to create a defect in TestKase is directly from a failed test execution. This workflow is designed to minimize context-switching and ensure that defects are automatically linked to the test case where they were discovered. (The link is at the test-case level, not tied to a specific execution run.)
Step-by-Step: Creating a Defect During Execution
- Open a test cycle and begin executing test cases.
- When you encounter a failure, set the test case execution result to Fail.
- After marking the test as failed, click the Link Defect button that appears in the execution view.
- You will be presented with two options:
- Create New Defect -- Opens the defect creation form pre-populated with context from the current test execution. Fill in the title, description, priority, and any additional details, then save.
- Link Existing Defect -- Search for and select a defect that has already been logged. This is useful when the same defect causes multiple test cases to fail.
- Once saved or linked, the defect is automatically associated with the current test case. You can continue executing the remaining test cases in the cycle.
What Gets Auto-Linked
When you create a defect from the execution view, TestKase automatically creates the following link:
- Defect -> Test Case: The defect is linked to the test case that was being executed when the failure occurred.
If you also want to link the defect to a requirement, you can do so manually from the defect detail view after creation (see Link to Requirements).
Do not create duplicate defects for the same root cause. If multiple test cases fail due to the same underlying issue, create the defect once and then use Link Existing Defect for subsequent failures. This keeps your defect count accurate and avoids confusion during triage.
Linking an Existing Defect to Multiple Failures
When a single defect causes multiple test cases to fail within the same cycle (or across cycles), you should link the existing defect rather than creating a new one each time. To do this:
- Mark the test case as Fail.
- Click Link Defect and choose Link Existing Defect.
- Search for the defect by title or browse the list of open defects.
- Select the defect and confirm. The test case is now linked to the existing defect.
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, quickly search the existing defect list to check if the same issue has already been logged by another tester.
- 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.