Working with Jira

project = SHOP AND type = Bug AND status != Done ORDER BY priority DESC

Issue types

Jira organizes work in a small hierarchy. Your team may add custom types, but these five are nearly universal:

Type	What it means	QuickBite example
Epic	A large goal, split into stories and tasks, often spanning several sprints	SHOP-120 Courier tipping
Story	A user-facing feature, usually written as a user storyUser storyA short description of a feature from the user's point of view.Open in glossary →	SHOP-142 Add a tip for the courier at checkout
Task	Work that isn’t a user feature: setup, tech work, test prep	SHOP-158 Update the regression suite for tipping
Bug	Behavior that doesn’t match what’s expected	SHOP-150 Order total ignores custom tip on Android
Sub-task	A smaller step inside a story, task or bug	SHOP-143 Tip selector UI

Boards and sprints

A board shows issues as cards in columns, one column per status (or group of statuses). Teams usually use one of two kinds:

• Scrum board: work is planned into a sprintSprintA short, fixed period (often two weeks) in which a team builds and tests a set of work.Open in glossary →, a time box of usually one to four weeks. The board shows only the current sprint; everything else waits in the backlog. At the end of the sprint the team reviews what got done. See ScrumScrumA popular agile framework where a team works in short sprints with fixed roles and meetings.Open in glossary → for the bigger picture.
• Kanban board: no sprints. Work flows continuously from left to right, and teams often limit how many cards can sit in a column at once (a “WIP limit”) to avoid bottlenecks. Common for support and maintenance teams.

As a tester, the board is your daily to-do list: the cards in In Testing (or QA, Ready for test, whatever your team calls it) are waiting for you.

Workflows and statuses

A workflow is the set of statuses an issue can be in and the allowed moves between them. Every team’s workflow is different, so learn yours in your first week. A typical one:

Bugs often have their own workflow with extra statuses like Reopened. If a fixed bug fails your retest, you move it back (reopen it) with a comment explaining what still happens. How often that happens is tracked as the reopen rateReopen rateThe share of fixed bugs that fail retesting or come back later.Open in glossary →. For the full journey of a bug, see the Bug Life Cycle lesson.

The fields testers use

Field	What to put in it	Tip
Summary	Where + what + when	“Checkout: order total ignores custom tip on Android”
Description	Preconditions, steps, expected, actual, notes	Use numbered lists; paste errors as code
Environment	Device, OS, app version + buildBuildA specific compiled version of the app or website that is ready to be installed or tested.Open in glossary →, server	“Pixel 8, Android 15, 3.8.0 (409), Staging”
Component	The part of the product	Routes the bug to the right team
Labels	Free tags for filtering	android, regression, checkout
Affects version	The version where you found it	3.8.0
Fix version	The release that will contain the fix	Usually set in triageTriageReviewing new bugs to decide if they're valid, how severe and urgent they are, and who fixes them.Open in glossary →, not by you
Priority	How soon it should be fixed	Your proposal; the team may change it
Attachments	Screenshots, videos, logs	Name them clearly: tip-total-wrong.mp4

Links between issues

Links connect tickets so the whole team sees how work relates. The three you’ll use most:

• blocks / is blocked by: SHOP-150 blocks SHOP-142 means the story can’t be finished until the bug is fixed.
• relates to: connected, but not blocking. A similar bug on iOS, a related story.
• duplicates / is duplicated by: the same problem was already reported. Close the newer one as a duplicateDuplicate bugA bug report that describes a bug someone already reported.Open in glossary → and link it to the original.

Bugs found while testing a story are linked to that story (or created as a sub-task of it, if that’s your team’s habit). That’s what stops a story from being closed with known bugs, and it’s what lets a lead see at a glance which features are healthy.

Creating a good bug ticket

Everything from How to Write a Bug Report applies. The Jira-specific checklist:

Comments, mentions and watching

The comment thread is where the real conversation about an issue happens. A few habits make you easy to work with:

• @mention a person when you need them to act or answer: “@Luka can you check if this also affects the web checkout?” Don’t mention the whole team for information.
• Watch issues you care about (your bugs, stories you test). You’ll get notified about changes and comments, without anyone mentioning you.
• Be factual and specific. “Retested on build 412, Pixel 8: fixed. Also checked preset tips and no tip.” beats “works now”.
• Keep decisions in the ticket, not only in chat. If a product owner says “won’t fix, by design” in a call, add a comment so the next person knows why.
• One topic per comment, newest information first if you edit. Use the description for the reproducible facts and comments for the conversation.
• No blame, no sarcasm. The ticket is permanent and widely read.

Finding things: filters and JQL

The search box in Jira understands two modes: a simple one with dropdowns, and JQL (Jira Query Language) for precise queries. JQL looks like code, but it’s really just sentences made of field, operator, value, joined with AND / OR, plus an optional ORDER BY.

project = SHOP AND type = Bug AND status != Done ORDER BY priority DESC

Piece	Meaning
project = SHOP	Only issues in the SHOP project
type = Bug	Only bugs (type is short for issuetype)
status != Done	Everything not in the Done status
ORDER BY priority DESC	Highest priority first

A few more you’ll use constantly:

Query	Finds
assignee = currentUser() AND statusCategory != Done	My open work
project = SHOP AND type = Bug AND created >= -7d	Bugs from the last 7 days
fixVersion = "3.8.0" AND status != Done	What’s left for the release
labels = regression AND type = Bug	Bugs tagged as regressions
assignee is EMPTY AND type = Bug	Bugs nobody picked up
reporter = currentUser() ORDER BY updated DESC	Issues I reported, latest activity first

Saved filters and dashboards

When a query is useful, save it as a filter with a clear name (“SHOP open bugs by priority”). Saved filters can be shared with the team, used as the source of a board, and subscribed to, so Jira emails you the results on a schedule.

A dashboard is a page of small panels (gadgets), each fed by a filter: a list of your open bugs, a pie chart of bugs by component, a “created vs resolved” chart for the release. A simple tester dashboard might show:

• My open work (assignee = currentUser() AND statusCategory != Done)
• Bugs waiting for retest (status = "In Testing" AND type = Bug)
• New bugs this week, by priority
• Open bugs for the next release (fixVersion = "3.8.0" AND type = Bug AND statusCategory != Done)

Test management add-ons

Jira on its own tracks stories, tasks and bugs, but not test cases or test runs. Teams add that with apps from Atlassian’s marketplace, such as Xray or Zephyr, or connect an external tool like TestRail. With these, test cases can be linked to stories (for test coverageTest coverageHow much of the product, requirements or risks your tests actually check.Open in glossary → and a traceability matrixTraceability matrixA table linking each requirement to the test cases that cover it.Open in glossary →), test runs record results per build, and a failed test can create a linked bug in one click. You’ll learn the specific tool on the job; the ideas are covered in Regression and Smoke Suites.

Common mistakes