qa-screenshot-management
Screenshot capture, organization, and comparison for QA testing. Use when taking screenshots during test execution to ensure proper naming, organization, and traceability back to test cases.
Best use case
qa-screenshot-management is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Screenshot capture, organization, and comparison for QA testing. Use when taking screenshots during test execution to ensure proper naming, organization, and traceability back to test cases.
Teams using qa-screenshot-management should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/qa-screenshot-management/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How qa-screenshot-management Compares
| Feature / Agent | qa-screenshot-management | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Screenshot capture, organization, and comparison for QA testing. Use when taking screenshots during test execution to ensure proper naming, organization, and traceability back to test cases.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# QA Screenshot Management Skill
Standardize screenshot capture and organization during QA testing.
## Directory Structure
```
qa-tests/
├── draft/ # QA test documents by status
├── active/
├── executed/
├── archived/
└── screenshots/
├── {test-id}/ # e.g., QA-20250105-001
│ ├── 01-initial-state.png # Numbered sequence
│ ├── 02-form-filled.png
│ ├── 03-success-state.png
│ └── elements/ # Extracted UI elements
│ ├── login-button.png
│ ├── email-field.png
│ └── password-field.png
├── baseline/ # Reference screenshots for comparison
│ └── {feature}/
│ └── {state}.png
└── failures/ # Failed test evidence
└── {date}/
└── {test-id}-{timestamp}.png
```
**Key:** Screenshots are stored in `qa-tests/screenshots/{test-id}/` where `{test-id}` matches the QA test document name (e.g., `QA-20250105-001`).
## Naming Convention
### Format
```
{sequence}-{state-description}.{png|jpeg}
```
### Sequence Numbers
- `01-` through `99-` for ordered steps
- Preserves execution order in file listings
### State Descriptions
Use descriptive, kebab-case names:
| State | Example Filename |
|-------|------------------|
| Initial page load | `01-initial-state.png` |
| After form fill | `02-form-filled.png` |
| Validation error | `03-validation-error.png` |
| Success message | `04-success-message.png` |
| Modal open | `05-modal-open.png` |
| Dropdown expanded | `06-dropdown-expanded.png` |
### Bad vs Good Names
| Bad | Good |
|-----|------|
| `screenshot1.png` | `01-login-page-loaded.png` |
| `test.png` | `02-credentials-entered.png` |
| `error.png` | `03-invalid-password-error.png` |
| `final.png` | `04-dashboard-after-login.png` |
## When to Capture Screenshots
### Always Capture
1. **Initial State** - Before any test actions
2. **After Critical Actions** - Form submissions, navigation
3. **Error States** - Any validation or system errors
4. **Success States** - Confirmation messages, completed flows
5. **Final State** - End of test case
### Conditional Capture
- Unexpected behavior (document with timestamp)
- Performance issues (loading spinners, delays)
- UI anomalies (layout issues, missing elements)
## Screenshot Metadata
Include metadata in test documentation:
```markdown
### Screenshots
| # | Filename | Description | Step |
|---|----------|-------------|------|
| 1 | 01-initial-state.png | Login page before input | TC-001 Step 1 |
| 2 | 02-credentials-entered.png | Form with test credentials | TC-001 Step 2 |
| 3 | 03-dashboard-loaded.png | Dashboard after successful login | TC-001 Step 3 |
```
## Playwright Screenshot Commands
### Basic Capture
```javascript
// Full viewport
await page.screenshot({ path: 'screenshots/01-initial-state.png' });
// Full page (scrollable)
await page.screenshot({
path: 'screenshots/02-full-page.png',
fullPage: true
});
```
### Element Screenshot
```javascript
// Specific element only
const element = page.locator('.error-message');
await element.screenshot({ path: 'screenshots/03-error-detail.png' });
```
### With Timestamp
```javascript
const timestamp = new Date().toISOString().replace(/[:.]/g, '-');
await page.screenshot({
path: `screenshots/failure-${timestamp}.png`
});
```
## Visual Comparison Strategy
### Baseline Management
1. **Create Baseline**
- Capture reference screenshots on approved build
- Store in `screenshots/baseline/{feature}/`
- Version control baselines
2. **Compare During Testing**
- Capture current state
- Compare against baseline
- Document differences
### Acceptable Differences
| Type | Action |
|------|--------|
| Dynamic content (dates, times) | Mask or ignore region |
| User-specific data | Use consistent test data |
| Animations | Wait for stable state |
| Random elements (ads) | Exclude from comparison |
## Failure Documentation
When a test fails, capture:
```
screenshots/failures/2025-01-05/
├── QA-20250105-001-TC-002-1704456789.png # Actual state
├── QA-20250105-001-TC-002-expected.png # Expected (if applicable)
└── QA-20250105-001-TC-002-diff.png # Visual diff (if generated)
```
### Failure Screenshot Checklist
- [ ] Capture full page showing context
- [ ] Capture specific element with issue
- [ ] Note browser console errors
- [ ] Record timestamp
- [ ] Link to test case and step
## Cross-Browser Screenshots
Organize by browser when testing multiple browsers:
```
screenshots/{test-id}/
├── chrome/
│ ├── 01-initial-state.png
│ └── 02-final-state.png
├── firefox/
│ └── ...
└── safari/
└── ...
```
## Responsive Screenshots
Capture at standard breakpoints:
| Device | Width | Suffix |
|--------|-------|--------|
| Mobile | 375px | `-mobile` |
| Tablet | 768px | `-tablet` |
| Desktop | 1280px | `-desktop` |
| Wide | 1920px | `-wide` |
Example:
```
01-homepage-mobile.png
01-homepage-tablet.png
01-homepage-desktop.png
```
## Screenshot Cleanup
### Retention Policy
| Category | Retention |
|----------|-----------|
| Passing tests | Delete after test run |
| Failing tests | Keep until issue resolved |
| Baselines | Keep in version control |
| Regression evidence | Keep 30 days minimum |
### Cleanup Command
```bash
# Remove screenshots older than 30 days from failures
find qa-tests/screenshots/failures -mtime +30 -delete
```
## Integration with Test Reports
Reference screenshots in test execution logs:
```markdown
## Test Execution Log
| Date | Tester | Result | Evidence |
|------|--------|--------|----------|
| 2025-01-05 | Jane | FAIL | [Screenshots](./screenshots/QA-20250105-001/) |
```
## Accessibility Screenshot Guidelines
When documenting accessibility issues:
1. **Highlight Problem Area**
- Use browser dev tools to highlight element
- Capture with focus indicator visible
2. **Include Context**
- Show surrounding elements
- Capture screen reader output if relevant
3. **Document Fix Verification**
- Before screenshot
- After screenshot
- Side-by-side comparisonRelated Skills
qa-test-management
Automatic QA test lifecycle management, naming conventions, and directory structure. Use when creating, organizing, or tracking QA tests to ensure proper naming, directory structure, and status transitions.
qa-screenshot-validation
Evaluate captured screenshots for layout issues, masked elements, and rendering problems. Use after taking screenshots to validate visual correctness and automatically resize viewport if elements are unexpectedly clipped.
prd-management
Use when organizing PRDs, tracking requirements, managing product specs, updating PRD status, archiving completed docs, or setting up PRD structure. Auto-applies naming conventions and lifecycle management.
zod
Zod schema validation patterns and type inference. Auto-loads when validating schemas, parsing data, validating forms, checking types at runtime, or using z.object/z.string/z.infer in TypeScript.
typescript-import-style
Merge-friendly import formatting (one-per-line, alphabetical). Auto-loads when writing TypeScript/JavaScript imports to minimize merge conflicts in parallel development. Enforces consistent grouping and sorting.
setup-mcp-auth
Configure authentication for an existing FastMCP server
fastmcp
FastMCP TypeScript framework patterns for MCP servers. Auto-loads when building MCP servers, creating tools/resources/prompts, implementing authentication, configuring transports, or working with FastMCP in TypeScript.
add-mcp-tool
Add a new tool to an existing FastMCP server with guided configuration
add-mcp-resource
Add a new resource or resource template to an existing FastMCP server
plan-with-team
Validate plan file ownership
privacy-compliance
GDPR, CCPA, and privacy compliance guidance for data protection. Use when handling personal data, implementing consent management, or ensuring regulatory compliance across jurisdictions.
oauth
OAuth 2.0 and OpenID Connect implementation patterns. Use when implementing authentication, authorization flows, or integrating with OAuth providers like Google, GitHub, or custom identity providers.