TestKase Docs
Core TestingRequirements

Best Practices & FAQ

Guidelines for effective requirements management and answers to common questions.

Best Practices

Follow these best practices to get the most out of requirements management in TestKase and maintain a high-quality, traceable test library.

1. Write clear, testable requirements

Every requirement should be specific enough that a tester can determine whether it passes or fails. Avoid vague language like "the system should be fast" or "the UI should be user-friendly." Instead, write "search results load within 3 seconds for datasets up to 10,000 records" or "all form fields display inline validation errors within 500ms."

2. Use priority levels consistently

Establish team guidelines for what qualifies as P0, P1, P2, and P3. Apply these guidelines consistently so that coverage reports and priority-based filters produce meaningful results. A common mistake is marking too many requirements as P0, which dilutes the meaning of the critical priority level.

3. Link test cases as you write them

Do not wait until the end of a sprint or release to link test cases to requirements. Link them as each test case is created. This keeps coverage metrics accurate in real time and helps you identify gaps early, when there is still time to write additional tests.

4. Organize folders by feature area

Structure your requirement folders to mirror your product's feature areas or business domains. This makes it intuitive to find related requirements and enables meaningful folder-level coverage reports. Keep folder names consistent with your test case folder structure for easy cross-referencing.

5. Review and deprecate stale requirements

As your product evolves, some requirements will become obsolete. Regularly review your requirements list and mark outdated ones as Deprecated. This keeps your Active requirement set focused and ensures coverage percentages reflect reality. Schedule a quarterly requirements review as part of your team's hygiene process.

6. Aim for 100% P0 and P1 coverage

Critical and high-priority requirements should always have linked test cases. Use the Uncovered Requirements report filtered by P0 and P1 to identify gaps. If time is limited, focus test authoring efforts on uncovered P0 requirements first, then P1.

7. Attach supporting documentation

Attach wireframes, design mockups, specification documents, and acceptance criteria files directly to the requirement. This gives testers all the context they need without searching through external tools. Keep attachments current and remove outdated versions.

8. Use traceability for release sign-off

Before each release, generate the Traceability Matrix report and review it with stakeholders. Confirm that all critical requirements are covered, all linked test cases have been executed in the current cycle, and all linked defects are resolved. This provides confidence and a documented audit trail for the release decision.

FAQ

Can I sync requirements from Jira?

Yes. With the Jira Integration, Jira issues are automatically imported as requirements in TestKase and kept in sync in real time. Changes in Jira (title, description, status, priority) are reflected in TestKase automatically. Linked test cases appear as comments on the Jira issue, and defect updates sync bidirectionally. You can also sync from GitHub or GitLab.

What does 'uncovered' mean in the coverage report?

An uncovered requirement is an Active requirement that has zero linked test cases. This means there is no test in your project that explicitly verifies this requirement. Uncovered requirements represent gaps in your test strategy and should be addressed by either linking existing test cases that implicitly cover the requirement or writing new test cases specifically for it. Use the Uncovered Requirements report to find these gaps and prioritize starting with P0 and P1 requirements.

Can I import requirements from a CSV file?

Currently, requirements are created individually through the UI or imported from Jira using the Jira sync feature. CSV import for requirements is on the product roadmap and will be available in a future release. In the meantime, if you have a large number of requirements to import, consider using the Jira sync workflow: create them in Jira (which supports CSV import) and then sync them into TestKase.

What is the difference between Draft, Active, and Deprecated status?

A Draft requirement is still being written or reviewed and is not yet finalized -- it should not be used as a basis for writing test cases. An Active requirement has been approved and is ready for testing -- only Active requirements are included in coverage calculations. A Deprecated requirement is no longer relevant because the feature was removed or replaced -- it is excluded from coverage calculations but its historical data is preserved for audit purposes.

Can a requirement be linked to test cases in different projects?

No. Requirements and test case links are scoped to a single project. If you need to trace a requirement across multiple projects, consider creating the requirement in each project where it applies, or use a shared project that consolidates cross-cutting requirements.

How does deprecating a requirement affect linked test cases and defects?

When a requirement is set to Deprecated, its linked test cases and defects remain intact -- the links are not removed. However, the deprecated requirement is excluded from coverage calculations and will not appear in active coverage reports. Historical traceability data is preserved for audit purposes. The linked test cases themselves are not deprecated; you should review them separately and decide whether they should also be deprecated or linked to other requirements.

Can I link the same test case to multiple requirements?

Yes. A single test case can be linked to multiple requirements, and a single requirement can be linked to multiple test cases. This many-to-many relationship is common when a single test verifies behavior that spans multiple requirements, or when a complex requirement needs multiple tests to fully verify it.

How do I track requirements that are at risk due to open defects?

Open the requirement detail view and check the Linked Defects section. If there are open defects linked to the requirement, the requirement is at risk. For a project-wide view, use the Traceability reports which show all requirements alongside their linked test cases and defects. Filter by defect status to quickly identify requirements with unresolved issues.

What happens to synced requirements if I disconnect the Jira integration?

If you disconnect the Jira integration, all previously synced requirements remain in TestKase as regular requirements. They are no longer read-only and can be edited directly. The Jira badge is removed, and the requirements become fully managed within TestKase. No data is lost during disconnection. See the Jira Integration guide for details.

Is there a limit to how many requirements I can create in a project?

There is no hard limit on the number of requirements per project. TestKase is designed to handle thousands of requirements with full search, filtering, and folder organization. For very large requirement sets, we recommend using a consistent folder structure and priority assignments to keep the list manageable and navigable.

On this page