exploratory-test

Name: exploratory-test
Author: tobihagemann

2installs29forks

How to install exploratory-test?

tobihagemann/turbo/exploratory-test

$npx -y skills add tobihagemann/turbo --skill exploratory-test

Installs into the current project.

Summary

Execute multi-level exploratory testing of the app covering basic functionality, complex operations, adversarial testing, and cross-cutting scenarios, plus usability observations through a UX lens reported separately from defects. Deeper than /smoke-test. Use when the user asks t

Files · 1

View on GitHub

SKILL.md

1	# Exploratory Test
2
3	Execute multi-level exploratory testing that goes beyond smoke testing to actively find bugs through escalating test scenarios.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each step:
8
9	1. Load or create test plan
10	2. Determine testing approach
11	3. Run `/user-experience` skill (when user-facing)
12	4. Execute tests by level
13	5. Report
14
15	## Step 1: Load or Create Test Plan
16
17	Check if `.turbo/test-plan.md` exists.
18
19	- If it exists — read the test plan and continue to Step 2. If the user specifies a narrower scope, filter the plan to relevant scenarios rather than executing all of them.
20	- If it does not exist — run the `/create-test-plan` skill first, then continue.
21
22	## Step 2: Determine Testing Approach
23
24	Use the approach specified in the test plan. If the plan does not specify one, determine it using the same logic as `/create-test-plan` Step 3.
25
26	## Step 3: Run `/user-experience` Skill (When User-Facing)
27
28	If the app has a user-facing surface (UI, screens, commands, messages, or any behavior a user sees or does), run the `/user-experience` skill to load the UX lens before executing tests, so usability concerns surface while interacting with the app. When it is unclear whether the surface is user-facing, use `AskUserQuestion` to ask rather than skipping silently. Skip this step for test targets with no user-facing behavior (internal library or infrastructure).
29
30	## Step 4: Execute Tests by Level
31
32	Work through each level sequentially. Complete all tests in a level before moving to the next.
33
34	### Execution Loop (Per Test)
35
36	1. Set up the preconditions described in the test scenario
37	2. Perform the exact steps
38	3. Capture the result (screenshot, output, or state observation)
39	4. Compare against the expected outcome
40	5. Record PASS or FAIL with details
41	6. When the UX lens is loaded, note any usability observation it surfaces, kept separate from the PASS/FAIL verdict
42
43	### Level Progression
44
45	1. Level 1: Basic Functionality — If any Level 1 test fails, report early and use `AskUserQuestion` to ask whether to continue. Basic failures may indicate the feature is too broken for deeper testing.
46	2. Level 2: Complex Operations — Execute all tests regardless of individual failures.
47	3. Level 3: Adversarial Testing — Execute all tests. Failures here are expected and valuable.
48	4. Level 4: Cross-Cutting Scenarios — Execute all tests.
49
50	If a project-specific testing skill or MCP tool was identified in Step 2, use that. The paths below are fallbacks.
51
52	### Web App Path
53
54	Start the dev server if not already running. Wait for it to be ready. If `/agent-browser` is available, run the `/agent-browser` skill. Otherwise, use `claude-in-chrome` MCP to interact with the app.
55
56	### UI/Native App Path
57
58	Launch the app. Use `computer-use` MCP to interact with the UI.
59
60	### CLI Path
61
62	Run commands directly.
63
64	## Step 5: Report
65
66	Present results organized by level:
67
68	```
69	Exploratory Test Results:
70
71	## Level 1: Basic Functionality (X/Y passed)
72	- [PASS] Test name: description
73	- [FAIL] Test name: description — [what went wrong]
74
75	## Level 2: Complex Operations (X/Y passed)
76	- [PASS] Test name: description
77	- [FAIL] Test name: description — [what went wrong]
78
79	## Level 3: Adversarial Testing (X/Y passed)
80	- [PASS] Test name: description
81	- [FAIL] Test name: description — [what went wrong]
82
83	## Level 4: Cross-Cutting Scenarios (X/Y passed)
84	- [PASS] Test name: description
85	- [FAIL] Test name: description — [what went wrong]
86
87	Overall: X/Y passed across all levels
88	```
89
90	Report usability observations from the UX lens below the level results, separately from the PASS/FAIL defects. A scenario can pass every functional check and still surface a usability concern.
91
92	```
93	## Usability Observations
94	- [UX] <observation> — names the UX context it touches (Understanding, Bridging, or Flowing) and the goal mismatch or friction it creates
95	```
96
97	For each failure, include the relevant screenshot, output, or state observation.
98
99	Update `.turbo/test-plan.md` by checking off completed tests and annotating results.
100
101	Then use the TaskList tool and proceed to any remaining task.
102
103	## Rules
104
105	- Always clean up: close browser sessions, stop dev servers started by this skill.
106	- Isolate shared process state so concurrent or subagent runs don't collide: bind dev servers and services to unique ports, scope tmux sessions (`tmux -L <name>`), and use temporary directories for scratch state.
107	- Never modify a

