Quality Assurance Standard¶
This standard states general QA expectations that apply to any product or component in any venture, at a level of rigor proportional to the product's risk. It does not mandate a specific testing tool or process — ventures and products choose their own methods within this standard.
Test plans required before release-ready¶
A product is not considered release-ready until it has a test plan covering, at minimum, its stated acceptance criteria (see docs/standards/product-specification-standard.md). The test plan does not need to be a separate formal document for a small product — it can be embedded in the specification — but it must exist somewhere and be identifiable.
Acceptance criteria must be testable¶
Acceptance criteria stated in a product or component specification must be written so that a specific check (manual or automated) can determine pass or fail. "The app should feel fast" is not testable; "the app's pantry list loads in under 2 seconds on a mid-range device on a typical home connection" is testable, provided a "typical" baseline is defined somewhere the check can reference.
Defects tracked¶
Known defects are recorded somewhere durable (an issue tracker, a defects log in the product's own documentation area, or equivalent) rather than kept only in memory or informal chat. A defect that is known and unaddressed should not be silently omitted from what a customer-facing claim implies about the product's behavior — see commercial-claims-standard.md.
No fabricated test results¶
Test results — whether produced by a human or an AI agent working in this repository — must reflect what was actually observed. Do not record a test as "passed" without having actually run it, and do not describe untested behavior as verified. This applies with particular force to AI-assisted work: an AI agent must not report tests as executed or passing unless it actually executed them and observed the result.
Proportional rigor¶
QA rigor should be proportional to the product's risk:
- A product handling no personal data and offering only convenience (e.g., a static reference workbook) needs lighter QA than one handling personal data or making claims a customer will rely on for a real-world decision.
- A product's specification should note, even briefly, why the chosen level of QA rigor is appropriate to its risk profile, so the choice is a documented decision rather than an unstated default.
Relationship to venture-specific QA practices¶
A venture may define more specific QA practices (e.g., a mobile app's device-testing matrix, a workbook's formula-validation checklist) under its own ventures/<slug>/docs/standards/ area. Those practices must satisfy, not weaken, this baseline.