CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

Install with Tessl CLI

npx tessl i github:jpoutrin/product-forge --skill qa-screenshot-management
What are skills?

78

Review — 75%

Does it follow best practices?

Validation — 11 / 11 Passed

Validation for skill structure

SKILL.md
Review
Evals

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:

StateExample Filename
Initial page load01-initial-state.png
After form fill02-form-filled.png
Validation error03-validation-error.png
Success message04-success-message.png
Modal open05-modal-open.png
Dropdown expanded06-dropdown-expanded.png

Bad vs Good Names

BadGood
screenshot1.png01-login-page-loaded.png
test.png02-credentials-entered.png
error.png03-invalid-password-error.png
final.png04-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:

### 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

// 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

// Specific element only
const element = page.locator('.error-message');
await element.screenshot({ path: 'screenshots/03-error-detail.png' });

With Timestamp

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

TypeAction
Dynamic content (dates, times)Mask or ignore region
User-specific dataUse consistent test data
AnimationsWait 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:

DeviceWidthSuffix
Mobile375px-mobile
Tablet768px-tablet
Desktop1280px-desktop
Wide1920px-wide

Example:

01-homepage-mobile.png
01-homepage-tablet.png
01-homepage-desktop.png

Screenshot Cleanup

Retention Policy

CategoryRetention
Passing testsDelete after test run
Failing testsKeep until issue resolved
BaselinesKeep in version control
Regression evidenceKeep 30 days minimum

Cleanup Command

# 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:

## 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 comparison
Repository
jpoutrin/product-forge
Commit

0ebe7ae

Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.

Claim skill