qa-goggles

name	qa-goggles
description	Systematic test case discovery procedure for finding coverage gaps. Use during QA phase or when writing tests to identify missing boundary cases, negative paths, and production scenario risks. Keywords: test coverage, missing tests, edge cases, boundary analysis, negative paths, production scenarios, equivalence partitioning.

QA Goggles — Systematic Test Case Discovery

A 5-step procedure for finding what tests are missing. Apply this after writing an initial test suite, or during Phase 6 QA review.

---

Step 1: Acceptance Criteria Mapping

Goal: ensure every acceptance criterion has at least one test.

For each acceptance criterion in the task spec:

1. Name the criterion explicitly
2. Find the test(s) that verify it
3. If no test exists → gap (blocking)
4. If only happy-path exists → partial gap (high)

Template:

Criterion: [text]
Tests found: [test_names or NONE]
Status: ✅ covered / ⚠️ partial / ❌ missing

---

Step 2: Boundary Value Analysis

Goal: ensure input boundaries are explicitly tested, not just mid-range values.

For every input parameter in the component under test:

• What is the minimum valid value? → test it
• What is the maximum valid value? → test it
• What is just below the minimum (invalid)? → test it
• What is just above the maximum (invalid)? → test it
• What is zero / empty / null? → test it

Example:

Input: page_size (int, 1–100 inclusive)
Boundaries to test:
  - page_size=1    → minimum valid
  - page_size=100  → maximum valid
  - page_size=0    → invalid (just below min)
  - page_size=101  → invalid (just above max)
  - page_size=-1   → invalid (negative)

---

Step 3: Equivalence Partitioning

Goal: ensure all distinct input classes are tested, not just one representative.

Group all possible inputs into classes where the system behaves identically:

• Valid class: inputs the system should process normally
• Invalid class: inputs the system should reject with an error
• Edge class: inputs at the boundary of valid/invalid
• Special class: empty, null, zero-length, all-same-value, etc.

At least one test per class. Do not write five tests for five valid values when one representative covers the class.

---

Step 4: Production Scenario Simulation

Goal: find tests that would catch failures at 2am in production.

Ask yourself for each component:

• What happens if the external dependency (DB, API, queue) is unreachable?
• What happens if the input data is malformed but syntactically valid?
• What happens if the input is unusually large (N=0, N=1, N=1,000,000)?
• What happens under a race condition or concurrent access?
• What happens if a config value is missing or set to an extreme value?
• What happens if the same operation is called twice (idempotency)?
• What happens if the operation is interrupted halfway through?

For each scenario identified: does a test exist? If not → gap.

---

Step 5: Negative Path Audit

Goal: ensure every unhappy path in the source code is exercised by a test.

Scan the implementation files for:

• Every raise statement → is there a test that triggers it?
• Every except clause → is there a test that exercises it?
• Every return None or Optional[X] return → is there a test that receives None?
• Every if condition: return early → is there a test where condition is true?
• Every else branch that handles an error or fallback → is there a test that enters it?

Template:

raise ValueError("...") at line 42  →  ✅ tested by test_invalid_input_raises_value_error
return None at line 67              →  ❌ no test exercises None return path
except TimeoutError at line 91      →  ✅ tested by test_timeout_returns_default

---

Assertion Quality Check

For each test found in the audit — is the assertion good or bad?

Bad assertion (mirrors implementation, passes even if implementation is wrong):

# Bad: asserts len matches what the function happened to return
assert len(result) == mock_service.call_count

Good assertion (asserts specific expected output, independent of implementation):

# Good: asserts the exact expected data
assert result == [FeatureRecord(timestamp=t1, value=1.0), FeatureRecord(timestamp=t2, value=2.0)]

Flag bad assertions — they provide false confidence.

---

Output Format

After running all 5 steps, produce:

## QA Goggles Report

| Gap | Step Found | Severity | Recommended Action |
|---|---|---|---|
| [description] | 1–5 | blocking/high/medium/low | add test / accept / separate task |

Total gaps: [N]
Blocking: [N] | High: [N] | Medium: [N] | Low: [N]