qa-testing-methodology

# QA Testing Methodology Skill

Apply proven test design patterns for comprehensive test coverage.

## Test Case Design Order

Always design tests in this order:

1. **Happy Path** - Main success scenarios
2. **Validation Tests** - Required fields, format validation
3. **Edge Cases** - Boundary conditions, limits
4. **Error Scenarios** - Invalid inputs, system errors
5. **Permission Tests** - Access control, authorization

## Equivalence Partitioning

Divide input data into partitions where all values should behave identically.

### Example: Age Input Field (18-65)

| Partition | Values | Expected Behavior |
|-----------|--------|-------------------|
| Below minimum | 0-17 | Reject with "Must be 18+" |
| Valid range | 18-65 | Accept |
| Above maximum | 66+ | Reject with "Maximum age is 65" |
| Invalid | -1, "abc", empty | Reject with validation error |

**Test Strategy**: Test ONE value from each partition, not every value.

## Boundary Value Analysis

Focus testing on boundaries where behavior changes.

### Example: Password (8-20 characters)

| Boundary | Test Values | Expected |
|----------|-------------|----------|
| Just below minimum | 7 chars | Reject |
| At minimum | 8 chars | Accept |
| Just above minimum | 9 chars | Accept |
| Just below maximum | 19 chars | Accept |
| At maximum | 20 chars | Accept |
| Just above maximum | 21 chars | Reject |

## Test Prioritization Matrix

Prioritize tests based on risk and frequency:

| Priority | Risk | User Impact | Test Frequency |
|----------|------|-------------|----------------|
| **Critical** | Data loss, security breach | All users blocked | Every build |
| **High** | Feature broken | Major workflow impacted | Every release |
| **Medium** | Inconvenient | Workaround available | Weekly |
| **Low** | Minor annoyance | Cosmetic issues | Monthly |

## Accessibility Testing Checklist

Include in every test procedure:

### Keyboard Navigation
- [ ] All interactive elements focusable with Tab
- [ ] Focus order is logical (left-to-right, top-to-bottom)
- [ ] Focus indicator is visible
- [ ] No keyboard traps

### Screen Reader
- [ ] All images have alt text
- [ ] Form fields have labels
- [ ] Error messages announced
- [ ] Headings structured correctly (h1 → h2 → h3)

### Visual
- [ ] Color contrast meets WCAG AA (4.5:1 for text)
- [ ] Information not conveyed by color alone
- [ ] Text resizable to 200% without loss
- [ ] No content flashes more than 3 times/second

## Performance Considerations

Note performance during manual testing:

| Metric | Acceptable | Needs Investigation |
|--------|------------|---------------------|
| Page load | < 3 seconds | > 3 seconds |
| Button response | < 100ms | > 300ms |
| Form submission | < 2 seconds | > 5 seconds |
| Search results | < 1 second | > 2 seconds |

## Test Data Guidelines

### DO
- Use realistic but fake data
- Document exact test data in test cases
- Use consistent test accounts
- Reset test data between runs when needed

### DON'T
- Use production data
- Use generic placeholders ("enter something")
- Share test credentials in plain text
- Assume data from previous tests exists

### Test Data Examples

```
Email: test.user@example.com
Password: Test@1234! (in password manager)
Phone: +1-555-0100 (test range)
Credit Card: 4111-1111-1111-1111 (test card)
Address: 123 Test Street, Test City, TS 12345
```

## Regression Testing

When to run regression tests:

| Trigger | Regression Scope |
|---------|------------------|
| Bug fix | Related feature + integration points |
| New feature | All features that share data/UI |
| Dependency update | Full regression |
| Release candidate | Critical + High priority tests |

## State-Based Testing

Test all valid state transitions:

```
Example: Order Status
┌─────────┐     ┌─────────┐     ┌─────────┐     ┌───────────┐
│ Created │ ──▶ │ Pending │ ──▶ │ Shipped │ ──▶ │ Delivered │
└─────────┘     └─────────┘     └─────────┘     └───────────┘
                     │                               │
                     ▼                               ▼
               ┌───────────┐                  ┌────────────┐
               │ Cancelled │                  │  Returned  │
               └───────────┘                  └────────────┘
```

Test:
- Valid transitions (Created → Pending)
- Invalid transitions (Delivered → Created)
- Edge cases (Cancel while shipping)

## Error Message Verification

Check error messages for:

1. **Clarity**: User understands what went wrong
2. **Actionability**: User knows how to fix it
3. **Tone**: Professional, not blaming
4. **Security**: No sensitive information exposed

### Good vs Bad Error Messages

| Bad | Good |
|-----|------|
| "Error 500" | "Something went wrong. Please try again." |
| "Invalid input" | "Email must be in format: name@example.com" |
| "User not found in database" | "No account found with this email" |
| "Password must match regex..." | "Password needs 8+ characters with a number" |

## Cross-Browser Testing Matrix

Minimum browser coverage:

| Browser | Desktop | Mobile |
|---------|---------|--------|
| Chrome | Latest, Latest-1 | Android |
| Safari | Latest | iOS |
| Firefox | Latest | - |
| Edge | Latest | - |

## Test Documentation Patterns

### When to Screenshot

- Initial state before test
- After critical actions
- Error states
- Final/success state
- Any unexpected behavior

### Writing Clear Steps

**Bad**: Click the button
**Good**: Click the blue "Submit" button in the bottom-right of the form

**Bad**: Enter your details
**Good**: Enter "test@example.com" in the Email field

**Bad**: Verify it works
**Good**: Verify success message "Order placed successfully" appears

## Mobile Testing Considerations

- Test touch targets (minimum 44x44 pixels)
- Test swipe gestures where applicable
- Test orientation changes (portrait ↔ landscape)
- Test with on-screen keyboard visible
- Test with poor network (3G simulation)