How to Set Up Requirements Traceability in BesTest

Requirements traceability answers a simple question: can you prove that every requirement has been tested, and that every test maps back to a business need?

Without traceability, teams run into the same problems repeatedly:

• •A feature ships untested because nobody realized the requirement existed
• •A test fails but nobody knows which business requirement is affected
• •A requirement changes mid-sprint and the team has no way to identify which test cases need updating
• •An audit asks for evidence that a feature was validated, and the team scrambles to reconstruct the paper trail

Traceability eliminates this guesswork. In BesTest, every requirement can be linked to the test cases that validate it, and every test case can be traced back to the requirements it covers. This bidirectional linking gives you a living map of your project's quality status.

For regulated industries (finance, healthcare, automotive), traceability is often a compliance requirement. But even for teams without regulatory obligations, it reduces risk and speeds up release decisions. When you can see at a glance that 95% of requirements are covered and passing, you have real data to support a go/no-go call.

Requirements in BesTest are standalone entities, stored separately from Jira issues. This keeps your Jira backlog clean while giving you a dedicated space for requirement management.

• •Open your Jira project
• •Click "BesTest" in the project menu bar at the top
• •Select the "Requirements" section

• •Click "Create Requirement"
• •Fill in the fields:

• •Click "Save"

After saving, open the requirement and go to the "Links" tab. Here you can link the requirement to one or more Jira issues (stories, epics, tasks). This creates a bridge between your project management workflow and your test management workflow.

To add a link:

• •Click "Add Link" in the Links tab
• •Search for the Jira issue by key or title
• •Select and confirm

Structuring Requirements Effectively

Write requirements at a level of granularity that maps well to test cases. A requirement like "The application works correctly" is too broad to test meaningfully. Break it down:

• •Too broad: User authentication works
• •Right level: User can log in with email and password
• •Right level: User receives an error message for incorrect credentials
• •Right level: Account locks after 5 consecutive failed login attempts

Each of these can have dedicated test cases, and each can be independently tracked for coverage.

Once you have requirements and test cases, you need to connect them. BesTest provides two paths for creating these links, and the resulting connection is the same regardless of which direction you start from.

Method 1: From the Requirement's Coverage Section

Every requirement has a dedicated Coverage section. This is the primary place to manage which test cases validate a given requirement.

• •Open a requirement
• •Scroll to the "Coverage" section
• •Click "Link Test Case"
• •Search by test case name or ID
• •Select the test case and confirm

The Coverage section immediately updates to show the linked test case and the requirement's coverage status.

Method 2: From the Test Case's Links Tab

Every entity in BesTest (requirements, test cases, test cycles) has a Links tab for managing relationships.

• •Open a test case
• •Go to the "Links" tab
• •Click "Link Requirement"
• •Search and select the requirement
• •Confirm the link

Many-to-Many Relationships

BesTest supports many-to-many linking:

• •One requirement can be linked to multiple test cases (different scenarios, edge cases, negative tests)
• •One test case can be linked to multiple requirements (a login test might validate both "user can authenticate" and "session is created on login")

There is no limit on the number of links. Use as many as accurately represent the relationships in your system.

Verifying Links

After linking, check both sides:

• •On the requirement, the Coverage section shows all linked test cases and the current coverage status
• •On the test case, the Links tab shows all linked requirements

If a link is incorrect, you can remove it from either side without affecting the underlying entities.

BesTest does not treat coverage as a simple binary check. A requirement is not "covered" just because it has one linked test case. Instead, BesTest uses a significance-based coverage model that accounts for how important and complex the requirement is.

How Significance Works

Each requirement's significance is calculated from two factors:

• •Dev complexity: How technically complex is the feature? A simple UI label change has low complexity. A payment processing flow has high complexity.
• •Business impact: How critical is this requirement to the business? A cosmetic preference is low impact. A security authentication flow is high impact.

The combination of these two factors (dev complexity x business impact) produces a significance score. Requirements with higher significance need more test coverage to be considered "Covered."

What "Covered" Actually Means

A requirement's coverage status in BesTest reflects whether it has enough test coverage relative to its significance:

• •Covered: The number and depth of linked test cases meets or exceeds the significance threshold
• •Not Covered: The requirement needs more test cases to reach adequate coverage for its significance level

This means a high-significance requirement (complex + high business impact) might need several test cases covering happy paths, edge cases, and error scenarios before BesTest marks it as Covered. A low-significance requirement might reach Covered status with a single test case.

Manual Override

You can also manually set a requirement's coverage status to "Covered." When you do this, the requirement is always treated as covered in stats and reports, regardless of how many test cases are linked. This is useful for requirements that are validated through other means (automated tests outside BesTest, third-party certifications, etc.).

Why This Model Matters

A flat "has at least one test case" model gives a false sense of security. A payment processing requirement with one basic happy-path test is technically "linked" but far from adequately tested. The significance model pushes teams to allocate testing effort proportionally to risk, which is how experienced QA teams already think about coverage.

Traceability data is only useful if you can see it clearly. BesTest's coverage reporting surfaces the information you need for release readiness decisions.

Requirements Coverage View

The Requirements section shows coverage status for every requirement in your project. You can quickly filter to see:

• •All requirements that are Not Covered (gaps that need test cases)
• •Requirements where linked test cases have failed in the latest cycle (at-risk areas)
• •Requirements with no linked test cases at all (blind spots)

Using Coverage Data in Sprint Reviews

At the end of a sprint, pull up the requirements coverage view and walk through it with the team:

• •New requirements added this sprint: Are they all linked to test cases? Are they Covered?
• •Requirements with failed tests: What failed, and is there a fix in progress?
• •Coverage percentage overall: Is it trending up or down compared to the last sprint?

This gives the team and stakeholders concrete data instead of opinions about quality.

Release Go/No-Go Decisions

For release decisions, consider these coverage checkpoints:

Dashboard Gadgets for Stakeholders

BesTest's Jira dashboard gadgets let project managers and product owners monitor coverage without opening BesTest directly. Add a coverage gadget to your team's Jira dashboard so that traceability data is visible to everyone, not just the QA team.

Traceability is easy to set up but takes discipline to maintain. Here are practical tips from teams that keep their traceability clean over time.

Link as You Go

Do not batch-link requirements to test cases at the end of a sprint. Instead, make it part of your workflow:

• •When you create a new requirement, immediately consider what test cases it needs
• •When you write a new test case, link it to the relevant requirement before moving on
• •When a requirement changes, review and update its linked test cases

Review Coverage Weekly

Set a recurring 15-minute check: open the requirements list, filter for "Not Covered," and assign owners to close gaps. Small, regular checks prevent coverage debt from piling up.

Use Consistent Naming

Name requirements and test cases so that related items are easy to find:

• •Requirement: "User can reset password via email link"
• •Test case: "Verify password reset email is sent within 30 seconds"
• •Test case: "Verify password reset link expires after 24 hours"

Clear, descriptive names make it obvious which test cases belong to which requirement, even without looking at the links.

Handle Requirement Changes

When a requirement changes:

• •Update the requirement text in BesTest
• •Review all linked test cases — do they still validate the updated requirement?
• •Update or add test cases as needed
• •Re-execute affected test cases in the next cycle

This keeps your traceability accurate through the natural evolution of your project.

Involve the Whole Team

Traceability should not be one person's responsibility. Developers can help by flagging when code changes affect requirements. Product owners can help by keeping requirement descriptions current. QA leads can monitor coverage trends and flag gaps early.

When traceability is a shared practice, it stays accurate. When it's one person's job, it falls behind.