Defect Life Cycle: From Log to Close in Mobile QA

Key takeaways

• The standard 7-state defect life cycle (New → Assigned → Fixed → Verified → Closed) covers about 60% of what actually happens. The other 40% is invisible states like Cannot Reproduce, Not a Bug, Duplicate, and Deferred, which trap real work.
• Mobile adds three complications to defect life cycle that web teams don't face: device-specific bugs, OS version regressions, and "works on my device" verification gap between dev and QA.
• The metrics that indicate life cycle health aren't total bug counts. They're time-in-state, reopen rate, cannot-reproduce rate, and aging. Teams that track these ship fewer regressions than teams that only track "bugs found this sprint."

The defect life cycle is sequence of states a bug moves through from moment it's reported until it's permanently resolved. Every generic post covers same 7-11 states with same flow diagram. This one goes into 12 states that actually exist in mature bug tracking, transitions between them, and where flow breaks on mobile teams specifically.

Bug life cycle in mobile QA has to account for things a web-only life cycle doesn't. Device fragmentation, OS version regressions, and a verification problem where dev and QA are testing on different devices are all defect life cycle complications that don't show up in generic model. Density measures outcome of many defect life cycle runs, not any single bug, and per-state metrics tell a different story than aggregate ones.

What defect life cycle actually is

The defect life cycle is a state machine. The bug is a token. The states describe where bug is in process. The transitions describe who moved it and why.

Standard SERP content presents it as a linear flow. It isn't. It's a graph with cycles, dead ends, and asymmetric transitions. IEEE 1044-2009 (Standard Classification for Software Anomalies) is underlying reference most bug tracking tools build on, even when they don't cite it directly.

What life cycle actually captures:

• Where each bug currently sits in process
• Who's responsible for next action on it
• How long it's been in current state
• Whether it's on critical path or parked

What life cycle doesn't capture (but should):

• Whether fix has been released to users (different from "fixed in code")
• Which devices/OS versions bug affects
• Whether fix touched related but untested code
• The severity/priority evolution as new information surfaces

Severity and priority get set at start of defect life cycle and change as bug moves through it. A bug initially triaged as "medium severity, low priority" can be reclassified when a customer support ticket surfaces same issue affecting hundreds of users. That reclassification needs to happen inside life cycle, not as a separate process.

The 12 states in a mature defect life cycle

Standard posts cover 7-11 states. The real number in a mature bug tracking setup is closer to 12. Here they are with what each actually means.

1. New (or Reported)

A tester, developer, automated test, or end user has logged something. Nobody has looked at it yet. This is intake queue.

The state exists to acknowledge receipt without committing to action. In a healthy team, bugs don't stay in New for more than 24 hours.

2. Triaged

A QA lead or triage team has reviewed bug. They've confirmed it's:

