Skip to content
Back to skills

Browser Journey Test

ASecurity

Validate user stories by simulating real user journeys in a live browser against deployed application. Activate after implementation to verify actual user experience against acceptance criteria, not just code logic.

  • 162 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 23, 2026
ai-agentsgotesting

Security analysis

A100/100

Scanned September 23, 2026

npx -y skills add digipulse-engineering/GAAI-framework --skill browser-journey-test --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Browser Journey Test?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Browser Journey Test
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/digipulse-engineering-browser-journey-test/badge)](https://www.skillsdirectory.com/skills/digipulse-engineering-browser-journey-test)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: browser-journey-test
description: Validate user stories by simulating real user journeys in a live browser against deployed application. Activate after implementation to verify actual user experience against acceptance criteria, not just code logic.
license: ELv2
compatibility: Works with any filesystem-based AI coding agent (requires browser automation capability)
metadata:
  author: gaai-framework
  version: "1.1"
  category: delivery
  track: delivery
  id: SKILL-BROWSER-JOURNEY-TEST-001
  updated_at: 2026-02-26
  status: experimental
  required_capability: browser-automation
inputs:
  - contexts/artefacts/stories/**
  - deployed_application_url  # Provided by the invoking agent from the staging deploy output. Not supplied manually.
outputs:
  - contexts/artefacts/test-evidence/{story_id}/journey-test-report.md
---

# Browser Journey Test

## Purpose / When to Activate

Activate after implementation to validate real user experience — not just code logic.

Use when:
- Stories describe user-facing flows
- Acceptance criteria can only be verified through UI interaction
- Regression testing requires end-to-end validation

Complements (does not replace) `qa-review`.

---

## Process

**CRITICAL — Anti-Collision Guard (MUST execute before writing any output file):**
Before writing `contexts/artefacts/test-evidence/{story_id}/journey-test-report.md`, check if the target file already exists on disk:
- If it does NOT exist → proceed normally.
- If it DOES exist → **read the existing file first**. Then decide:
  - If the existing content is from a **different entity** (different story ID, different epic) → **STOP immediately**, surface the ID collision to the human, do not proceed.
  - If the existing content is from the **same entity** and an update is warranted (e.g., re-run after a fix) → proceed, but preserve any prior evidence or notes that remain relevant. Treat this as an **update**, not a replacement.
  - If the existing content is identical or still valid → skip writing, report "no changes needed".
This guard prevents the silent data loss incident of 2026-03-17 where concurrent sessions overwrote story files.

For each Story:

1. Read the Story's acceptance criteria. For each AC, extract the user action (verb + object) and the expected outcome. Produce a numbered action sequence.

2. Execute each action in the sequence using the browser automation capability available in the current environment (e.g., Playwright, Puppeteer, or the agent's built-in browser tool). Navigate to `deployed_application_url` before starting.

3. After each action, capture: (a) a screenshot saved to `contexts/artefacts/test-evidence/{story_id}/step-{N}.png`, (b) the HTTP status code, (c) any console errors, (d) whether the expected outcome from Step 1 is visually and functionally confirmed.

4. For each step, classify the result: PASS (outcome confirmed), FUNCTIONAL_FAILURE (expected outcome not met — blocks delivery), UX_FRICTION (outcome met but interaction is degraded — e.g., slow load, confusing layout, accessibility issue — does not block delivery).

5. Produce the test report using the output format below.

---

## Output Format

```
# Browser Journey Test — {Story ID}

> **Date:** {YYYY-MM-DD}
> **URL:** {deployed_application_url}
> **Overall verdict:** PASS | FAIL

## Step Results

| # | Action | Expected Outcome | Result | Evidence |
|---|--------|-----------------|--------|----------|
| 1 | {action} | {outcome} | PASS/FUNCTIONAL_FAILURE/UX_FRICTION | step-1.png |

## Functional Failures (blocking)
{list or "None"}

## UX Friction Points (non-blocking)
{list or "None"}
```

---

## Outputs

- `contexts/artefacts/test-evidence/{story_id}/journey-test-report.md`
- `contexts/artefacts/test-evidence/{story_id}/step-{N}.png` — one screenshot per action step

---

## Quality Checks

- Every acceptance criterion has a corresponding browser test
- Every step result has a screenshot as evidence
- Failures include reproduction steps
- Evidence is captured for audit trail
- FUNCTIONAL_FAILURE vs UX_FRICTION classification follows the rule: outcome not met = failure, outcome met but degraded = friction

---

## Non-Goals

This skill must NOT:
- Replace unit or integration tests
- Make product decisions about UX issues
- Run tests against non-deployed code

**Validates real user experience. Prevents regressions in production-like conditions.**

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.