ZAKON-QA — Real-User Testing Standard (mandatory all agents) — 2026-06-05
ZAKON-QA: Real-User Testing Standard (MANDATORY for ALL agents)
The 7 hard rules
1. Test as a REAL USER, not the API
API-with-token tests give false green — they assert "feature exists in code", not "a user can do this". Drive the REAL UI with REAL clicks (Playwright/browser). Use reliable auth (API-login + session-cookie injection, the real-demo-smoke.spec.ts pattern) — flaky UI-form login silently lands on /login and poisons every check. Log in as the actual product user.
2. FULL CRUD round-trips, not "page renders"
For EVERY entity (invoices, expenses, contacts, articles, …): create → it MUST appear in the list → open its detail → edit → reuse it. "No error on click" ≠ "works". Verify the OUTCOME: the created item actually appears, the edited value actually persists, the deleted item actually disappears. A test that clicks a button and only checks "no exception" is NOT a test.
3. Verify by LIVE OUTCOME — never by "build SUCCESS" or git-sha label
A green build with the correct commit label CAN ship a STALE bundle (dead-code edit, Docker/BuildKit layer cache). NEVER claim a fix is live because the build passed or the Cloud Run revision is labeled with the new sha. Confirm on the LIVE url with a screenshot you ACTUALLY LOOK AT (e.g. "PDV shows €30,50, not €NaN"). Assert the page RENDERED a known element BEFORE asserting the fix — a blank page / login redirect falsely passes "no NaN on page".
4. REJECT your own false positives — and NEVER fabricate
When something looks like a bug, verify the real affordance/data before reporting: wrong test account (e.g. logged in as a different org with empty data), wrong selector, guessed-wrong URL, checking the wrong field/page, already-sorted data. If your control case also "fails", your TEST is broken, not the app. A regression test that PASSES by SKIPPING its assertion ("could not create draft — skipping") is NOT a pass. Never invent a bug to look busy; reporting a false bug is a worse failure than finding none.
5. CONSISTENCY / completeness audit
Systematically check that each entity has: list + detail view + create + edit + sort + REACHABLE navigation (row/name click → detail). Inconsistency between entities (invoices have detail, contacts don't) is exactly where real bugs hide. Audit the route tree + the actual nav affordances (Link href / onClick), not just "does the list render".
6. Don't rationalize broken UX as "intentional stub"
If a real user hits an error toast / 403 / 501 / dead button, it IS a bug — regardless of backend intent. Either make the feature work or degrade it GRACEFULLY (clear "not available" notice, hidden/disabled button + upsell). A 501 that makes the client throw an error toast is a bug even if storage is "intentionally" unconfigured.
7. Capture EVERYTHING + mobile
On every page: capture console errors, all HTTP ≥400, NaN/undefined/raw-i18n-key leaks, horizontal overflow at 390px mobile. Screenshot each state and LOOK at it.
Process when a bug is found
Reproduce (live, real clicks) → root-cause (edit the LIVE/compiled file, not dead code) → fix → CI green (required gates) → deploy → re-verify the OUTCOME on the live surface with a screenshot → only then "done". Per [[feedback_verify_by_live_outcome_not_green_build_2026-06-04]].
Reusable harness
apps/e2e/tests/regression-102887.spec.ts + _hunt*.mjs cookie-auth pattern in the Bilko repo are the reference implementation. The webapp-testing, deploy-verify, mobile-uat, and uat-browser skills MUST follow these 7 rules.
No comments to display
No comments to display