• Reproducible (or noted conditions where it isn't)
• Not already in system as a duplicate
• Categorized by severity, priority, and affected component
• Assigned to a queue (this team, this release, this sprint)

Some teams skip triage and go from New straight to Assigned. That works at 5 bugs a week. It breaks at 50 bugs a week.

3. Assigned

A specific developer owns bug. They may not have started yet, but accountability is now on them.

4. In Progress (or Open)

The developer has started investigating or fixing. Work is happening.

5. Fixed (code committed, not verified)

The developer believes bug is fixed. Code is in a branch, PR, or merged to main. QA hasn't verified.

This is state that gets abused most. Devs mark bugs Fixed when they think they've fixed them. Sometimes fix works. Sometimes it doesn't. Sometimes it introduces a new bug. The state doesn't guarantee anything except developer intent.

6. Ready for Verification

The fix is in a build QA can test. Different from Fixed because Fixed means "in code" and Ready for Verification means "in a build QA can install and check."

Skipping this distinction is a common source of "we can't verify fix because build isn't ready yet" delays.

7. Verified (or Retested Pass)

QA has tested fix on affected build and confirmed it works. The bug is functionally resolved.

8. Closed

The bug is done. No further action required. Either verified and released to users, or verified and part of pending release.

9. Reopened

QA (or a user) confirms bug is still present after it was marked Fixed or Closed. The bug returns to developer's queue with a special flag: this was supposed to be fixed and wasn't.

Reopens are important signals. High reopen rates mean fixes aren't being verified properly, or underlying issue was misunderstood.

10. Deferred

The bug is valid but won't be addressed in current release cycle. Scheduled for a future sprint or release.

Deferred bugs need expiration dates. Otherwise they accumulate forever and pollute backlog.

11. Duplicate

The bug is a rediscovery of one already in system. Linked to original, closed for tracking purposes.

12. Rejected (Not a Bug or Won't Fix)

The reported behavior is correct as specified, or product decision is not to fix. Includes:

• Not a Bug: The behavior is correct per specification
• Won't Fix: The behavior is technically incorrect but fix cost exceeds value
• Cannot Reproduce: Nobody can reproduce bug from report

Rejecting a bug needs justification. Just closing it without explanation is how tester-developer relationships break. False positives clog defect life cycle with tickets that get closed without any code changing, so tracking rejection rates by category is a leading indicator of test noise.

The state transition matrix

Not every state can transition to every other state. Here's actual transition map.

Invalid transitions to enforce in your bug tracking tool:

• New cannot go directly to Fixed (skips triage)
• Fixed cannot go directly to Closed (skips verification)
• Closed cannot go back to any earlier state except Reopened
• Deferred needs an owner and a date, not just a status change

Enforcing valid transitions in Jira workflows, Linear states, or GitHub Projects is what turns a state field into a real workflow. Without enforcement, states are labels people apply inconsistently.

The four invisible states nobody documents

These four states account for a big chunk of bug volume and they get treated as edge cases when they should have first-class workflows.

Cannot Reproduce

The reporter saw bug. The developer can't recreate it. Nobody knows what to do.

Common causes on mobile:

• Different device than reporter used
• Different OS version
• Different app version (reporter was on an older build)
• User state developer doesn't have (specific account, feature flag combination)
• Timing-dependent race condition that doesn't fire every time
• Network condition developer isn't reproducing

The wrong response: mark it Cannot Reproduce and close. The bug goes away from tracker but not from production.

The right response: request specific reproduction data (device model, OS version, app version, video), assign to reporter with a specific ask, and only close if no response within a defined window (typically 5 business days).

Not a Bug (works as designed)

The reporter thinks something is broken. The developer says it's working correctly per spec.

This is where product-QA misalignment surfaces. Half time, spec is genuinely wrong (or missing). The other half, tester misread requirements.

The workflow that works: developer justifies with a link to spec. QA and product both review justification. If everyone agrees it's not a bug, close. If not, escalate to product owner for a spec update.

Duplicate

Two different testers report same bug independently. Or same tester reports it twice.

Duplicates are more common than teams realize. They're also more useful than teams realize. A bug reported 5 times independently is a higher-severity bug than one reported once, even if severity classification stayed same.

The workflow that works: link duplicate to original, add reporter to original's watch list, close duplicate. Track duplicate rate as a signal for both bug severity (many dupes = widespread) and process efficiency (many dupes = search isn't working).

Deferred

The bug is valid. It's real. Nobody's fixing it right now.

Deferred is state that accumulates dead bugs. In an unhealthy backlog, "Deferred" is where bugs go to die. In a healthy one, Deferred has a date and an owner responsible for revisiting.

The rules that keep Deferred honest:

• Every Deferred bug has an expiration date (when it comes back for review)
• Every Deferred bug has an owner (who will make call at that date)
• Deferred bugs go through triage again at their date, not automatic reactivation
• Bugs deferred more than 3 times get closed as Won't Fix

Mobile-specific complications

The generic defect life cycle assumes one runtime, one environment, one platform. Mobile violates all three.

Device-specific bugs

A bug affects Pixel 6 but not Pixel 8. Or Galaxy S22 but not Galaxy A54. The fix might work on one and break on other.

The life cycle needs to capture affected devices. Otherwise "Fixed" becomes "Fixed on dev's phone."

OS version-specific bugs

A bug affects iOS 15 but not iOS 17. Or Android 12 but not Android 14.

Fixing OS-specific bugs is complicated because sometimes you can't fix them - OS behavior changed and there's no workaround. That bug needs to move to Deferred with a note about OS support timeline rather than staying open forever.

Regression on OS updates

Apple releases iOS 18. Your app now behaves differently in a specific edge case. A bug that was working in iOS 17 is now broken in iOS 18.

This kind of bug doesn't come from your code changing. It comes from OS changing under your code. The life cycle needs to distinguish "regression from our change" from "regression from OS change" because debugging approach differs.

The verification device gap

Dev fixes bug on their iPhone 15 Pro. QA verifies on their iPhone SE 3rd gen. The bug appears fixed in both places.

But original report was on an iPhone 12 with iOS 16. That device wasn't tested. The bug might still be present there.

Mobile teams need explicit "verified on" tracking. "Fixed and verified" is meaningless without device and OS version list.

App version tracking

Bug reported on v3.4.1. Fix ships in v3.4.2. But users don't auto-update. Half userbase is still on v3.4.1 and still seeing bug.

The life cycle "Closed" state should track "closed at what version" and "% of users on that version or higher." Otherwise, closed bugs keep generating support tickets from users on old versions.

The verification problem

Mobile verification is genuinely harder than web verification. Here's pattern that keeps failing.

How verification breaks:

1. QA logs bug on iPhone 12 with iOS 16.
2. Dev fixes on their MacBook Simulator (iOS 17, different device model).
3. Dev marks Fixed.
4. QA verifies on their test device (iPhone SE 3rd gen, iOS 17).
5. QA marks Verified.
6. Ship.
7. User on iPhone 12 iOS 16 still hits bug. Support ticket.
8. Bug returns as new report because tracker shows old one Closed.

Every step is "correct" but net effect is a bug that stays in production.

The pattern that works:

• Bug report must specify device model, OS version, app version at time of report
• Fix must be verified on original reporting environment (or as close as available)
• Verified state includes an explicit "verified on: [device, OS, app version]" list
• If verification device doesn't match report device, verification is provisional until reporter re-tests

This is more overhead than most teams want. Teams that skip it ship regressions users hit.

Metrics per state that actually matter

Total bug count is metric everyone tracks. It tells you almost nothing about life cycle health.

Cycle time

Total time from New to Closed. Median and P95. If cycle time is growing, process is slowing down somewhere.

Break this down into segments:

• New → Triaged (triage backlog signal)
• Triaged → Assigned (queue depth signal)
• Assigned → Fixed (developer throughput signal)
• Fixed → Verified (build and verification pipeline signal)
• Verified → Closed (release cadence signal)

The slowest segment is where bottleneck lives.

Time-in-state (per state)

If most bugs sit in Ready for Verification for 3 days, your build pipeline is bottleneck. If most bugs sit in Assigned for 5 days before In Progress, your developer allocation is broken.

Reopen rate

Reopened bugs / Total closed bugs. Should be under 5% for a healthy team.

High reopen rate means:

• Fixes aren't being verified properly
• Developer misunderstood bug
• Fix caused a regression tester didn't catch
• Verification device didn't match report device (see previous section)

Cannot Reproduce rate

Cannot Reproduce closures / Total closures. Should be under 10%.

High Cannot Reproduce rate means:

• Bug reports are missing critical reproduction data
• Test environments don't match production environments
• Real bugs are being closed prematurely

Duplicate rate

Duplicates / Total reported. High rate means testers can't find existing bugs (search issue) or same bug is genuinely widespread.

Aging

Bugs in each state longer than N days. Alert on:

• Any bug in Assigned > 5 days without transition to In Progress
• Any bug in Fixed > 3 days without transition to Verified
• Any Deferred bug past its revisit date

What breaks defect life cycles at scale

Small teams can run a life cycle with 6 states in Google Sheets. Large teams can't. Here's what breaks and when.

Under 50 bugs/month:

• Any tool works
• Manual triage is fine
• Ownership is clear because there aren't many devs

50-500 bugs/month:

• Need a real bug tracker (Jira, Linear, GitHub Issues with automation)
• Triage becomes a scheduled meeting
• Deferred backlog starts accumulating
• Reopen rate needs monitoring

500-2000 bugs/month:

• Need automated triage rules (by component, severity, keyword)
• Aging alerts become essential
• Duplicate detection needs to work (search, similarity matching)
• Multiple triage owners by component

2000+ bugs/month:

• Enterprise tools required (Jira with automation, or dedicated defect management tools)
• Dashboards for each state
• Machine learning for triage prediction becomes viable
• Dedicated defect management role

The transitions between scales are painful. Teams that outgrow their tools ship regressions during transition period.

Bug tracking tools compared for defect life cycle support

Different tools handle defect life cycle differently. Trade-offs:

Jira

• Fully customizable workflows and states
• Strong reporting on time-in-state and cycle time
• Integrations with everything
• Weakness: complexity adds up, workflows drift without governance

Linear

• Fast, opinionated workflows
• Clean state model with limited customization
• Good for teams that want to move quickly
• Weakness: less flexible for complex life cycles or regulated environments

GitHub Issues + Projects

• Free for public repos, cheap for private
• Good if your team already lives in GitHub
• Automations via GitHub Actions
• Weakness: less mature reporting, weaker workflow enforcement

Shortcut (formerly Clubhouse)

• Middle ground between Jira and Linear
• Story-based workflows fit product teams
• Weakness: less common, fewer integrations

ClickUp / Monday.com

• General project management with bug tracking capability
• Fine for small teams
• Weakness: not purpose-built for bug tracking, state models are shallow

The right tool depends on team size and life cycle complexity, not on which is "best." A 6-person startup with Linear beats an enterprise with badly-configured Jira. Same team on Jira beats them on Linear if their workflow needs 12 states.

Where automated regression fits

The Fixed → Verified transition is bottleneck for most teams. Verification is manual by default, and manual verification is slow.

Automated regression that reliably catches "specific bug is fixed AND nothing else broke" would collapse that transition from days to hours. Most mobile teams don't have this because selector-based test frameworks (Appium, XCUITest, Espresso) are too flaky to trust for verification.

The flakiness problem in verification:

• QA runs automated regression suite after a fix
• 15% of tests fail
• 3 of failures are real (fix regressed something, or original bug isn't fully fixed)
• 12 of failures are framework flakes
• QA lead spends 90 minutes triaging which failures are real
• Fixed → Verified takes days instead of hours

Drizz tests are written in plain English:

• Tap "Log in"
• Validate "Welcome back" is visible

Vision AI reads screen way a user does. The tests don't flake on selector changes, so a failure in verification actually means something failed.

Before, on Appium:

• Fix ships to staging Monday
• QA runs regression Monday afternoon: 15% flaky failures
• QA triages Tuesday morning: 3 real failures identified
• Dev investigates and re-fixes Wednesday
• QA re-verifies Thursday
• Fixed → Verified: 4 days

After, on Drizz:

• Fix ships to staging Monday
• QA runs regression Monday afternoon: 2% failures
• QA reviews 2%: 1 real regression, 1 flake identified in 15 minutes
• Dev fixes regression Monday evening
• QA re-verifies Tuesday morning
• Fixed → Verified: 1 day

The defect life cycle math works because Fixed → Verified segment shrinks by 75%. That flows through to cycle time, throughput, and how quickly production bugs get resolved.

The defect life cycle is only as fast as its slowest state. For most mobile teams, that's Fixed → Verified. Get framework right, and whole life cycle speeds up.

FAQ

What are stages of defect life cycle?

New, Triaged, Assigned, In Progress, Fixed, Ready for Verification, Verified, Closed, Reopened, Deferred, Duplicate, Rejected.

What's difference between bug life cycle and defect life cycle?

Nothing. They're used interchangeably. Some teams prefer "defect" because it sounds more formal. Others use "bug." Same process.

Who owns defect life cycle?

QA typically owns process. Product owns priority. Engineering owns fixes. Life cycle spans all three teams.

What does Cannot Reproduce mean in bug tracking?

The bug can't be recreated by developer. Often a mobile-specific reproduction problem where devices, OS, or app versions differ.

How do you know if your defect life cycle is working?

Track cycle time, reopen rate under 5%, Cannot Reproduce rate under 10%, and aging alerts.

Should closed bugs ever be reopened?

Yes, if bug resurfaces after fix ships. Reopened is a legitimate state signaling incomplete verification.

‍