Manual Test

manual-test

Preparing manual test session...

1. Gather Context

Read these files to understand what to test:

Recent Changes

# What changed recently (last 20 commits or since last tag)
git log --oneline -20
git diff --stat HEAD~10

Identify which areas of the project were modified and map to testable features.

Known Issues

Check the backlog for known gaps and bugs that are still TODO:

• Read relevant epic files in docs/reference/backlog/
• These are confirmed issues — test around them but don't spend time re-discovering them

Recent Sprint Work

• Read docs/progress.md for latest sprint info
• Check docs/sprints/ for recent sprint specs with acceptance criteria

UAT Coverage

• Read docs/testing/UAT_COVERAGE.md (if it exists) for test case status
• Identify which areas have not been tested yet

Product Requirements & Personas

• Read docs/context/personas.md (if it exists) for lean persona cards — these provide CONTEXT, GOALS, FRUSTRATIONS, BEHAVIORS, EVALUATES BY, and FAILURE LOOKS LIKE fields that directly inform exploratory testing in Phase 3C
• Read docs/reference/PRD_SUMMARY.md (if it exists) for success criteria and user flows
• Section 3 (success criteria) identify what to prioritize testing
• Section 4 (user flows) provide the core scenarios to regression test
• If both personas.md and PRD Section 2 exist, prefer personas.md (richer behavioral detail for test generation)

2. Pre-Flight Checks

Before manual testing, verify the system is ready:

Run the project's test command (from CLAUDE.md) to ensure automated tests pass.

If pre-flight fails, fix issues before proceeding to manual testing.

3. Generate Test Plan

Generate a structured test plan covering three areas:

A. Regression Tests (from recent changes)

Based on the git diff, generate specific test scenarios for recently modified code:

#### Regression: [Area changed]
- [ ] **Scenario**: [What to test] — **Steps**: [How to test] — **Expected**: [What should happen]

B. Known Issue Verification

For each recently fixed issue, generate a verification test:

#### Verify Fix: [Story ID] — [Title]
- [ ] [Specific step to verify the fix still works]

For each open issue, note it as a known limitation:

#### Known Limitation: [Story ID] — [Title]
- Warning: [Brief description] — skip testing this area

C. Exploratory Testing

Based on architecture and project knowledge, suggest areas to probe.

If personas.md was loaded: Structure exploratory testing around each persona. For each persona, create scenarios that exercise their GOALS, probe their FRUSTRATIONS, use their CONTEXT constraints, and check for their FAILURE LOOKS LIKE scenarios. Apply their EVALUATES BY questions to each tested feature.

If only PRD_SUMMARY.md was loaded (no personas.md): Structure exploratory testing around each persona from PRD Section 2. For each persona, create scenarios that exercise their primary goal, pain points, and constraints.

Example: a persona with "low connectivity" context → test offline/slow-network behavior. A persona with "screen reader" context → test keyboard navigation and ARIA labels. A persona with "FAILURE LOOKS LIKE: gets stuck on jargon-filled error messages" → verify all error messages are plain English.

#### Exploratory: [Feature Area] (as [Persona Name])
- [ ] [Step 1 — what to do and what to look for, from persona's perspective]
- [ ] [Step 2]

#### Exploratory: Error Handling
- [ ] [Provoke an error condition and verify graceful handling]

#### Exploratory: Edge Cases
- [ ] [Test boundary conditions, empty states, large inputs]

4. Present Test Plan

Output the complete test plan:

## Manual Test Plan — [Date]

### Environment
- [List required services, tools, and their status]

### A. Regression Tests ([count] scenarios)
[generated scenarios]

### B. Known Issue Checks
**Verified fixes**: [count]
**Known limitations**: [count]
[generated checks]

### C. Exploratory Testing ([count] areas)
[generated areas]

### How to Report Findings
Use `/testing-cycle <description of what you found>` for each issue.
This will classify it and handle it through the right process.

For structured UAT, use `/UAT-cycle <test-case-id>` to execute formal test cases.

5. Wait for Testing

Tell the user:

The test plan is ready. Start the application if not already running, then work through the checklist. Report each finding with /testing-cycle <feedback>. When done, wrap up with /sprint-end.

Do not proceed until user reports back.