Bug Reporting
Severity and priority scales, lifecycle, report templates and triage process for the iSpeaker Live Testing Phase.
On this page
Overview
A bug report is only as valuable as the information it carries. This page documents how bugs are classified, recorded, triaged, and resolved during the Testing Phase of iSpeaker Live MVP 1.0. Every tester is expected to follow the conventions here so that engineering can reproduce, fix, and verify defects without back-and-forth delays.
TC-PAY-002) in the report so the link is preserved.
Severity scale
Severity describes the technical impact of the defect — how broken something is, regardless of how often it happens. It is assigned by QA at report time and revised during triage if needed.
S1 — Critical
Blocks a core flow with no workaround. Data loss, security exposure, payment failure, app crash on launch, complete outage of a primary feature.
SLA: Acknowledged within 1 hour, fix targeted same business day.
S2 — High
A major function is broken but a workaround exists, or a non-payment data corruption occurs. Significant degraded UX.
SLA: Acknowledged same day, fix within 2 business days.
S3 — Medium
A secondary feature is broken or behaves incorrectly. Most users can still use the platform normally.
SLA: Triaged within 2 days, fix within the current sprint.
S4 — Low
Cosmetic issues, minor copy issues, off-by-one alignment, edge-case UI defects.
SLA: Backlogged; fix when convenient.
Priority scale
Priority describes the business urgency — how soon a fix should ship, regardless of how broken the thing is. Assigned by the product owner or engineering lead during triage.
| Label | Meaning | Typical targets |
|---|---|---|
| P0 | Drop everything and fix now. Production-blocker or release-blocker. | Hotfix in hours. |
| P1 | Must be fixed before the release cut. | Current sprint. |
| P2 | Should be fixed soon; not a release blocker. | Next 1-2 sprints. |
| P3 | Nice to fix. | Backlog. |
Severity × Priority matrix
This is the suggested starting mapping. Triage can override it with documented reasons (for example, a cosmetic bug on the landing page may become P1 if it harms conversion).
| S1 | S2 | S3 | S4 | |
|---|---|---|---|---|
| Affects all users | P0 | P1 | P2 | P2 |
| Affects many users | P0 | P1 | P2 | P3 |
| Affects few users | P1 | P2 | P3 | P3 |
| Edge case | P2 | P3 | P3 | P3 |
Bug lifecycle
A bug moves through a fixed set of states. Only specific roles can perform each transition.
New
Tester files the bug using the template below. Initial severity and steps to reproduce are required.
Triaged
QA lead validates reproducibility and confirms severity. Product assigns priority. The bug is routed to a team (frontend / backend / mobile).
In Progress
Engineer takes the bug, attaches a branch, and updates the report with a root-cause hypothesis.
Code Review
Pull request opened, linked to the bug ID, and reviewed by at least one peer.
Merged / On Staging
Merged into the release branch and deployed to staging. Bug status changes to "Ready for QA".
Verified
Original tester (or another QA) re-runs the failing steps on staging and either passes the bug or re-opens it.
Closed
Bug is closed after verification. If it returns later, a new bug is filed referencing the closed one.
Other terminal states: Won't Fix (intentional behavior), Duplicate (linked to original), Cannot Reproduce (re-open if it happens again with more data), Deferred (moved to a later release).
Bug report template
Copy this template into your issue tracker. Mandatory fields are marked with *.
Title*: [Module] One-line summary in present tense
Bug ID: (auto-generated)
Reporter*: Your name
Date*: YYYY-MM-DD
Build*: app vX.Y.Z (commit / build number)
Environment*: dev | staging | production
Platform*: Web (Chrome 130) | Android 14 (Pixel 7) | iOS 18 (iPhone 14)
Language*: AR | EN
Severity*: S1 | S2 | S3 | S4
Priority: (filled by triage)
Related test case: TC-XXX-NNN (if any)
Preconditions:
- Account: tester01@example.com (Student role)
- Wallet balance: 100 SAR
- Anything else needed to reach the bug
Steps to reproduce*:
1. ...
2. ...
3. ...
Expected result*:
What should happen.
Actual result*:
What actually happens. Include exact error messages.
Frequency*: Always | Most of the time | Sometimes | Once
Workaround:
None | Describe a temporary way around it.
Attachments*:
- Screenshot or screen recording
- Console / network log if relevant
- Backend log timestamp if relevant
Additional notes:
Hypotheses, regression info, related bug IDs.Good vs. bad reports
Bad report
Title: Doesn't work
Description: I tried to register and it failed. Please fix.
This report can't be acted on: no environment, no steps, no error, no build.
Good report
Title: [Auth] Register fails with "phone has already been taken" when phone is new
Description: Build v1.0.7 on Android 14. Used phone +966500001234 (never registered). Got 422 with field phone. Reproduced 5/5 times. Web works with same number.
Specific, reproducible, and linkable to a test case.
Example bugs
- Environment
- Staging · Web Chrome 130 · EN
- Build
- web v1.0.7
- Related case
TC-PAY-001,TC-PAY-002- Steps
-
- Start a 100 SAR top-up via PayPal.
- Cancel inside PayPal.
- Immediately retry with the same 100 SAR amount and complete payment.
- Expected
- Balance increases by 100 SAR; one completed transaction; the cancelled one stays in
failed. - Actual
- Balance increases by 200 SAR; both transactions show
completed. - Frequency
- 3/3 reproductions.
- Hypothesis
- Webhook for cancel arrives after the second flow completes and is processed against the same wallet row without re-checking transaction state.
- Environment
- Staging · Android 14 (Pixel 7) · AR
- Build
- android v1.0.7 (build 218)
- Related case
TC-FEED-004- Steps
-
- Open a post with 5 comments.
- Add a reply to the top comment.
- Delete the same reply.
- Pull-to-refresh the post.
- Expected
- Comment count returns to 5.
- Actual
- Comment count shows 6 until the next app restart.
- Frequency
- Always.
- Environment
- Staging · Android 13 (Samsung A12, 720×1600) · AR
- Build
- android v1.0.7
- Related case
TC-LR-005,TC-I18N-002- Steps
-
- Open a running live room in Arabic.
- Look at the top bar of the room.
- Expected
- Counter and end-session button do not overlap; both fully tappable.
- Actual
- End-session button covers the participants counter on screens narrower than 360 dp.
Triage process
Triage happens daily during the Testing Phase. The standing meeting (15-30 min) is attended by the QA Lead, Product Owner, and Tech Leads (web, mobile, backend).
- New bugs queue: All bugs in
Neware walked through. - Reproducibility check: QA confirms the report has enough info; otherwise the bug is moved to
Needs Infoand assigned back to the reporter. - Severity validation: QA lead adjusts severity if needed.
- Priority assignment: Product owner picks priority using the matrix.
- Routing: Tech lead assigns to a team.
- Release-blocker review: Any open S1/P0 is reviewed at the end and blocks release until resolved.
Quality metrics tracked during testing
Tooling & channels
- Issue tracker — All bugs live here with their IDs; this is the single source of truth.
- Slack #qa-bugs — New S1/P0 bugs are announced automatically. Engineers acknowledge in the thread.
- Screen capture — Use built-in OS recorders for short clips; long clips compressed to MP4 ≤ 30 MB before uploading.
- Console / network captures — Web uses Chrome DevTools HAR exports; mobile uses Logcat/Console attached to the bug.
- Crash reporting — Crashlytics / Sentry IDs included where applicable.