Linking a Test Case to a Bug Tracker Issue That Survives a Migration

A QA lead runs a regression suite on a Monday morning and a case fails that also failed six months ago. The obvious question is whether this is the same bug come back, or a new one that happens to look similar. Answering that should take ten seconds. In most teams it takes twenty minutes of searching old spreadsheets and asking around, because linking a test case to an issue in a bug tracker rotted the day it was created and nobody noticed.

That link, a test case pointing at the issue it found, is arguably the single most useful relationship in a test system. It gets created constantly and almost nobody treats it as something that needs to last. This post is about making it survive three things. A year passing. A tracker migration. And the person who created the link leaving the company. It also gives Kiwi TCMS credit where it is due, because its approach to this problem, integrating directly with roughly eleven trackers, is one of its clearest strengths.

Here is the scene that makes this concrete. A team ships a checkout flow, and a tester finds a Safari only bug where the payment button does not respond. She files it in Jira, pastes the Jira link into the test case notes, and moves on. Fourteen months later the company migrates from Jira Cloud to Jira Data Center during a Thursday maintenance window. Every pasted link in that test suite, including hers, now points at a page that no longer exists. Nobody notices until a customer reports the same bug again and the team needs to know if it is really new.

What the link is actually for

It is tempting to think of the case to bug link as a navigation shortcut. A way to click from a test result to a ticket instead of searching for one. That undersells it badly. The link actually answers two much harder questions.

The first is whether this exact failure was ever seen before. A tester staring at a failed checkout test on a Tuesday does not want to file a fresh bug if this is the same one from March that is still sitting in the backlog. The second is whether the fix actually got verified.

The three ways teams create the link, and how each one fails

Almost every team creates this link one of three ways, and the failure mode is different for each.

• A pasted URL in a comment or a text field. Someone finds the ticket in Jira, copies the link, and drops it into the test case notes.
• A free text id, like writing "JIRA-4021" into a field with no validation behind it.
• A real integration, where the test tool and the tracker both know about the same issue through an API.

The pasted URL is the most common of the three, and it is also the worst. A free text id at least survives a tracker migration if someone remembers the old numbering scheme. A pasted URL does not survive anything.

The moment a company moves from Jira Cloud to Jira Data Center, or merges two trackers after an acquisition, every pasted link silently points at nothing. Nobody notices on the day of the migration.

They notice eighteen months later, during an audit, when a case marked "verified fix" points at a 404 page. There is no way to prove what actually happened.

What a durable link actually needs to carry

A link that survives a migration, a personnel change, and a few years of normal software chaos needs more than a URL. It needs four pieces of information traveling together.

• The issue id itself, in a form that does not depend on the tracker's current URL scheme.
• The specific execution the failure came from, not just the test case in the abstract.
• The case it belongs to, so a reader can trace backward to the steps that produced the failure.
• A timestamp, so anyone reading the link later knows when the connection was made.

Without the execution reference, a case with three failed runs over a year gets flattened into one ambiguous link. Nobody can tell which run actually raised which bug.

Think back to the Safari checkout bug. Say the tester's link only pointed at the case, not at the specific run from that Tuesday. A reviewer a year later cannot tell whether the bug came from that run. It might instead have come from one of the two other times the same case failed for unrelated reasons. The execution reference is what turns a vague hunch into a documented fact.

The integration landscape, stated fairly

This is where Kiwi TCMS earns real credit. It integrates with roughly eleven bug trackers, including GitHub Issues, GitLab, Jira, Bugzilla, Redmine, and Azure Boards (kiwitcms.org features page, checked 25 August 2026).

For a team that already lives in one of those trackers, that breadth removes the pasted URL problem entirely. The link is created and maintained through an API instead of a person's memory.

If that Jira migration had happened on a team using a real integration instead of pasted URLs, the link would have updated automatically. That is because the integration tracks the issue by its stable id, not by a URL that a server reshuffle can break.

That is a genuine strength and it deserves to be said plainly rather than buried under caveats. A team running GitLab and Kiwi TCMS together gets a link that updates itself when the issue status changes, instead of a link that needs a human to notice and update it. The gap between those two experiences is the entire subject of this post.

The closing loop most teams skip

Here is the step almost everyone forgets. The bug gets fixed, the ticket closes, and the team moves on to the next release. Nobody goes back and reruns the original test case against the fix. The link between the case and the bug just sits there, permanently marked "open," even though the underlying problem is gone.

Going back to the Safari checkout example, imagine the fix ships on a Wednesday and the ticket closes that afternoon. If nobody reruns the case, the test suite still shows that scenario as unverified six months later, even though engineering believes it is fixed. A customer hitting the same bug again would force the team to start the investigation from zero.

A durable process treats the fix as the start of a second step, not the end of the story. When the fix ships, the case gets run again, and the result gets recorded against the same thread that raised the bug in the first place. That is what makes the link answer "did the fix get verified" honestly, instead of leaving that question to a Slack message from six months ago that nobody can find. A QA lead who builds this habit into the team's normal workflow is the one who can actually trust their own regression history a year later.