Working with a Tracker

Every bug, story, and task on a real team lives in a tracker — a shared database of work items with a workflow attached. Jira is the name you'll hear most, but they all share one shape, and the shape is what you need to learn: tickets with fields, statuses that follow a lifecycle (yesterday's diagram, productized), assignees, comments, and links. The tracker is where your work becomes visible to everyone else — which makes using it with discipline a surprisingly large part of professional reputation.

Picture a busy kitchen's order-ticket rail: every order visible, in sequence, with a status, replacing the chaos of shouted requests. That's the tracker's whole job — the team's shared memory, readable at a glance. And like the rail, it only works if everyone keeps their tickets honest.

The Shape They All Share

Names you'll meet in job postings, one honest line each: Jira — the heavyweight standard, endlessly configurable, most common by far. Azure DevOps — Microsoft's suite, common in Microsoft-stack companies. Linear — the fast, minimal newer favorite of startups. GitHub Issues — lightweight, lives next to the code. The liberating fact: they rearrange the same parts — tickets, fields, statuses, links, filters. Learn the concepts on one and you can orient in any of them within a day; "which tracker do you know?" matters far less than postings imply, and saying exactly that (politely) in an interview is a fine answer.

Triage: Where New Bugs Get Sorted

Triage — the word from your Chapter 1 mornings, now in full — is the recurring pass where new bugs get processed: severity sanity-checked, priority assigned (Petra's call, your evidence), duplicates merged, owners picked. Some teams triage daily in fifteen minutes; some weekly; Fernway, being small, does it right after standup twice a week. Your job as the filer is to arrive pre-triaged: severity proposed, evidence attached, and — the habit that saves everyone — duplicates already searched. Thirty seconds of searching "date" and "time zone" before filing is the difference between FW-312 and FW-312-through-FW-315, four tickets for one bug, three of them wasting a triage slot each.

Hygiene: the Habits That Compound

Tracker discipline is a small set of habits, each trivial daily and enormous cumulatively. Search before filing — covered. Link related tickets — FW-329 links to FW-312 ("regression caused by this fix"), the test case links to the story (Chapter 5's traceability, maintained as you go, in seconds). Update statuses honestly, today — a ticket that says "in progress" about work that stopped Tuesday is a small lie the whole team plans around. Comment with findings, not chatter — "reproduced on build 4.2.17, narrowed to UTC+ zones only" belongs in the ticket; "any update on this?" belongs in chat. The principle under all four: a stale tracker lies to everyone who plans from it — and Nadia plans from it, Petra prioritizes from it, and Chapter 7's release decisions are made from it. The tracker is only as trustworthy as its least-maintained ticket.

New → Triagedsorted, prioritized, owned

→

In progressfindings live in comments

→

Fixedawaiting your re-test

→

Verified → Closedre-tested, linked, done

Your Queue as Your Workbench

Trackers earn their keep through filters — saved searches that become your daily views. Three every QA engineer builds in week one: "my open bugs" (everything you filed that's still alive — you are its advocate until closure), "fixed, awaiting verification" (your morning queue — the gate from last topic, operationalized), and "new since yesterday" (what landed overnight, feeding triage). Dashboards are just filters arranged on one screen; every tracker builds them from the same idea. Ten minutes of filter setup replaces an hour a week of scrolling — and makes you the person who never loses a ticket, which is a quiet but real reputation.

The First-Week Cleanup

Here's what the tracker looked like when you arrived at Fernway — before the book's timeline, in the testing-by-hoping era: 82 open tickets. Half of them stale — filed a year ago against screens that no longer exist. No severities anywhere. Four separate tickets for one search bug, unlinked. A dozen "in progress" items whose progress stopped in the spring. Your first week's least glamorous work: merge the duplicates (one survivor, three closed-as-duplicate with links), close the stale ones with reasons ("screen removed in the March redesign" — closed-with-reason is information; silently deleted is vandalism), tag severities on the twenty that remain real, and build the three filters. By Friday the tracker tells the truth: about twenty real, current, prioritized bugs. Nadia notices — everyone notices, because now planning works from facts. Unglamorous, and it made you visible to the whole team in five days: tracker discipline is the cheapest reputation a new tester can buy.