Topic 8 — Bug tracking and test management tools

Goal: Know the tools QA teams use to organize testing and track bugs.

Lesson 8.1 — Where bugs actually live

In her pharmacy days, Nadia had a rule: if it isn't written down and signed, it didn't happen. So when she found her first real bug at FreshCart — the promo code WELCOME10 taking 100% off instead of 10% — her instinct was to walk over to Priya's desk and tell her.

Marcus, her mentor, gently stopped her. "Tell her in person and it lives in her memory for ten minutes," he said. "Put it in the tracker and it lives forever, with a status everyone can see."

That's the first thing to understand about real QA work. Bugs and test cases don't live on sticky notes, in your head, or in a chat message that scrolls away by lunch. They live in software built to track them — so nothing gets lost, and so anyone on the team can glance at a screen and know exactly what's broken, who's holding it, and whether it's fixed yet.

A bug you found but didn't log is a bug you didn't find.

The job goes past spotting problems: you make them visible and trackable until somebody fixes them. The tools in this topic are how teams do that at scale.

Lesson 8.2 — The bug life cycle

When Nadia logged that promo-code bug, it didn't just sit there marked "broken." Over the next two days it moved through a series of statuses, like a prescription moving from ordered to filled to picked up. That journey has a name: the bug life cycle.

Here's the path almost every bug follows:

1. New / Open — Nadia reports it. The bug exists in the system now.
2. Assigned — Tom, the PM, or a lead hands it to a developer. Priya gets this one, since she owns checkout.
3. In Progress / Fixed — Priya works on it and marks it Fixed when her code change is done.
4. Re-test / Verified — back to Nadia. She re-runs her exact steps to confirm the fix really works.
5. Closed — Nadia confirms the fix holds, and the bug is put to rest.

There's one important branch. If Nadia's re-test shows the bug is still broken — the discount is now 90% off instead of 100%, still wrong — she doesn't close it. She marks it Reopened, and it loops back to Priya. Catching that on re-test, instead of rubber-stamping "Fixed," is the whole reason QA verifies fixes at all.

Notice who owns which step. QA opens the bug and QA verifies the fix. The developer owns the middle. The status is the handoff baton, and at any moment it tells you whose court the ball is in.

Lesson 8.3 — When a bug doesn't get "fixed"

Not every bug ends at Closed-because-fixed. Nadia learned this the week she filed eleven bugs and three came back with resolutions she didn't expect. Marcus walked her through the three you'll see most:

• Won't Fix. The bug is real, but the team has decided to live with it — usually because it's low-priority and the cost of fixing outweighs the annoyance. Nadia reported that the order-confirmation screen showed "1 items" instead of "1 item." Real bug. Tom marked it Won't Fix for now: ugly, harmless, not worth a developer's afternoon this sprint. (It can always be reopened later.)
• Duplicate. Someone already reported it. Nadia's "map doesn't load on slow wifi" turned out to match a ticket Dev had filed two days earlier, so hers was closed as a Duplicate and linked to the original. No work lost — just merged.
• Cannot Reproduce. The developer followed the report and the bug never appeared. This one stung a little, because it usually points back at the report. If Priya can't make it happen, the steps probably weren't clear or complete enough — exactly the reporting discipline from Topic 6. A vague bug is a bug that bounces.

"Cannot Reproduce" is rarely the developer's failure. It's usually a steps-to-reproduce that wasn't precise enough.

None of these mean you were wrong to report. A good tester files the bug and lets the team decide the resolution. Your job is to make it impossible to ignore by accident.

Lesson 8.4 — Jira and the rest of the toolbox

The tracker FreshCart uses is Jira, and that's the single most useful tool name to know walking into this field. Jira is the most common project- and bug-tracking tool in the industry, and you'll see it named in QA job ads constantly. Get comfortable with it and you've cleared a real bar.

