1.6Before/After: Transforming a Bad Test Plan

BEFORE (Bad Test Plan)

Test Plan for Release 2.4

We will test the new features in release 2.4. Testing will include
functional testing, regression testing, and performance testing.
The QA team will execute test cases and report bugs. Testing will
take place on the QA environment. We will use Jira for bug tracking.

Test Cases:
- Test checkout
- Test search
- Test login
- Test payment

Schedule: Testing will happen next week.

What is wrong with this plan:

• Every sentence is generic and could describe any project
• No specific scope (which "new features"?)
• No risks identified
• No exit criteria (when is testing "done"?)
• No test data requirements
• No environment details beyond a name
• Schedule is vague ("next week")
• Test cases are so broad they are meaningless

AFTER (Good Test Plan)

# Test Plan: Multi-Currency Checkout -- Sprint 14

## Scope
Testing the multi-currency checkout feature (SHOP-1234) that allows
users to pay in EUR, GBP, and JPY in addition to USD. Covers:
- Currency selection on checkout page
- Exchange rate display and refresh
- Payment processing in non-USD currencies
- Order confirmation with converted amounts
- Order history showing original and converted amounts

## Out of Scope
- Mobile app (separate test plan for Sprint 15)
- Currencies beyond EUR, GBP, JPY (Phase 2)
- Admin panel currency management (tested in Sprint 13)

## Approach
- **Manual testing:** Checkout flow in each currency, edge cases
  (currency switching mid-checkout, rate changes during session)
- **Automated testing:** 12 new E2E tests for currency checkout
  added to Playwright suite; existing 487 regression tests
- **Exploratory testing:** Focus on currency rounding, error
  handling when Forex API is slow or unavailable

## Test Environments
| Environment | URL | Purpose |
|---|---|---|
| QA | qa.shop.example.com | Feature testing with mock Forex API |
| Staging | staging.shop.example.com | Integration testing with real Forex API (sandbox) |

## Test Data
- Test accounts with addresses in US, UK, Germany, Japan
- Test credit cards for USD, EUR, GBP, JPY (Stripe test cards)
- Products with prices that produce rounding edge cases ($9.99, $0.01)

## Risks
| Risk | Impact | Mitigation |
|---|---|---|
| Forex API sandbox rate limits | Cannot test under load | Mock API for load tests |
| JPY has no decimal places | Rounding bugs | Specific test cases for zero-decimal currencies |
| Exchange rate volatility | Inconsistent test results | Pin exchange rates in QA environment |

## Entry Criteria
- [ ] Multi-currency code merged to release/2.4 branch
- [ ] Forex API sandbox credentials configured in QA and staging
- [ ] Test accounts created with international addresses
- [ ] Feature flag `multi-currency` enabled in QA

## Exit Criteria
- [ ] All 34 manual test cases passed
- [ ] 12 new automated tests passing in CI
- [ ] Full regression suite green (487 tests)
- [ ] No open Sev-1 or Sev-2 bugs
- [ ] Performance: checkout p95 latency < 2s with currency conversion
- [ ] Exploratory testing completed (4 hours, 2 QA engineers)

## Schedule
| Activity | Start | End | Owner |
|---|---|---|---|
| Test case design | Mon Feb 10 | Tue Feb 11 | Alice (QA) |
| Environment setup | Mon Feb 10 | Mon Feb 10 | Bob (DevOps) |
| Manual testing | Wed Feb 12 | Thu Feb 13 | Alice + Carol (QA) |
| Automation | Wed Feb 12 | Fri Feb 14 | Dave (SDET) |
| Exploratory testing | Thu Feb 13 | Fri Feb 14 | Alice (QA) |
| Go/no-go review | Fri Feb 14 2:00 PM | -- | All stakeholders |

Notice the transformation: every sentence is specific to this project. A reader immediately knows what is being tested, what is not, what could go wrong, and when testing is done.