Bug reports — file it like a professional
Structured defect reports on the apps under test: reviewed by mentors, valid bugs earn XP.
- Learn the industry-standard bug report: reproducible by anyone, every time
- Valid, high-quality reports earn XP — quality is scored, not volume
- A comment thread with your reviewer on every bug, plus a full fix/retest lifecycle
The miatz bug-report standard
A great report is reproducible by anyone: a precise title, numbered steps to reproduce, expected vs actual result, a correct severity (impact) and priority (urgency), the environment, and a screenshot or recording as evidence. The form requires every field — that's deliberate. Evidence uploads go to private storage; only you and reviewers can see them.
One distinction to keep straight: severity is how bad the impact is (low/cosmetic → critical/crash, data loss, security); priority is how urgently it should be fixed (P3 → P0). They're independent judgments.
What happens after you submit
Your report lands in the review queue as pending. A mentor or admin triages it to valid, invalid or duplicate, usually with written feedback. Valid reports earn XP — sized by quality, which is why signal over volume is the house rule. Filing a bug also bumps your streak.
Every bug has a comment thread: reviewers can ask clarifying questions, and you'll see a "reviewer replied" marker on your list when the last word is theirs.
The fix-and-retest loop
Bugs also carry a resolution lifecycle — open → in progress → fixed (or won't fix / closed). When a bug you filed is marked fixed, retest it: you can mark it verified fixed, or reopen it if the fix doesn't hold. Closing your own loop is exactly what professional QA looks like.
Not for miatz problems
Bug Reports covers the apps under test. If something is wrong with miatz itself — the platform you're learning on — raise a support ticket from the Support page instead, so the right team sees it.
The journey, step by step
| Step | What you do | What you get |
|---|---|---|
| Find a defect | Test one of the Applications to Test and catch something broken | A candidate bug worth writing up |
| File the report | Fill every field: steps, expected vs actual, severity, priority, environment, evidence | A reproducible report lands in the review queue |
| Mentor review | A mentor or admin triages your report | Marked valid, invalid or duplicate — with feedback either way |
| Earn XP | Your report is judged valid | XP awarded based on report quality |
| Follow the fix | Track resolution (open → in progress → fixed) and discuss in the thread | When it's fixed, retest and mark it verified fixed — or reopen it |
Frequently asked
What happens after I submit a bug?
It enters review as pending. A mentor or admin marks it valid, invalid or duplicate, usually with feedback. Valid reports earn XP, and a comment thread on the bug lets you discuss it with the reviewer.
What's the difference between severity and priority?
Severity is impact — how badly the feature is broken (low/cosmetic up to critical/crash, data loss or security). Priority is urgency — how soon it should be fixed (P3 low up to P0 urgent). A cosmetic typo on the homepage can be low severity but high priority.
The app says my bug is fixed — what do I do?
Retest it. From the bug's page you can mark it verified fixed if the fix holds, or reopen it if it doesn't — that verification loop is part of the practice.
Is this where I report problems with miatz itself?
No. Bug Reports is for defects you find in the practice apps under test. For a problem with the miatz platform, raise a support ticket instead — see "Raise a ticket" in Help.
Related guides
QA real, live products — then study their architecture and code once you unlock the advanced tabs.
ReadWhen to use the AI Tutor, the community, or a ticket.
ReadLook at a real screen and reconstruct the spec that produced it — graded instantly by AI.
ReadHow the XP and spoken-skills leaderboards rank you, and what the dashboard league resets.
Read