08 — Testing Checklist#

Verify expected functionality, quality, reliability, and release readiness using reproducible evidence.

Scope: Shared / cross-cutting. This file is one part of the 08_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, record N/A and 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-001 User stories, acceptance criteria, and definition of done are documented and testable.
TST-002 Critical user journeys, business rules, edge cases, and negative cases are identified and prioritized by risk.
TST-004 Requirements and recent defect fixes are mapped to test cases or coverage evidence.
TST-005 Test environments and integrations reflect production sufficiently to make results meaningful.
TST-035 Prioritize a risk-based test matrix across roles, tenants, locales, feature flags, and affected integrations.
TST-036 Specify observable expected results and data setup/cleanup steps for every critical scenario.
TST-037 Define objective coverage targets, ownership for gaps, and procedures for exploratory testing.
TST-038 Confirm production-like test data has been anonymized or generated synthetically.

Automated and component testing#

TST-006 Unit tests exercise core logic, input boundaries, error handling, and regressions.
TST-009 Automated tests run in CI on the relevant changes and fail the build on critical failures.
TST-010 Tests are deterministic: flaky cases are diagnosed, quarantined with owners, or fixed.
TST-011 Test fixtures and synthetic data avoid exposing real customer secrets or personal information.
TST-039 Mutation, property-based, or fuzz testing covers high-risk parsers and business rules where useful.
TST-040 CI records test artifacts, failure traces, and flaky-test trends for reproducible triage.
TST-042 Contracts are checked for changes to required fields, nullability, and backward compatibility.

Functional and end-to-end testing#

TST-012 Onboarding, authentication, account recovery, and sign-out work where applicable.
TST-013 Primary create/read/update/delete or transaction journeys work from start to finish.
TST-014 User permissions and role-specific workflows behave correctly for allowed and denied operations.
TST-016 Search, filters, sorting, pagination, exports, notifications, and background jobs work where present.
TST-017 External integrations are tested for success, rate limits, retries, and unavailable dependencies.
TST-018 Critical journeys are retested after fixes; regression suites pass.
TST-043 Critical flows work for first-time, returning, expired-session, and restricted users.
TST-044 Parallel actions, duplicate clicks, and lost responses cannot create inconsistent transactions.

Performance, resilience, and data integrity#

TST-024 Response time, throughput, and resource usage meet documented performance budgets under realistic load.
TST-049 Representative synthetic monitoring and load tests include slow networks and constrained mobile devices.

Release verification#

TST-030 Builds, linters, type checks, and all required automated tests pass for the release candidate.
TST-031 Known defects are triaged by severity; no unaccepted release-blocking defect remains.
TST-034 Test results and sign-off are linked to the specific build or commit being released.
TST-052 Release notes identify affected systems, user-facing changes, and backward-incompatible behaviors.
TST-053 Failure-injection or controlled dependency-outage testing has been completed for high-risk paths.
TST-054 Monitoring thresholds, escalation contacts, and post-release observation windows are documented.

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.

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 shared/cross-team controls 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 (or npx playwright test for E2E).
JavaScript: Jest + Playwright; for Jest-based suites, run npx jest --ci (or npx playwright test for 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 shared / cross-cutting 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.