What is a JIRA workflow and how might a QA engineer need to customise it?

Workflow components:

• Statuses — the states an issue can be in (Open, In Progress, In Review, Ready for QA, In Testing, Done).
• Transitions — the allowed moves between statuses (e.g., "In Testing → Reopen → In Progress").
• Conditions — rules that must be true for a transition to fire (e.g., "Fix Version must be set before closing").
• Validators — field-level checks on transition (e.g., "Resolution is required to close").
• Post-functions — actions that happen automatically on transition (e.g., "Send email to reporter when status = Resolved").

Common QA workflow customisations:

1. Add a "Ready for QA" status — separates "developer says it's done" from "deployed to test environment and ready to verify." Without it, QA doesn't know when something is actually testable.

2. Add "In Testing" status — signals that a QA engineer has picked up the issue and is actively verifying. Prevents two QAs from testing the same issue.

3. Reopen transition — moves a closed bug back to In Progress when the fix is incomplete, preserving history.

4. Condition: Fix Version required before closing — prevents developers from closing bugs without recording which release the fix is in.

5. Condition: QA sign-off required before Done — in regulated industries, some workflows require a specific role to perform the closing transition.

Requesting workflow changes: You'll need to work with a JIRA admin. Document the business reason — "we can't track QA throughput without an In Testing status" is a clear justification.