awesomechecklists
llms.txtGitHub ↗
/

26 — Testing Checklist#

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

Scope: Backend / API-specific. This file is one part of the 26_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#

  1. Copy this template into each project's review records; keep the shared repository template unchecked.
  2. 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.
  3. 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.
  4. Apply the release gate below. These checklists guide review; they do not replace qualified specialist review when required.

Automated and component testing#

  • TST-007 Integration tests verify database, queue, cache, and third-party interactions, including failures.
  • TST-008 API/contract tests verify schemas, validation, error codes, versioning, and compatibility.

Performance, resilience, and data integrity#

  • TST-025 Peak-load, concurrency, and rate-limit scenarios have measurable results where relevant.
  • TST-027 Database migrations, rollback plans, and data integrity constraints are tested on representative data.
  • TST-029 Telemetry identifies critical errors, latency, and failures without disclosing sensitive data.
  • TST-050 Reliability checks verify concurrency safeguards, queue replays, eventual consistency, and duplicate delivery where applicable.
  • TST-026 Timeouts, retries, circuit breakers, idempotency, and graceful degradation are verified.
  • TST-028 Backup/restore or disaster recovery procedures are exercised to the agreed recovery targets.
  • TST-051 Recovery tests verify that failed or partially completed writes do not corrupt data or leak sensitive state.

Release verification#

  • TST-032 Deployment, configuration, feature flags, and rollback/roll-forward steps are rehearsed.
  • TST-033 Staging smoke tests pass and post-deployment production smoke checks are assigned.

API Checks#

Apply to API endpoints, client integrations, webhooks, or data feeds present in the project. Record N/A with reasons if none exist.

Reference basis: OWASP Application Security Verification Standard (ASVS) 5.0; OWASP API Security Top 10 (2023); OpenAPI Specification 3.2.1.

  • TST-055 Validate each documented endpoint, method, status code, required field, optional field, and example against the running API.
  • TST-056 Run positive and negative tests for authentication, expired credentials, user roles, cross-user objects, and cross-tenant boundaries.
  • TST-057 Check object-level and property-level authorization on read, update, list, and bulk endpoints.
  • TST-058 Test malformed JSON, invalid content types, missing/null/oversized values, Unicode, and unexpected fields.
  • TST-059 Confirm pagination, filtering, sorting, cursor handling, and empty/result-limit behavior under data changes.
  • TST-060 Exercise retry, timeout, cancellation, idempotency, and concurrency behavior for state-changing requests.
  • TST-061 Assert stable, actionable 4xx/5xx responses and structured error bodies if the project uses RFC 9457.
  • TST-062 Verify versioning and consumer compatibility, including deprecation notices and contract-diff checks.
  • TST-063 Check rate-limit and quota enforcement, appropriate 429 behavior, and documented retry guidance.
  • TST-064 Test batch jobs, async requests, webhooks/callbacks, and signature verification where applicable.
  • TST-065 Confirm error and debug responses never return credentials, internal stack traces, or unauthorized records.
  • TST-066 Measure high-traffic endpoint latency/throughput and recovery from upstream failures using realistic workloads.
  • TST-067 Verify API documentation, examples, and supported SDKs remain in sync with deployed behavior.

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 API and service 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 (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.

How to check: In a project-specific copy, have the agent audit the backend / API 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.

Reference, not a certification. Check applicability, verify important claims against current primary sources, and seek expert review where necessary. Suggest an improvement.