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 to read the Uncovered Requirements report a feature at a time. Keep folder names consistent with your test case folder structure for easy cross-referencing.
5. Review and archive stale requirements
As your product evolves, some requirements will become obsolete. Regularly review your requirements list and set outdated ones to archive. This keeps your active requirement set focused and easy to navigate. 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 to identify gaps -- it lists every requirement with no linked test case, so scan it for your P0 and P1 items. 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. It shows every requirement with the test cases linked to it, so you can confirm that all critical requirements are covered. Check execution results and open defects separately -- the matrix does not carry either. This provides a documented audit trail for the release decision.
FAQ
▶Can I sync requirements from Jira?
Yes, in one direction. With the Jira Integration, Jira issues are read into TestKase as requirements. Their titles, statuses and priorities are re-read from Jira when you use the refresh control on the requirement -- there is no live push. Linked test cases are written back as comments on the Jira issue; nothing else is written to Jira, and defect changes do not sync in either direction. You can also read requirements from GitHub or GitLab.
▶What does 'uncovered' mean in the coverage report?
An uncovered requirement is a 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. Coverage counts every requirement regardless of status, so 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 do the requirement statuses (open, in progress, closed, archive) mean?
An open requirement has been captured and is being written or reviewed. An in progress requirement is one where work is actively underway. A closed requirement has been delivered. An archive requirement is no longer relevant because the feature was removed or replaced -- its historical data is preserved for audit purposes. Status is optional and does not affect coverage: coverage counts every requirement regardless of status.
▶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 archiving a requirement affect linked test cases and defects?
When a requirement is set to archive, its linked test cases and defects remain intact -- the links are not removed. Archiving is a status change only; coverage still counts the requirement, and its historical traceability data is preserved for audit purposes. The linked test cases themselves are unchanged; you should review them separately and decide whether they should be archived 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, expand Traceability and read the Defects field. It lists every defect linked to a test case that is itself linked to this requirement, with the defect's current status; if any of them are open, the requirement is at risk. The field is read-only and derived, so a requirement with no linked test cases will never show a defect. The Traceability Matrix report gives a project-wide view of requirements and their linked test cases, but it does not include defects.
▶What happens if I reset the requirement integration?
It depends on the platform.
If the platform was Jira, GitHub or GitLab, the issues were never stored in TestKase -- they live in the tracker. Resetting the integration stops TestKase resolving them, so they can no longer be viewed or refreshed here. Reconfigure the integration to restore them.
If the platform was TestKase (built-in requirements), resetting the requirement integration permanently deletes every requirement and every requirement folder in the project. Export your requirements before you reset.
▶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.