Jira and defect life cycle

Workflow basics

1. What is a defect life cycle?

It is the path a defect takes from discovery through investigation, remediation and an agreed outcome. Teams configure different statuses and transitions. Explain the workflow you used instead of presenting one diagram as mandatory for every Jira project.

2. Is Jira a testing tool or a bug tracker?

Jira tracks work and supports workflows, including defects. Dedicated test-case management often uses an app or an external system. Do not assume every installation includes test executions, test plans or the same custom fields.

3. What is a status versus a transition?

A status describes the current workflow state; a transition moves the item to another state. A “Ready for retest” state might be entered through a “Deploy fix” transition. Access conditions can make a transition unavailable to some users.

4. What is a typical defect workflow?

An illustrative flow is Open, In progress, Ready for retest and Closed, with a route back to investigation when retesting fails. Those names are team choices. A developer finishing code does not by itself establish that a tested fix is deployed.

5. How do status and resolution differ?

Status describes progress; resolution records why work is considered resolved, such as Fixed or Duplicate in a configured project. An apparently open item with a populated resolution can distort reports. Reopening often needs workflow configuration that clears the resolution.

6. How do severity and priority differ?

Severity describes impact; priority expresses the urgency or ordering of work. A rare data-loss defect can be severe even before its likelihood is understood. Many projects use custom severity fields, so check their definitions instead of inferring severity from the priority icon.

7. Who decides a bug’s priority?

The team’s triage agreement determines decision rights, often involving product and engineering with QA evidence. A tester proposes urgency with user impact, frequency and release context. Do not escalate every defect to the highest priority just to get attention.

8. What does rejected mean?

It means the team has declined the report for a recorded reason, such as intended behavior or insufficient evidence. The exact status and resolution vary. If the behavior conflicts with an agreed requirement, discuss that evidence rather than treating rejection as proof the tester was wrong.

Useful defect reports

9. What makes a bug report actionable?

Give a precise summary, build and environment, prerequisites, minimal steps, expected and actual behavior, and evidence. Mention frequency and affected data scope when known. A screenshot without reproduction context rarely tells a developer what to change.

10. How would you report an incorrect checkout total?

For a deliberately fake example, state the basket items, displayed prices, discount and tax rules, then show the expected calculation and observed total. Attach the build identifier and sanitized response if relevant. Distinguish a wrong calculation from a misunderstood shipping rule.

11. What should a good title contain?

Name the feature, condition and failure, such as “Checkout retains expired coupon after basket refresh.” Avoid “not working” or a title that already asserts an unproven root cause. A useful title lets triage distinguish it from a similar report quickly.

12. How much evidence should you attach?

Attach enough to establish the behavior: a short recording, relevant request identifiers or a minimal log excerpt. Remove credentials, personal data and session tokens. A full production log dump can create a privacy problem while making the useful detail harder to find.

13. Should every observation be a separate bug?

Separate independently actionable failures, but avoid duplicating one root symptom across many reports without links. If an incorrect subtotal drives several downstream displays, explain the scope in one report or use linked items. Do not combine unrelated defects merely because they appeared during one test.

14. How do you handle cannot reproduce?

Compare exact build, configuration, user state, data and timing with the developer. Narrow the reproduction and record intermittent frequency only from actual attempts. Keep the report open or resolve it according to agreed evidence, rather than inventing a reliable reproduction.

15. When should you reopen a defect?

Reopen when the promised fix fails the same acceptance expectation on the intended build. Include the retest environment and new evidence. If the original fix works but another behavior fails, consider a linked new defect so history remains meaningful.

16. How do you handle duplicate reports?

Confirm that the symptom and relevant cause or scope are actually covered by the original report. Link the duplicate to the retained item and preserve any new reproduction detail. Similar error text alone does not prove two failures have the same cause.

Searching and reporting

17. What is JQL?

Jira Query Language filters work items by fields, operators and functions. It does not directly update the matching items. Field availability and names depend on the project and permissions, so a syntactically reasonable query can still need local adaptation.

18. How do you find unresolved bugs in one project?

An illustrative query follows. QA is a fake project key; this was checked against JQL documentation but not executed against a Jira instance. The project must have the named issue type and the user must have permission to see its items.

project = QA AND issuetype = Bug AND resolution IS EMPTY ORDER BY priority DESC, created ASC

19. How do you find your unresolved assigned work?

Use the current-user function to avoid hard-coding another person’s account identifier. This documentation-checked query was not run against a live Jira instance. A filter returns only work visible to its viewer.

assignee = currentUser() AND resolution IS EMPTY ORDER BY updated DESC

20. Why can a not-equal filter miss unassigned work?

An empty field is not necessarily included by a not-equal comparison. Explicitly include the empty case when it belongs in the result. This documentation-checked example was not run live.

project = QA AND (assignee != currentUser() OR assignee IS EMPTY)

21. How are saved filters useful to testers?

Save a repeatable search for retest work or release defects, then share it with the intended audience. Check filter permissions as well as item permissions. A filter that works for its author may appear incomplete to someone with narrower access.

22. What belongs on a defect dashboard?

Choose views that support decisions, such as unresolved bugs by priority, aging retest work and release-specific unresolved defects. State each filter’s scope and refresh expectations. A colourful chart of all historic bugs is less useful than a focused view of current risk.

23. How do you link tests to stories?

Record the story reference in the test system and link execution evidence back to the relevant work item. A test-management app may add richer relationships, but ordinary links do not prove coverage. Check that the linked execution ran against the intended build.

24. What do fix version and affected version mean?

Affected version records where a problem was observed; fix version records the intended or actual release for its correction according to team practice. Neither is the same as a deployed build identifier. An incorrectly set version can make a release defect filter misleading.

Triage scenarios

25. What happens in defect triage?

Review impact, evidence, duplicates, ownership, ordering and the next action. Include product and engineering perspectives when release trade-offs are needed. Triage should produce decisions, not just a second reading of every report title.

26. How do you handle an old defect that still reproduces?

Retest on a current relevant build and update its impact and reproduction evidence. Ask whether it still affects supported users and upcoming changes. Closing solely because it is old makes backlog size look better without resolving the risk.

27. A developer marks Fixed but QA has no build. What now?

Record the fix reference and request the deployment or build where it can be evaluated. Use the team’s waiting-for-retest or deployment state if configured. Never mark retest passed based only on a merged pull request.

28. What if a transition is missing?

Check the current status, workflow, permissions and any transition conditions with the project administrator. Do not create duplicate tickets to work around a configuration problem. Record the intended action and the blocker so the workflow can be corrected.

29. Should automation close bugs when tests pass?

A passing check can supply evidence, but closure rules must address the correct build, scenario and any remaining manual evaluation. Keep automated transitions auditable. One passing smoke test is not enough to close a defect whose reproduction it does not cover.

30. How would you explain defect ownership in an interview?

Describe how you supplied evidence, helped triage, retested the delivered fix and checked nearby risks. State the configured workflow names as examples from that project. Avoid claiming that QA alone owns product quality.

Likely follow-up: What if the same defect returns later? Compare the regression with the original scope and link the history so investigation can use both.

Practise it

Find a reproducible defect in ShopLite and write it using the bug report template. Practise a triage conversation locally; no Jira account is required.