Hostile Qa Tester

Hostile QA Tester

When to Use

Use this skill before a release, after a redesign, or when "it works for me" reports pile up. It role-plays the user your product team never invites: impatient, misclicking, tech-resistant, and determined to do the wrong thing. Output is a reproducible evidence log plus a severity-ranked bug report.

Do not use for: accessibility conformance audits (run a dedicated a11y pass); performance and load testing; security penetration testing (this is UI behavior, not exploitation); products with no UI to attack, such as pure APIs.

Procedure

1. Pick personas. Choose at most 3, extreme but believable: "Boss Bob" (clicks the first button, reads nothing), "Grandma Gina" (wrong taps, huge fonts, no keyboard), "Hacker Harry" (types quotes and scripts into every field and expects graceful errors).

2. Define scenarios from real user journeys. Per persona write 4–6 scenarios covering: the happy path with interruptions (back button, refresh mid-flow), empty states, extreme inputs (empty, 5000 chars, emoji, '; DROP TABLE), and cancellation paths (close a modal, sign out mid-checkout).

3. Execute with hostility rules: never follow an error message literally; retry the failed action twice; click adjacent elements; submit forms without filling them; use browser back/forward aggressively; resize the window mid-interaction; ignore onboarding hints on purpose. Record every step.

4. Capture evidence: screenshot before and after each suspicious action; note browser, OS, viewport, and the exact click coordinates; save console errors. Name files NN_persona_scenario_seq.png so a reviewer can replay your path.

5. Classify by severity:

| Severity | Meaning | Example | |---|---|---| | S1 Blocker | Data loss, dead end, core task impossible | Checkout button dead after retry | | S2 Major | Task possible only via a workaround | Error text is a raw stack trace | | S3 Minor | Works but confusing or ugly | Misaligned button, unclear label | | S4 Nit | Cosmetic, no task impact | Typos, inconsistent spacing |

6. Write the report: for each bug — title, persona + scenario, numbered steps to reproduce, expected vs actual, evidence file names, severity, suggested fix. Rank S1s first, then S2s; merge duplicates; end with "what survived" (flows that withstood hostility) so the team sees wins too.

Reference

| Hostile move | What it exposes | |---|---| | Submit empty form | Missing validation messages | | Back button mid-flow | Lost state, stale pages | | Refresh after step 2 of 5 | Non-idempotent steps | | Double-click submit | Double charges, duplicate records | | Paste 1000-char text | Broken truncation / overflow | | Append /admin to URL | Missing auth redirects |

Evidence housekeeping: one folder per session, files named 01_bob_checkout_doubleclick.png, 02_gina_filter_tap.png, ..., plus a plain-text steps.log listing each action with a timestamp.

Verification Checklist

• [ ] Ran at least 3