npx skills add https://www.modelscope.cn/skills/@jpoutrin/qa-testing-methodology
smithery/jpoutrin
qa-testing-methodology
QA test design patterns (equivalence partitioning, boundary analysis, accessibility). Auto-loads when designing test cases, planning test coverage, or writing test procedures.
Installation
npx skills add smithery/jpoutrin --skill qa-testing-methodology
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, includ…
810.4K installsPostgres best practices maintained by Supabase, for Postgres running anywhere. Load this skill …
391.6K installsReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "chec…
617.3K installsBuild, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and …
576.5K installsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe …
568.9K installsAlso in this package
Other skills from smithery/jpoutrin · top by installs.
npx skills add smithery/jpoutrin
More details
Agent compatibility
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Also listed on
Alternate registries and mirrors of this skill.
Package contents
Files included with this skill beyond the listing page.
-
skill md
SKILL.md6,518 B -
docs
SUMMARY.md213 B
History
- First recorded snapshot · 0 installs
SKILL.md
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: [email protected]
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: [email protected]" |
| "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 "[email protected]" 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)