What Is a Task? The Anatomy of a Jira Ticket

In software teams, the ticket is the atom of work. Everything starts with one, lives in one, and gets resolved in one. Knowing how to read a well-written ticket — and how to spot a badly written one — is a skill that will save you hours every week.

Learning Objectives

By the end of this lesson you will be able to:

• Identify the purpose of each field in a Jira ticket: Summary, Description, and Acceptance Criteria
• Explain what "Definition of Done" means and why it matters
• Recognise what a good ticket looks like versus a dangerous one

The Skeleton of a Ticket

Every Jira ticket has dozens of fields, but three carry the most weight for a QA engineer:

1. Summary

The Summary is the one-line title of the ticket. It should be specific enough to understand without reading the whole ticket.

✅  Good: "Login button disabled after failed OTP verification on iOS 17"
❌  Bad:  "Login doesn't work"

As a tester, you'll often use the Summary to find relevant tickets. A vague Summary is a wasted search result.

2. Description

The Description is the body of the ticket — the full context. A good Description answers:

• What is the problem / feature? — the "what"
• Why does it matter? — the business context
• How to reproduce it (for bug tickets)? — the steps
• What is the current vs expected behaviour?

Bug ticket description template:

Steps to reproduce:
1. Navigate to /login
2. Enter valid email, enter wrong password three times
3. Request OTP via email
4. Enter the received OTP

Current behaviour: Login button remains disabled after correct OTP entry
Expected behaviour: Login button becomes active; user is authenticated

Feature ticket description template:

As a [user type], I want to [do something] so that [I get some value].

Context: Currently users who...

Pro Tip: When a bug ticket has no reproduction steps, always ask the reporter to add them before picking it up. A bug you can't reproduce is a bug you can't verify is fixed.

3. Acceptance Criteria (AC)

Acceptance Criteria are the most important field for a QA engineer. They are the explicit, testable conditions that a ticket must satisfy before it can be considered complete.

A good Acceptance Criterion is:

• Specific — no room for interpretation
• Testable — you can write a test case directly from it
• Binary — it's either met or it isn't

✅  Good AC:
- When the user enters a correct OTP, the login button becomes enabled within 1 second
- When the session expires (> 30 min), the OTP becomes invalid and an error message is shown
- The OTP field accepts only 6-digit numeric input

❌  Bad AC:
- The OTP flow should work properly
- The login experience should be smooth

If you can't write a test case from an Acceptance Criterion, the AC is not done yet.

Definition of Done (DoD)

The Definition of Done is a shared team agreement that lists all conditions a task must satisfy before it can move to "Done." It lives above the individual ticket — it applies to every ticket.

A typical DoD might include:

• All Acceptance Criteria are met
• Code is reviewed and approved by at least one peer
• Unit tests are written and pass
• QA has tested on staging and signed off
• No P1/P2 bugs are open against this ticket

The DoD is the difference between "we finished coding it" and "this is actually done."

Key insight: As a QA engineer, you are one of the gatekeepers of the DoD. Your sign-off is what moves the ticket to "Done." Take that responsibility seriously — it's not a formality.

Other Fields Worth Knowing

Summary

A Jira ticket is a conversation in three parts:

1. Summary — what this ticket is about in one line
2. Description — the full story with context and reproduction steps
3. Acceptance Criteria — the exact conditions QA must verify

The Definition of Done is the team's shared contract that this ticket is truly finished.

Next lesson: follow a ticket on its journey across the entire Kanban board.