Defects

Overview

TestKase includes a fully integrated defect tracking system so your team can log, triage, assign, and resolve bugs discovered during test execution -- all without leaving the platform. Every defect is a first-class entity that can be linked to test cases, requirements, and test cycles, giving you end-to-end traceability from a business requirement all the way down to the specific bug that blocks it.

Unlike external bug trackers that require context-switching and manual syncing, TestKase's native defect management lives alongside your test cases and execution results. When a tester marks a test as failed, they can create or link a defect in the same workflow. This tight integration means fewer gaps in your testing data and a clearer picture of product quality at any point in time.

Create a Defect

There are two primary ways to create a defect in TestKase: from the dedicated Defects tab (standalone creation), or directly during test execution when a test case fails. Both methods give you the same form and fields -- the difference is context and whether the defect is automatically linked to a test execution.

From the Defects Tab (Standalone)

Use standalone creation when you discover a defect outside of a formal test cycle, such as during exploratory testing, a customer report, or a code review.

1. Navigate to the Defects tab in your project from the left sidebar.
2. Click the Create Defect button in the top-right corner of the defects list view. A creation form will open.
3. Enter a Title (required). The title should be a concise summary that clearly identifies the issue. For example: "Login page returns 500 error when password contains special characters" or "Cart total does not update after removing an item".
4. Fill in the Description field with a detailed account of the defect. Include reproduction steps, actual behavior, and expected behavior. Rich text formatting is supported, so you can use bullet lists, bold text, and inline code to make the description easy to scan.
5. Set the Priority level. This determines how urgently the defect should be addressed. See the Defect Fields section below for a detailed breakdown of each priority level. The default priority is Major.
6. The Status is automatically set to Open for new defects. You do not need to change this during creation.
7. Optionally assign the defect to a team member using the Assignee field. The assignee is the person responsible for investigating and resolving the defect.
8. Add any Attachments (screenshots, log files, HAR captures) that help illustrate the issue. See the Attachments section for supported file types.
9. Click Save. The defect is created immediately and appears in the defects list. You will be taken to the defect detail view where you can link test cases, link requirements, and manage the defect through its lifecycle.

During Test Execution

When a tester marks a test case as Fail during a test cycle execution, they can create a defect directly from the execution view. This is the most common workflow because it links the defect to the specific test execution automatically. See the Defects from Execution section for a detailed walkthrough.

Defect Fields

Each defect in TestKase has a set of core fields that capture the essential information needed to triage, assign, and resolve the issue. Understanding these fields helps your team write consistent, actionable defect reports.

Priority Levels Explained

Choosing the correct priority is critical for effective triage. The priority level communicates the urgency and business impact of the defect to your team. Use the following guidelines when assigning priority:

• Blocker -- The defect completely prevents testing or use of a critical feature. No workaround exists. This severity typically halts a release or sprint. Examples: application crashes on launch, login is completely broken, data loss occurs during normal operations, a security vulnerability exposes user data.
• Critical -- A major feature is severely impaired but the application is still partially usable. A workaround may exist but is not acceptable for production. Examples: payment processing fails for a specific card type, search returns incorrect results, user permissions are not enforced correctly, data corruption under specific conditions.
• Major -- An important feature does not work as expected, but the overall application remains functional. There is usually a reasonable workaround. This is the default priority for new defects. Examples: a filter option does not apply correctly, export generates a file with missing columns, form validation allows invalid input, pagination skips a page.
• Minor -- A small issue that does not significantly impact functionality. The feature works but has cosmetic or minor behavioral issues. Examples: a tooltip displays the wrong text, date format is inconsistent between pages, a button label has a typo, minor alignment issues in the UI.
• Trivial -- A negligible issue with no functional impact. Typically cosmetic or related to minor polish. Examples: extra whitespace in a footer, a subtle color mismatch between design and implementation, a log message with a minor grammatical error, placeholder text not updated.

Priority Decision Guide

When deciding which priority to assign, ask yourself the following questions in order:

1. Can users still use the application? If not (crash, total feature failure), choose Blocker.
2. Is a major business function broken? If yes, but the app is partially usable, choose Critical.
3. Does the defect affect core functionality with a workaround? If yes, choose Major.
4. Is it a minor behavioral or UI issue? If yes, choose Minor.
5. Is it purely cosmetic with no impact on usability? If yes, choose Trivial.

Status Values Explained

Defect statuses track where a defect is in its resolution lifecycle. See the Status Workflow section for transition rules and detailed guidance on when to move a defect between statuses.

• Open -- The defect has been reported and is awaiting triage or investigation. This is the initial status for every new defect. An Open defect has not yet been picked up by a developer or assigned to a sprint.
• In-Progress -- The defect is actively being investigated or a fix is underway. The assignee has acknowledged the defect and is working toward a resolution. This status indicates that work is in progress and the defect is not blocked.
• Closed -- The fix for the defect has been implemented and deployed (or merged). The developer believes the issue is resolved. However, the fix has not yet been verified by a tester through re-testing.
• Achieved -- The fix has been verified through re-testing and confirmed to work correctly. This is the terminal state for a successfully resolved defect. Achieved means the defect is fully resolved and validated.

Next Steps

• Learn about the Status Workflow and how defects move through their lifecycle
• Understand Traceability by linking defects to test cases and requirements
• Explore Defect Management for attachments, search, filtering, and reports
• Push defects to Jira, GitHub, or GitLab with bidirectional sync
• Review Best Practices & FAQ for effective defect tracking guidelines