Bug intake triage template for mobile QA teams

A useful bug intake triage template records both what the tester observed and what the team decides to do next. For mobile QA, include the affected build, device and starting state, then record a decision, an owner and the evidence or retest needed to move the issue forward. A completed intake form should lead to a clear next action, even when the problem is intermittent.

Use the worksheet below in an issue description or a shared triage document. It is a suggested working format, not a requirement to add every field to the tester's report form.

What belongs in the bug intake triage template?

Separate the original observation from the triage assessment. The tester knows what happened on their device; the team decides whether it matches a known defect, what investigation is justified and where it belongs in the release plan.

BUG INTAKE
Original report / evidence link:
Summary: [action or state] causes [observable failure]
App version and build:
Platform, device and OS:
Starting state: [account type, permissions, relevant data]
Steps or last known actions:
Expected result:
Actual result:
Frequency: [observed attempts; unknown is valid]
Impact and workaround:

TRIAGE ASSESSMENT
Reviewed by / date:
Reproduction: [confirmed / intermittent / not reproduced / not tried]
Test conditions and result:
Known issue / possible duplicate:
Severity and reason:
Priority and release impact:
Decision: [investigate / needs information / duplicate / defer / close]
Decision reason:
Owner of the next action:
Next action and review date or trigger:
Canonical issue: [if different from the original report]
Verification: [scenario and environment to retest]
Reporter update:

Use “unknown” where evidence is missing. An invented build number or assumed reproduction rate is more misleading than an explicit gap. Link to restricted evidence where appropriate and keep passwords, tokens and real customer records out of shared descriptions.

If the original report needs work, use the good bug report guide for the tester-facing fields. The triage section above is for the person reviewing the queue.

How do you choose the next action?

Check urgent impact first. If the observation suggests an active security, privacy or data-loss problem, use your team's escalation route while preserving the evidence. Do not wait for every template field before notifying the responsible person.

For the remaining queue, use these suggested decisions:

Decision	Use it when	Record before moving on
Investigate	There is a credible defect or enough potential impact to justify investigation	An owner, the next check and the affected release
Needs information	A specific missing fact prevents a useful next step	One focused question, who follows up and when to review
Duplicate	Evidence supports linking this observation to an existing issue	The canonical issue and any new build, device or symptom details
Defer	The team accepts the issue but is not scheduling it now	The reason and a date or condition for reconsideration
Close	The observation is explained, outside scope or belongs in another workflow	The explanation and a route for relevant new evidence

Do not confuse accepting an issue for investigation with promising a fix in the next build. Similarly, “needs information” is a task someone owns, not a place to leave an issue indefinitely.

These decisions can fit your existing tracker. For example, Linear's Triage documentation describes accepting, declining, marking duplicates and snoozing, with comments for requesting more information. Map the worksheet to the states your team uses rather than creating a second competing workflow.

Which mobile details change the investigation?

Record the conditions that distinguish this report from another report of the same symptom:

• Build: version and build number, plus the distribution channel if relevant.
• Installation history: fresh install or upgrade, and the previous version if known.
• App state: newly opened, resumed from the background or reached through a deep link.
• Account and data: test account role, relevant saved data and feature access.
• Device conditions: OS version, permissions, network changes or accessibility settings when they affect the failing flow.

Ask for the missing condition most likely to change the next test. If a photo upload stalls after the app resumes, “did the phone switch from Wi-Fi to mobile data?” is more actionable than “please send more details”. Do not require every tester to supply a full diagnostic archive for a visible layout defect.

What if you cannot reproduce the bug?

Record what you tried before deciding what the failed attempt means. “Could not reproduce” on a fresh install does not rule out a problem reported after an upgrade. A different account role or permission state can also change the result.

Here is a fictional triage assessment for a mobile field-service app:

Observation: Job photos remain queued after returning to the app.
Reported build: 4.2 (318), Android, after upgrading from build 314.
Evidence: Recording shows the queued indicator after tapping Retry.

Reproduction: Not reproduced on a fresh install of build 318.
Missing condition: Whether the network changed while backgrounded.
Decision: Investigate; the failed fresh-install test is inconclusive.
Owner: Mobile engineer on the upload feature.
Next action: Test the upgrade path and background/network transition.
Review: Before the next release-candidate decision.
Reporter update: Ask about the network change; retain the recording.
Verification: Retry the affected queued upload and confirm completion.

The example does not establish a root cause. It turns uncertainty into a testable next action. If the issue remains unconfirmed, keep that confidence level visible rather than silently changing the report to “fixed” or “not a bug”.

How should severity and priority differ?

Use severity to describe the consequence when the failure occurs. Use priority to decide how urgently the team should act, considering the affected audience, workaround and release purpose. Atlassian explains this distinction in its severity and priority guide. Agree your own levels; that incident-management guide does not define a universal mobile QA scale.

For example, a cosmetic misalignment and a button hidden behind the keyboard may look similar in screenshots. If the hidden button prevents completing the only sign-in route, the functional impact is different. Describe the blocked task before choosing a label.

Record why the priority follows from the evidence. “Investigate before release: upgraded accounts may be unable to submit completed jobs” gives a reviewer more to assess than “P1”. Do not infer how many users are affected from one tester's reproduction count.

How do you handle duplicates without losing evidence?

Compare the failing action, starting state, affected builds and observed result before treating two reports as the same defect. A matching screenshot is a clue, not proof of a shared cause.

When you link a duplicate, preserve anything the canonical issue lacks: a new device combination, an upgrade path, a clearer reproduction sequence or evidence that the failure persists in a later build. Keep the original report reference so the team can trace the observation and update the reporter.

Tell the reporter which issue now owns the investigation. If their conditions differ enough to suggest a separate defect, keep the reports related while that distinction is investigated.

How do you use the template in the next QA round?

Choose one person to own the intake queue during the round. Review a few existing reports together to agree what each decision means, then use the template on new arrivals. At the next release review, check that investigated issues have owners, information requests have follow-ups and deferred issues have reasons.

For structured manual intake, the beta issue template helps testers prepare the build, steps and evidence. The mobile beta feedback guide covers the wider cohort workflow. If gathering reports is the bottleneck, explore BugScreen's mobile QA reporting workflow or create a workspace to try it with your team. Keep the triage decisions in the place your team already uses to assign and review engineering work.