🧩 Issue Types & Hierarchy

Issue Types & Hierarchy: Picture a construction project: the floor plan (Epic) describes a whole goal, each apartment (Story) is a deliverable piece, and the individual jobs insi

Picture a construction project: the floor plan (Epic) describes a whole goal, each apartment (Story) is a deliverable piece, and the individual jobs inside it (Sub-task) are the steps that finish that piece. A Bug arrives from outside this hierarchy: it is damage found in an already delivered apartment -- a work item in its own right, yet always pointing back to an apartment. The question worth pausing on: if they all end up as cards on a board anyway, does it really matter whether you file something as a Story, a Task or a Bug? The importance is not in the card but in the number produced from it: the sentence "20 bugs came out of this sprint" is a lie if 12 of those cards were really forgotten work items. Compare: in Java the compiler stops you when you use the wrong type. In Jira picking the wrong issue type raises no warning -- the cost appears not at compile time but three months later in a quality report. Type safety here lives in discipline, not in a machine. For QA this means: writing down, as a team, the boundary between a bug and a task is the precondition of every quality metric you measure. No definition, no metric; no metric, and the answer to "is quality improving" is pure intuition.

🧭 What You Will Learn in This Tab

We will cover the Epic to Story to Task to Sub-task hierarchy and where a Bug sits in that tree, which fields make up an issue and on which screen those fields appear, the answer to "why is this field missing in this project", and how issue link types (blocks / is blocked by / duplicates / relates to) affect sprint planning.

🎬 How a Bug Is Born Under an Epic

Epic SHOP-100 -- "Checkout Flow Overhaul" -- describes a large goal that cannot be delivered on its own. In this film you will watch how that goal breaks into small pieces, and where a bug is eventually born from.

Step 1 -- The Epic breaks into a Story: SHOP-118 "Apply Coupon Code" is one deliverable piece. An Epic can hold dozens of Stories; each is delivered independently.

Step 2 -- The Story breaks into Sub-tasks: "coupon field UI", "backend discount calculation", "e2e test". Each Sub-task is a concrete piece of work one person can finish in a day.

Step 3 -- All Sub-tasks finish, the Story goes Done, the feature ships. The hierarchy is complete here -- the Epic to Story to Sub-task chain has closed.

Finale (the contrast) -- Two weeks later Ayse notices in the live environment that the coupon discount is deducted twice. SHOP-142 is filed -- but this bug is NOT a child INSIDE the hierarchy; it arrives from OUTSIDE the hierarchy and attaches to the Story via a LINK ("caused by SHOP-118"). Epic to Story to Sub-task describes planned work; a Bug describes an unplanned, discovered reality -- the two do not live in the same tree.

1️⃣ C1. The Hierarchy: Epic to Story to Sub-task

Compare this hierarchy to a Java package structure: an Epic is like a PACKAGE (`com.shopqa.checkout`) -- it holds a broad goal together. A Story is like a CLASS (`CouponService`) -- it has one responsibility, one purpose. A Sub-task is like a METHOD (`applyDiscount()`) -- it does one concrete thing. The question worth pausing on: where does this analogy break? A Java package can hold classes with no relation to each other at all (no required link) -- but every Story under an Epic MUST serve the SAME goal. So the Jira hierarchy carries a STRICTER constraint than a package: not grouping, but division toward a shared purpose. Compare further: a method can contain another method (a nested function), but a class inside a class is uncommon in Java; in Jira a Sub-task under a Sub-task CANNOT be opened either -- the hierarchy is capped at three levels, there is no infinite depth. What this means for QA: filing work at the wrong level (say, opening a Sub-task as if it were a Story) is not just visual clutter -- reporting tools sum things up by level, and the wrong level corrupts that sum.

Step by Step: How a Goal Breaks Into Deliverable Pieces

"Checkout Flow Overhaul" -- a goal that cannot be tested on its own and takes weeks. It does not fit in one sprint.

Story: a deliverable slice