| name | qa-testing-methodology |
| description | QA best practices and test design patterns. Use when designing test cases to ensure comprehensive coverage with equivalence partitioning, boundary analysis, and accessibility testing. |
QA Testing Methodology Skill
Apply proven test design patterns for comprehensive test coverage.
Test Case Design Order
Always design tests in this order:
- Happy Path - Main success scenarios
- Validation Tests - Required fields, format validation
- Edge Cases - Boundary conditions, limits
- Error Scenarios - Invalid inputs, system errors
- 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:
- Clarity: User understands what went wrong
- Actionability: User knows how to fix it
- Tone: Professional, not blaming
- 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)