11 — Testing Checklist#
Verify expected functionality, quality, reliability, and release readiness using reproducible evidence.
Scope: Frontend-specific. This file is one part of the 11_Testing.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.
Review details#
- Project / product:
- Release / version / environment:
- Scope and applicable jurisdictions / markets:
- Reviewer / owner:
- Review date:
- Decision: Pending / Approved / Approved with documented exceptions / Blocked
How to use#
- Copy this template into each project's review records; keep the shared repository template unchecked.
- Check
[x]only after verifying the item with evidence. For any inapplicable item, recordN/Aand the reason in the project's own review notes or issue tracker using its checklist ID; do not mark it as passed. - Record evidence links or artifact references by checklist ID. Open an issue for every failed item, assign an owner and due date, and retest after remediation.
- Apply the release gate below. These checklists guide review; they do not replace qualified specialist review when required.
Requirements and test strategy#
- TST-003 A test plan identifies environments, devices, browsers, roles, test data, owners, and exit criteria.
Functional and end-to-end testing#
- TST-045 Deep links, refreshes, browser navigation, and interrupted workflows preserve valid state.
- TST-015 Form validation, empty states, duplicate submissions, timeout states, and helpful errors are tested.
Experience, accessibility, and compatibility#
- TST-020 Supported browsers, operating systems, and input methods have been checked.
- TST-021 Keyboard navigation, focus visibility/order, labels, contrast, and screen-reader paths are tested against the project's accessibility target.
- TST-023 Localization, formats, time zones, Unicode, and right-to-left layouts are tested where applicable.
- TST-046 Accessibility tests cover zoom/reflow, text resizing, error identification, and visible focus.
- TST-047 Screen-reader and keyboard-only smoke tests are performed by a human on critical journeys; automated scans are not the sole evidence.
- TST-048 Touch interactions, tap-target sizes, orientation changes, and reduced-motion preferences are checked where applicable.
- TST-019 Layouts and interactions work on supported mobile, tablet, and desktop viewports.
- TST-022 Loading, success, error, and offline/degraded states are understandable to users.
Automated and component testing#
- TST-041 Component tests exercise loading, state transitions, error boundaries, and event handling.
Frontend Checks#
Apply to browser-based, mobile-web, embedded, or other user-facing interfaces. Record N/A with reasons for headless services.
Reference basis: OWASP Application Security Verification Standard (ASVS) 5.0; W3C — WCAG 2.2 Quick Reference; web.dev — Core Web Vitals.
- TST-068 Verify initial rendering and hydration on representative pages, including direct navigation and refresh.
- TST-069 Test navigation, back/forward history, route guards, and not-found views for valid and invalid URLs.
- TST-070 Check forms for client/server validation agreement, keyboard submission, error summaries, and duplicate-submit protection.
- TST-071 Check loading, success, empty, offline, timeout, and partial-data states with meaningful recovery actions.
- TST-072 Verify keyboard order, visible focus, labels, semantic landmarks, accessible names, and screen-reader announcements.
- TST-073 Test contrast, text resizing, 200% zoom, responsive reflow, touch targets, and reduced-motion behavior against the chosen WCAG target.
- TST-074 Test images, fonts, media, and responsive layout across defined browser/device support.
- TST-075 Inspect console errors, network failures, unhandled promises, and hydration mismatches in representative sessions.
- TST-076 Measure real-user or representative LCP, INP, and CLS against documented performance targets.
- TST-077 Ensure frontend state does not expose other users' records after account switching, back navigation, or cache restoration.
- TST-078 Check long content, translated text, right-to-left layouts, time zones, date/currency formats, and assistive technology where relevant.
- TST-079 Verify user-facing analytics, alerts, and error handling do not disclose personal information or secrets.
Release gate#
- All applicable high-priority checks above pass, or an authorized decision-maker has explicitly accepted and documented each residual risk.
- Failed items have tracked remediation, owners, and deadlines; material blockers remain blocked until resolved.
- Evidence links and the reviewer, review date, and final decision are recorded.
Domain-specific approval rule: Do not approve when critical flows, data integrity, access-control tests, or required recovery checks fail.
Trusted references and scope#
The checks above are adapted into practical verification questions from these authoritative publications (not copied as standards text). Verify current versions and the project's scope before sign-off.
- OWASP Application Security Verification Standard (ASVS) 5.0
- OWASP API Security Top 10 (2023)
- OpenAPI Specification 3.2.1
- IETF RFC 9457 — Problem Details for HTTP APIs
- W3C — WCAG 2.2 Quick Reference
- web.dev — Core Web Vitals
Guidance is risk-based and project-specific; sources do not replace testing or specialist review.
Source review date: 2026-11-12.
Suggested testing tools#
Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.
- Test focus: unit/integration, API contract, end-to-end, and regression test runs; include browser and client behavior where applicable.
- Cross-stack: Playwright + Pact.
- Python: pytest + coverage.py; for pytest-based suites, run
python -m pytest -q. - TypeScript: Vitest + Playwright; for Vitest-based suites, run
npx vitest run(ornpx playwright testfor E2E). - JavaScript: Jest + Playwright; for Jest-based suites, run
npx jest --ci(ornpx playwright testfor E2E). - Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.
Suggested AI skills for verification#
These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.
property-based-testing— Explore invariants and adversarial edge cases (trailofbits/skills, 8,150 repo stars).e2e-testing-patterns— Review critical end-to-end coverage (wshobson/agents, 42,437 repo stars).verification-before-completion— Require reproducible evidence before approval (obra/superpowers, 316,578 repo stars).
How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.
Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.
Important warning: reference only#
⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.
Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.