Engineering & performance / DIJION
A quality test matrix for mobile apps and games
Connect critical tasks with device, connectivity, data and interruption conditions to prepare a practical release check.
“It works on a phone” is not a complete test result. Which phone, task, connection and data were involved? A small team may not cover every possibility, but it can select critical flows and risks explicitly. This guide does not present measurements for a particular product or guarantee flawless operation.
Select critical tasks first
For an app, creating a record or retrieving information may be critical. For a game, starting play, using the control and returning after an interruption may matter most. Prioritize flows that block use, lose data or produce incorrect outcomes before listing visual details.
Write the starting condition and observable result. Replace “The form works” with “Valid input produces confirmation; failed submission preserves the text.” Controlled test records can verify this without involving real personal information.
Build the matrix around meaningful conditions
Scroll the table horizontally to see all columns.
| Dimension | Example conditions | Risk |
|---|---|---|
| Device and screen | Small/large screen; supported lower-capacity device | Overflow, clipping or slow response |
| Language and text | Turkish/English; long content; larger system text | Missing labels or actions |
| Connection | Normal, slow, lost and restored | Endless loading or duplicate operations |
| Data | First use, existing content, empty result, invalid input | Incorrect empty state or lost data |
| Interruption | Backgrounding, screen lock and return | Lost progress or unsafe resume |
| Accessibility | Screen reader, cues beyond color, reduced motion | Unclear states or unreachable actions |
Multiplying every condition can make the matrix unmanageable. Begin with high-risk pairs: small screens and long translations, submission and connection loss, gameplay and backgrounding. Expand coverage according to actual product use.
Write repeatable scenario cards
Scroll the table horizontally to see all columns.
| Field | Example |
|---|---|
| Identifier | CONTACT-RETRY-01 |
| Precondition | Completed form; controlled test service |
| Steps | Submit, disconnect, observe and reconnect |
| Expected | Input remains, outcome is truthful and no duplicate submission occurs |
| Evidence | Recording or message; version and device |
| Outcome | Passed / failed / not tested |
Keep Not tested as a real outcome. Missing hardware or an unavailable service is not a pass. Use test data in reports and check recordings for exposed account information.
Match the measurement to the problem
Startup delay, jank, crashes and long-running operations are different issues. Establish repeatable conditions on the same device and scenario. A single quick run cannot represent every user. Platform tools such as Android vitals can provide separate signals from released application usage.
A Lighthouse score measures a website, not native application performance. Laboratory and real-user measurements are also separate evidence. Do not present web metrics such as INP, LCP or CLS as a verdict on a mobile game’s frame timing. Record the platform, conditions and limits of the measurement.
Separate impact from reproducibility
Rare data loss may still have high severity. Frequent minor misalignment may be less urgent. Record impact separately from reproduction steps so that frequency and consequences are not confused.
- P0: A verified critical blocker or serious data loss.
- P1: A main flow becomes difficult and recovery is poor.
- P2: A usability issue with an alternative path.
- P3: A lower-impact improvement for later work.
Connect the release decision to evidence
Review critical scenario results, open issues, untested conditions and the recovery option together. After a fix, recheck the affected flow and neighboring behavior. The purpose is meaningful evidence for changing risks, rather than mechanically repeating the same long list.