TestKase
TestKase
|Docs
Test ManagementIntegrationsBuilt-in

Built-in

Manage requirements and defects natively in TestKase without external integrations.

Overview

TestKase includes full built-in requirement and defect management for teams that do not use an external issue tracker like Jira, GitHub, or GitLab -- or for teams that prefer to manage everything in one place. With the built-in option, you can create requirements, track defects, organize them into folders, and link them to test cases and test cycles without configuring any external integration. Everything lives inside TestKase, giving you a self-contained test management workflow from requirements through execution to defect resolution.

No setup required

Start managing requirements and defects immediately with zero configuration

Full requirement management

Create, prioritize, and track requirements with statuses, priorities, and attachments

Defect tracking

Create defects from the project Defects tab and track them through resolution

Folder organization

Organize requirements and defects into folder hierarchies for easy navigation

When to Use Built-in

The built-in option is the right choice when:

  • Your team does not use an external issue tracker -- You do not have Jira, GitHub Issues, or GitLab Issues in your workflow, or your team manages work outside of those platforms.
  • You want a self-contained test management workflow -- Requirements, test cases, test cycles, defects, and traceability all live in TestKase with no external dependencies.
  • You need requirements and defects managed alongside test cases in one tool -- Having everything in a single platform simplifies onboarding, reduces context switching, and keeps traceability tight.

When to Use an External Integration Instead

If any of the following apply, consider connecting TestKase to an external platform:

  • Your backlog lives in Jira, GitHub, or GitLab -- If your team already tracks requirements or user stories in an external tool, you can search those issues from TestKase and link them to test cases for traceability, rather than re-entering them.
  • You want linked test cases visible in your issue tracker -- When you link a test case to an external issue, TestKase posts a comment on that issue listing the linked test cases, so developers see coverage without leaving their tool. Coverage comments are posted only by the API Integration -- projects connected through the Jira Plugin or the Chrome Extension do not post comments back to the issue tracker.
  • Your developers work primarily in an external platform -- Linking test cases to existing issues keeps traceability visible where developers already work, and issue status can be refreshed into TestKase on demand.

Built-in Is a Connection You Select

Built-in is not "no integration" -- it is the fourth option on the Requirement Integration and Defect Integration pages, under the heading TestKase Built-in, and you connect it the same way you would connect Jira or GitHub. TestKase records it exactly like an external connection.

Two consequences follow from that:

  • The Built-in card has a Reset action, and resetting it deletes the requirements and folders (or the defects) that belong to it -- see below.
  • Requirements and defects are configured independently. A project can use Built-in requirements while its defects point at an external tracker, or the reverse.

Switching Away From Built-in Deletes Your Data

Switching is destructive -- your built-in data is deleted, not migrated.

A project uses one option at a time. Connecting any other option to a project whose requirement integration is currently Built-in -- the Jira, GitHub or GitLab card under API Integrations, the Jira Plugin, or a Chrome Extension card -- permanently deletes that project's requirements and every requirement folder in it. Doing the same on the Defect Integration page deletes that project's built-in defects. Resetting a Built-in integration deletes the same data.

Because the Jira Plugin and the Chrome Extension cover both types with a single configuration, connecting either of them also deletes the other type's built-in data at the same time.

The deletion happens the moment you press Continue on the product's Data Loss dialog. That dialog appears after you choose the external project and before the new connection is saved, so abandoning the rest of the wizard does not bring anything back -- you are left with no integration and no requirements.

Nothing is copied into Jira, GitHub or GitLab, and nothing can be recovered afterwards. The dialog warns only that "mappings" will be lost -- it does not mention the deletion. Export anything you need before you switch.