Use this flow to decide what needs to block a release, what can be scheduled, and what needs better evidence before engineering spends time on it.
1. Confirm the report is complete
- Clear title and product area
- Steps to reproduce or a reason reproduction is not yet possible
- Expected behavior and actual behavior
- Environment, account, browser, device, and app version
- Screenshot, replay, logs, or support ticket evidence
2. Classify severity
Severity should describe the damage the bug can cause. It should not describe who is available to fix it.
- Critical: data loss, security risk, checkout failure, widespread outage, or legal exposure.
- High: core workflow blocked for an important user segment.
- Medium: workflow degraded, workaround exists, or limited audience affected.
- Low: cosmetic issue, rare edge case, or no meaningful user impact.
3. Assign priority
Priority should combine severity with timing, customer importance, roadmap commitments, and release risk.
4. Route with context
Send the issue to the owning team with the evidence, suspected component, confidence level, and customer communication notes.
pagemarkr angle: Triage improves when severity, priority, owner, and evidence are captured in the same workflow.
Next step
Request access to pagemarkr if your current QA triage process depends on scattered docs, screenshots, and Slack threads.