A defect that knows which test found it
Record defects here or file them into the tracker your developers already use — with the case, the build and the environment travelling with the ticket instead of being written from memory.
Nine destinations · built-in tracker included · anyone can file
Total shows $0.00 after a promo code
- Open
- In progress
- Fixed
- 4Verified
- 5Closed
Written from memory, a bug report is missing the fact that reproduces it
By the time a tester switches to the tracker and types a title, the build, the environment and the device are half-remembered. The developer gets a paragraph, not a defect — and “cannot reproduce” does the rest.
Raised from the failure, not a blank form
Filed from the failed test — the case, cycle, build and environment ride along.
Raised from a device session — the device, platform, browser and a screenshot attach themselves.
Linked both ways — the defect knows its test, and the test knows its defects.
Anyone in the workspace can file — no paid seat to report a bug.
Send it to the tracker your team already runs
Nine destinations, each a real integration — plus a built-in tracker with attachments up to 50 MB if you run nothing else.
Jira
creates PROJ-412
or any tracker your team runs
See it through to verified
A defect linked to a case makes the fix provable: re-run the case that failed, and “resolved” becomes “verified”. When the same area breaks release after release, the link makes recurrence a fact rather than a hunch.
Frequently asked questions
Jira, GitHub, GitLab, Asana, Trello, ClickUp, Monday, Azure Boards, and TestKase's own built-in tracker. Each has a real implementation — if it is listed, an issue raised from a test result appears in it.
No. The built-in tracker means a defect found during testing lands somewhere structured, with attachments, rather than in a chat message. Plenty of teams run nothing else, and a testing tool that only speaks Jira quietly tells them their workflow does not count.
When it is raised from a failed execution: the test case, the cycle, the build, the environment and the actual result. When it is raised from a device session: the device, platform and browser version, with the screenshot attached as a file. The point is that the three facts most often missing from a bug report are the three the tool already knows.
Read the guide: Writing better bug reports →No. An issue filed into an external tracker is owned by that tracker, and its status is not mirrored back here. That is a deliberate boundary rather than an omission — two systems both believing they own a status is how they end up disagreeing.
Anyone in the workspace. That sounds like a detail and decides quite a lot: in most testing tools filing requires a paid seat, so the designer, support engineer or product owner who finds something ends up sending a screenshot to somebody who has one. The report that arrives second-hand is always the one missing the device, the build and the steps.
Yes — the link from a defect to its test case is what shows recurrence. A defect connected to a case, and a case with a history of results across cycles, makes recurrence a visible fact rather than something one long-serving person happens to remember.
No, and treating them as the same thing produces a tracker nobody trusts. A failure can be a broken test, a stale expected result, bad test data or an environment problem — none of which is a defect in the product. The value of filing from the failure is that the context is there to tell them apart, not that every red result deserves a ticket.
No. Defects here are a record and a link, not a workflow engine — there are no SLA timers, auto-assignment rules or escalation. The verification step is yours: because the defect is linked to the case that failed, you know exactly which case to re-run to prove the fix.
Not yet. You can capture and attach, but drawing arrows or boxes happens in whatever tool you already use. BrowserStack ships annotation and it is a genuine gap on our side rather than a decision.
Stop losing the context between finding and filing
Raise the defect from the failure, and the case, build and environment come with it.