🔄 Workflows & Statuses

Workflows & Statuses: A workflow is like the sequence of gates at an airport: check-in, security, passport, boarding.

A workflow is like the sequence of gates at an airport: check-in, security, passport, boarding. Passing each gate requires permission and the order cannot be skipped -- you do not board before passport control. In Jira every status is a waiting lounge and every transition is a gate; who the gate opens for is decided by permissions. The question worth pausing on: why is moving a bug to "Done" not a single button? Because the word "done" alone means nothing: was the code written, reviewed, shipped to staging, and VERIFIED? A workflow is the contract that records the answers. Compare: when you write a state machine with an enum you block invalid transitions in code. In Jira that block does not live at compile time but in the workflow definition -- if you did not add a transition condition, the wrong move is allowed and nobody warns you. The critical point for QA is the resolution field: when a record moves to "Done" with a wrong (or empty) resolution, that bug either disappears from reports or still counts as open. One wrong field silently misleads your entire quality dashboard.

🧭 What You Will Learn in This Tab

We will cover the difference between status, transition and resolution; a typical bug workflow and where QA sits in it (Ready for QA to In QA to Done or Reopened); why the definition of "done" must be written down as a team; why conditions placed on transitions sometimes make your button invisible; and which chores automation rules can take over on specific transitions.

🎬 A Bug's Fall Into Reopened

SHOP-142 sits in "In Progress" -- Mert is fixing the coupon calculation function. In this film you will watch the record move gate to gate, and see how one gate sends it back.

Step 1 -- Mert finishes the code and triggers the "Ready for QA" transition. This transition has a condition: without code review approval, the button does not even appear. The approval exists, the transition opens.

Step 2 -- Ayse moves the record to "In QA" and runs the coupon scenario on staging. The single percentage coupon works correctly -- but Ayse tries one more scenario: coupon plus membership discount at the same time.

Step 3 -- In the second scenario the bug is still there: when the two discounts stack, the amount is calculated wrong again. Ayse moves the record to "Reopened" and adds a NEW reproduction step -- the original report was not incomplete, the scope simply widened.

Finale (the contrast) -- Mert writes the second fix, this time setting the resolution field to "Fixed" only AFTER Ayse VERIFIES it -- he leaves it EMPTY at his own transition. Had Mert set resolution to "Fixed" early, some reports would still count the record as "resolved" even after it fell into Reopened -- WHEN resolution gets set matters as much as reaching Done.

1️⃣ E1. The Status, Transition and Resolution Triplet

Compare this triplet to a traffic light system: status is the LIGHT'S COLOR (the current state -- red/yellow/green), transition is the LIGHT CHANGING (red to green, an event), and resolution is the INTERSECTION'S CAMERA RECORD (why this change happened -- a fault, planned maintenance). All three answer a different question. The question worth pausing on: why is "Done" alone not enough, why do you also need a resolution field? Because the same "Done" state can be reached for DIFFERENT REASONS -- was it genuinely fixed (Fixed), was it actually a duplicate (Duplicate), or was it never reproducible at all (Cannot Reproduce)? Status tells you "where it is", resolution tells you "WHY it is there". Compare: in Java, a method's return VALUE (like status -- which outcome was reached) and the EXCEPTION TYPE it throws (like resolution -- why that outcome was reached) carry different information; squeezing both into one field loses information. The practical takeaway for QA: a reporting query that only looks at status ("= Done") CANNOT tell apart bugs that were genuinely fixed from bugs closed as "cannot reproduce" -- it needs to look at resolution too.

A quality report answers "how many bugs were FIXED this month" with the query `status = Done`. What is wrong with this query?

Nothing is wrong, status = Done is enough

Done can also be reached via Duplicate or Cannot Reproduce; without checking resolution, genuinely fixed bugs CANNOT be told apart