People who liked this also viewed

6 picks

Type

exploratory-test

2installs29forks

View on GitHub

How to install exploratory-test?

tobihagemann/turbo/exploratory-test

$npx -y skills add tobihagemann/turbo --skill exploratory-test

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Exploratory Test
2
3	Execute multi-level exploratory testing that goes beyond smoke testing to actively find bugs through escalating test scenarios.
4
5	## Task Tracking
6
7	At the start, use `TaskCreate` to create a task for each step:
8
9	1. Load or create test plan
10	2. Determine testing approach
11	3. Run `/user-experience` skill (when user-facing)
12	4. Execute tests by level
13	5. Report
14
15	## Step 1: Load or Create Test Plan
16
17	Check if `.turbo/test-plan.md` exists.
18
19	- If it exists — read the test plan and continue to Step 2. If the user specifies a narrower scope, filter the plan to relevant scenarios rather than executing all of them.
20	- If it does not exist — run the `/create-test-plan` skill first, then continue.
21
22	## Step 2: Determine Testing Approach
23
24	Use the approach specified in the test plan. If the plan does not specify one, determine it using the same logic as `/create-test-plan` Step 3.
25
26	## Step 3: Run `/user-experience` Skill (When User-Facing)
27
28	If the app has a user-facing surface (UI, screens, commands, messages, or any behavior a user sees or does), run the `/user-experience` skill to load the UX lens before executing tests, so usability concerns surface while interacting with the app. When it is unclear whether the surface is user-facing, use `AskUserQuestion` to ask rather than skipping silently. Skip this step for test targets with no user-facing behavior (internal library or infrastructure).
29
30	## Step 4: Execute Tests by Level
31
32	Work through each level sequentially. Complete all tests in a level before moving to the next.
33
34	### Execution Loop (Per Test)
35
36	1. Set up the preconditions described in the test scenario
37	2. Perform the exact steps
38	3. Capture the result (screenshot, output, or state observation)
39	4. Compare against the expected outcome
40	5. Record PASS or FAIL with details
41	6. When the UX lens is loaded, note any usability observation it surfaces, kept separate from the PASS/FAIL verdict
42
43	### Level Progression
44
45	1. Level 1: Basic Functionality — If any Level 1 test fails, report early and use `AskUserQuestion` to ask whether to continue. Basic failures may indicate the feature is too broken for deeper testing.
46	2. Level 2: Complex Operations — Execute all tests regardless of individual failures.
47	3. Level 3: Adversarial Testing — Execute all tests. Failures here are expected and valuable.
48	4. Level 4: Cross-Cutting Scenarios — Execute all tests.
49
50	If a project-specific testing skill or MCP tool was identified in Step 2, use that. The paths below are fallbacks.
51
52	### Web App Path
53
54	Start the dev server if not already running. Wait for it to be ready. If `/agent-browser` is available, run the `/agent-browser` skill. Otherwise, use `claude-in-chrome` MCP to interact with the app.
55
56	### UI/Native App Path
57
58	Launch the app. Use `computer-use` MCP to interact with the UI.
59
60	### CLI Path
61
62	Run commands directly.
63
64	## Step 5: Report
65
66	Present results organized by level:
67
68	```
69	Exploratory Test Results:
70
71	## Level 1: Basic Functionality (X/Y passed)
72	- [PASS] Test name: description
73	- [FAIL] Test name: description — [what went wrong]
74
75	## Level 2: Complex Operations (X/Y passed)
76	- [PASS] Test name: description
77	- [FAIL] Test name: description — [what went wrong]
78
79	## Level 3: Adversarial Testing (X/Y passed)
80	- [PASS] Test name: description
81	- [FAIL] Test name: description — [what went wrong]
82
83	## Level 4: Cross-Cutting Scenarios (X/Y passed)
84	- [PASS] Test name: description
85	- [FAIL] Test name: description — [what went wrong]
86
87	Overall: X/Y passed across all levels
88	```
89
90	Report usability observations from the UX lens below the level results, separately from the PASS/FAIL defects. A scenario can pass every functional check and still surface a usability concern.
91
92	```
93	## Usability Observations
94	- [UX] <observation> — names the UX context it touches (Understanding, Bridging, or Flowing) and the goal mismatch or friction it creates
95	```
96
97	For each failure, include the relevant screenshot, output, or state observation.
98
99	Update `.turbo/test-plan.md` by checking off completed tests and annotating results.
100
101	Then use the TaskList tool and proceed to any remaining task.
102
103	## Rules
104
105	- Always clean up: close browser sessions, stop dev servers started by this skill.
106	- Isolate shared process state so concurrent or subagent runs don't collide: bind dev servers and services to unique ports, scope tmux sessions (`tmux -L <name>`), and use temporary directories for scratch state.
107	- Never modify a

People who liked this also viewed

6 picks

Type