QA Checklists

• · QA1 — Every async/data-driven surface is checked in all four states: empty, loading, error, success.
• · QA2 — Boundary values are tested explicitly: zero items, one item, maximum items, minimum/maximum input length, special characters (unicode, emoji, SQL-special chars for injection-adjacent robustness).
• · QA3 — Network conditions are tested: offline, slow 3G, request timeout, mid-request disconnect.
• · QA4 — Cross-browser/device coverage is weighted by real usage data (analytics), not exhaustive theoretical combinations.
• · QA5 — Destructive actions are tested for their guard behavior (confirmation, undo) and for the actual data-loss risk if bypassed.

• · Before calling a feature done, walk it through all four states deliberately — don't just test the happy path and assume the rest "probably works."
• · Test with an empty dataset, then one item, then a very large dataset — each surfaces different bugs (empty: missing guidance; one: pluralization bugs; many: performance/pagination bugs).
• · Paste an emoji, a very long string, and a string with <script> tags into every text input — cheap, catches a surprising number of bugs.
• · Turn off the network mid-action (submit a form, then disconnect) — does the app hang, error gracefully, or corrupt state?
• · Check analytics for the actual top 5 browser/device combinations before deciding what to manually test — don't guess.

• · Happy-path-only QA — testing only the ideal flow (data present, fast network, standard input), missing the states/edge cases where most real bugs hide.
• · Untested empty states — a list feature demoed and shipped with only pre-populated test data, the empty state never actually seen until a real new user hits it broken.
• · Guessed browser matrix — QA time spent on IE11-equivalent legacy combinations nobody uses per analytics, while the actual top mobile browser combination goes untested.
• · Unstructured exploratory testing — "click around for a bit" with no charter and no reproducible findings log, producing vague unreproducible bug reports.
• · No regression pass — each release re-breaks a previously-fixed bug because nothing checks for its return.

• [ ] Four states (empty/loading/error/success) verified on new async surfaces. (QA-E1)
• [ ] Boundary values tested (zero/one/max items, long/special-char input). (QA-E2)
• [ ] Degraded network conditions tested on the primary shipped flow. (QA-E3)
• [ ] Browser/device matrix derived from real analytics. (QA-E4)
• [ ] Regression check performed for previously-fixed critical/high bugs. (QA-E6)
• [ ] Exploratory sessions have a charter and reproducible findings log. (QA-E5)

• Ministry of Testing — community resources

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• webExploratory TestingJames Bach / Satisfice
• specMinistry of Testing — community resources