Triage classification
Some failure symptoms overlap between categories. For example, a timeout waiting for an element can be a test issue (flaky wait) or a product bug (the UI never rendered the expected element). Bugzy uses contextual signals — did the preceding action succeed? Is the element present but misplaced? — to resolve ambiguity and classify based on root cause, not on whether the test can be patched.
Classification uses the project’s knowledge base and previous triage history. Accuracy improves over time.
Auto-fix behavior
When the test-engineer subagent fixes a test issue:1
Analyze error
Analyzes the error message and stack trace.
2
Identify root cause
Identifies the root cause — selector change, timing issue, or assertion drift.
3
Apply fix
Modifies the test file with the fix.
4
Validate
Re-runs the test to validate the fix works.
5
Commit
If the fix works, commits it to the repo.
6
Retry if needed
If the fix fails, retries with a different approach (up to 3 total attempts).
Bug filing
For product bugs, Bugzy creates issues in your connected tracker (Jira, Azure DevOps, Asana, Linear). Each issue includes:- Failure description and steps to reproduce
- Screenshots from the failure point
- Browser and environment details
- Link to test file and execution logs
Disputed findings
When a team member disagrees with Bugzy’s classification:1
Reply to Bugzy
Reply to the finding message in Slack or Teams.
2
Process reply
The
handle-message task processes the reply.3
Evaluate dispute
Bugzy evaluates the dispute against test evidence.
4
Update finding
If the dispute is valid, the finding is updated and the knowledge base is adjusted.
5
Confirm resolution
Bugzy confirms the resolution in the thread.
disputed-findings.md and directly adjust future triage behavior.
How accuracy improves
After several execution cycles, Bugzy typically reaches a steady state where most test issues are auto-fixed, product bugs are accurately classified, and notifications contain only actionable information.