In Jira, every bug is a ticket (also called an issue). Nadia's promo-code ticket holds everything she learned to write in Topic 6 — title, steps to reproduce, severity, priority, status, assignee, attachments — all in one place. As people work it, they update the status, and the ticket walks through the life cycle from Lesson 8.2 right there on the screen. Jira isn't the only one: Azure DevOps, Linear, and Bugzilla are common alternatives, and they all work on the same idea of a ticket that moves through statuses.

You don't need to be a Jira power user on day one. You need to know that a tracker is where bugs live, how to create a clear ticket, and how to drag it through its statuses. That's mostly your good reporting habits plus a little clicking around.

Two more kinds of tool sit next to the bug tracker:

Test management tools store and organize your test cases (Topic 5), not your bugs — and they track which were run, which passed, and which failed, so anyone can see how ready a release is. The big names: TestRail, which runs as its own standalone platform, and Xray and Zephyr, which live natively inside Jira so your tests and bugs sit in one system. On lighter teams, a well-organized spreadsheet does the same job, and there's no shame in that — FreshCart's first regression checklist was a Google Sheet.

Communication tools are where the work actually flows. FreshCart runs on Slack (Microsoft Teams is the equivalent elsewhere). When Nadia needs a quick "is this expected or a bug?" answer from Priya, she asks in Slack, not in a formal ticket. A surprising amount of QA is communication — clear, fast, friendly — and the chat tool is where that happens all day.

Lesson 8.5 — Browser dev tools, the free superpower

A few weeks in, checkout broke on the staging site. The page just sat there spinning. Nadia could have logged "checkout doesn't work, please look into it" — true, but thin. Instead Marcus showed her something that's been hiding in plain sight her whole career.

Every web browser has developer tools built in, free. You open them with F12, or by right-clicking the page and choosing Inspect. You don't need to read or write a single line of code to use them. Two tabs matter for QA:

• The Console tab shows JavaScript errors — the red text that appears when something on the page breaks. When checkout froze, the Console showed a bright red error message. Nadia couldn't fix it, but she could copy it.
• The Network tab shows every request the page makes to the server, each with a status code. Here's the part beginners get wrong, so look closely the first time you open it: DevTools doesn't paint the good requests green. A successful 200 shows up in plain, normal text like every other row — easy to scroll right past. It's the failures that jump out: 4xx and 5xx requests are highlighted in red. So a 500 (the server errored out) stands out, while a 200 (the request succeeded) just looks ordinary. When checkout failed, Nadia saw the payment request come back 500 instead of 200 — the red row was the exact moment it went wrong.

She pasted both — the Console error and the red 500 from Network — straight into her bug report. Priya opened the ticket and said, "Oh, I know exactly where that is." A fix that might have taken a day of back-and-forth took twenty minutes.

That's the move that makes a junior tester stand out. You're not debugging the code. You're handing the developer the evidence they'd otherwise have to dig for. It's free, it's two tabs, and almost no beginner bothers to learn it.

Worked example — One bug, end to end

A customer reports that paying with a saved card fails at the last step. Watch it travel the whole system.

Nadia reproduces it on staging, opens dev tools, and catches it red-handed: the Console throws an error, and the Network tab shows the /payments request returning 500. She opens a Jira ticket — title, exact steps, severity High (no one can pay), the Console error, and a screenshot of the red 500 attached. Status: New.

Tom reviews the morning's bugs, agrees it's urgent, and assigns it to Priya. She picks it up, the status flips to In Progress, and she drops a note in Slack: "looking at the payments 500 now, think it's the saved-card path." An hour later she marks it Fixed.

Now it's back to Nadia. She re-tests the exact steps with a saved card. It works — and she also checks a fresh card to be sure nothing else broke. She moves the ticket to Verified, then Closed, and logs the result in FreshCart's TestRail suite so the next regression run includes this case. One bug, one tool for each job, every status visible to the whole team the entire time. Nothing lived in anyone's memory.