Scoutqa Test

ScoutQA testing

Run AI-powered exploratory QA against local or remote web applications with the scoutqa CLI, then report execution IDs, issue IDs, severities, and verification evidence.

Think of ScoutQA as an intelligent testing partner that can autonomously explore, discover issues, and verify features. Delegate testing to multiple parallel ScoutQA executions to maximize coverage while saving time.

When to invoke

• "Test this website with ScoutQA."
• "Run exploratory testing on this page."
• "Check for accessibility issues."
• "Verify the login flow works."
• "Find bugs on this page after the feature change."

Procedure

Testing workflow

Copy this checklist and track your progress:

Testing Progress:

• Write specific test prompt with clear expectations
• Run scoutqa command in background
• Inform user of execution ID and browser URL
• Extract and analyze results

Step 1: Write specific test prompt

See "Writing Effective Prompts" section below for guidelines.

Step 2: Run scoutqa command

IMPORTANT: Use the Bash tool's timeout parameter (5000ms = 5 seconds) to capture execution details:

When calling the Bash tool, set timeout: 5000 as a parameter:

• This is the Bash tool's built-in timeout parameter in Claude Code (NOT the Unix timeout command)
• After 5 seconds, the Bash tool returns control with a task ID and the process continues running in the background
• This is different from Unix timeout which kills the process - here the process keeps running
• The first 5 seconds capture the execution ID and browser URL from ScoutQA's output
• The test continues running remotely on ScoutQA's infrastructure with the background task

scoutqa --url "https://example.com" --prompt "Your test instructions"

In the first few seconds, the command will output:

• Execution ID (e.g., 019b831d-xxx)
• Browser URL (e.g., https://app.scoutqa.ai/t/019b831d-xxx)
• Initial tool calls showing test progress

After the 5-second timeout, the Bash tool returns a task ID and the command continues running in the background. You can work on other tasks while the test runs. The timeout is only to capture the initial output (execution ID and browser URL) - the test keeps running both locally as a background task and remotely on ScoutQA's infrastructure.

Step 3: Inform user of execution ID and browser URL

After the Bash tool returns with the task ID (having captured the execution details in the first 5 seconds), inform the user of:

• The ScoutQA execution ID and browser URL so they can monitor progress in their browser
• The background task ID if they want to check local command output later

The test continues running in the background while you continue other work.

Step 4: Extract and analyze results

See "Presenting Results" section below for the complete format.

Command Options

• --url (required): Website URL to test (supports localhost / 127.0.0.1)
• --prompt (required): Natural language testing instructions
• --project-id (optional): Associate with a project for tracking
• -v, --verbose (optional): Show all tool calls including internal ones

Local Testing Support

ScoutQA supports testing localhost and 127.0.0.1 URLs autonomously — no manual setup required.

# Seamlessly test a locally running app when you're developing your app
scoutqa --url "http://localhost:3000" --prompt "Test the registration form"

When to Use Each Command

Starting a new test? → Use scoutqa --url --prompt Verifying a known issue? → Use scoutqa issue-verify --issue-id <id> Finding issue IDs from an execution? → Use scoutqa list-issues --execution-id <id> Agent needs more context? → Use scoutqa send-message (see "Following Up on Stuck Executions")

Prompt design

Focus on what to explore and verify, not prescriptive steps. ScoutQA autonomously determines how to test.

Example: User registration flow

scoutqa --url "https://example.com" --prompt "
Explore the user registration flow. Test form validation edge cases,
verify error handling, and check accessibility compliance.
"

Example: E-commerce checkout

scoutqa --url "https://shop.example.com" --prompt "
Test the checkout flow. Verify pricing calculations, cart persistence,
payment options, and mobile responsiveness.
"

Example: Running parallel tests for comprehensive coverage

Launch multiple tests in parallel by making multiple Bash tool calls in a single message, each with the Bash tool's timeout parameter set to 5000 (milliseconds):

# Test 1: Authentication & security
scoutqa --url "https://app.example.com" --prompt "
Explore authentication: login/logout, session handling, password reset,
and security edge cases.
"

# Test 2: Core features (runs in parallel)
scoutqa --url "https://app.example.com" --prompt "
Test dashboard and main user workflows. Verify data loading,
CRUD operations, and search functionality.
"

# Test 3: Accessibility (runs in parallel)
scoutqa --url "https://app.example.com" --prompt "
Conduct accessibility audit: WCAG compliance, keyboard navigation,
screen reader support, color contrast.
"

Implementation: Send a single message with three Bash tool calls. For each Bash tool invocation, set the timeout parameter to 5000 milliseconds. After 5 seconds, each Bash call returns with a task ID while the processes continue running in the background. This captures the execution ID and browser URL from each test in the initial output, then all three continue running in parallel (both as background tasks locally and remotely on ScoutQA's infrastructure).

Key guidelines:

• Describe what to test, not how to test (ScoutQA figures out the steps)
• Focus on goals, edge cases, and concerns
• Run multiple parallel executions for different test areas
• Trust ScoutQA to autonomously explore and discover issues
• Always set the Bash tool's timeout parameter to 5000 milliseconds when calling scoutqa commands (this returns control after 5 seconds while the process continues in the background)
• For parallel tests, make multiple Bash tool calls in a single message
• Remember: Bash tool timeout ≠ Unix timeout command (Bash timeout continues the process in background, Unix timeout kills it)

Common Test Scenarios

Post-deployment smoke test:

scoutqa --url "$URL" --prompt "
Smoke test: verify critical functionality works after deployment.
Check homepage, navigation, login/logout, and key user flows.
"

Accessibility audit:

scoutqa --url "$URL" --prompt "
Audit accessibility: WCAG 2.1 AA compliance, keyboard navigation,
screen reader support, color contrast, and semantic HTML.
"

E-commerce testing:

scoutqa --url "$URL" --prompt "
Explore e-commerce functionality: product search/filtering,
cart operations, checkout flow, and pricing calculations.
"

SaaS application:

scoutqa --url "$URL" --prompt "
Test SaaS app: authentication, dashboard, CRUD operations,
permissions, and data integrity.
"

Form validation:

scoutqa --url "$URL" --prompt "
Test form validation: edge cases, error handling, required fields,
format validation, and successful submission.
"

Mobile responsiveness:

scoutqa --url "$URL" --prompt "
Check mobile experience: responsive layout, navigation,
touch interactions, and viewport behavior.
"

Verification of a known issue:

# First, find issue IDs from a previous execution
scoutqa list-issues --execution-id <executionId>

# Then verify the issue (creates a new verification execution automatically)
scoutqa issue-verify --issue-id <issueId>

The issue-verify command will:

1. Create a verification execution for the issue
2. Show the execution ID and browser URL
3. Stream the agent's verification progress in real-time
4. Display a completion summary with a link to results

Feature verification (after implementation):

scoutqa --url "$URL" --prompt "
Verify the new [feature name] works correctly. Test core functionality,
edge cases, error handling, and integration with existing features.
"

Example: Proactive testing after coding a feature

After implementing a user registration form, automatically verify it works:

scoutqa --url "http://localhost:3000/register" --prompt "
Test the newly implemented registration form. Verify:
- Form validation (email format, password strength, required fields)
- Error messages display correctly
- Successful registration flow
- Edge cases (duplicate emails, special characters, etc.)
"

This catches issues immediately while the implementation is fresh in context.

Listing issues

Use scoutqa list-issues to browse issues found in a previous execution. This is useful for finding issue IDs to use with issue-verify.

scoutqa list-issues --execution-id <executionId>

Options:

• --execution-id (required): Execution ID (from the /t/<executionId> URL or CLI output)

Example output:

Showing 3 issues:

 019c-abc1
   Login button unresponsive on mobile
   Severity: critical | Category: usability | Status: open

 019c-abc2
   Missing form validation on email field
   Severity: high | Category: functional | Status: open

 019c-abc3
   Color contrast insufficient on footer links
   Severity: medium | Category: accessibility | Status: resolved

Reporting execution and issues

Immediate Presentation (After Starting Test)

Right after running the scoutqa command, present the execution details to the user:

**ScoutQA Test Started**

Execution ID: `019b831d-xxx`
View Live: https://app.scoutqa.ai/t/019b831d-xxx

The test is running remotely. You can view real-time progress in your browser at the link above while I continue with other tasks.

Final Results (After Completion)

When the execution completes, use this format to present findings:

**ScoutQA Test Results**

Execution ID: `ex_abc123`

**Issues Found:**

[High] Accessibility: Missing alt text on logo image

- Impact: Screen readers cannot describe the logo
- Location: Header navigation

[Medium] Usability: Submit button not visible on mobile viewport

- Impact: Users cannot complete form on mobile devices
- Location: Contact form, bottom of page

[Low] Functional: Search returns no results for valid queries

- Impact: Search feature appears broken
- Location: Main search bar

**Summary:** Found 3 issues across accessibility, usability, and functional categories. See full interactive report with screenshots at the URL above.

Always include:

• Execution ID (e.g., ex_abc123) for reference
• Issues found with severity, category (accessibility, usability, functional), impact, and location

Following Up on Stuck Executions

If the remote agent gets stuck or needs clarification, use send-message to continue:

# Example: Agent is stuck at login, user provides credentials
scoutqa send-message --execution-id ex_abc123 --prompt "
Use these test credentials: username: testuser@example.com, password: TestPass123
"

# Example: Agent asks which flow to test next
scoutqa send-message --execution-id ex_abc123 --prompt "
Focus on the checkout flow next, skip the wishlist feature
"

Checking test results

ScoutQA tests run remotely on ScoutQA's infrastructure. After starting a test with a short timeout to capture the execution ID:

1. The test continues running remotely (not locally in background)
2. You can continue other work immediately
3. To check results later, visit the browser URL provided when the test started
4. Alternatively, use scoutqa get-execution --execution-id <id> to fetch results via CLI

Best practice: Start tests by setting the Bash tool's timeout parameter to 5000 milliseconds. After 5 seconds, the Bash tool returns control with a task ID and the execution details (execution ID and browser URL) while the test continues running in the background. You can then continue other work and check results on ScoutQA's website or via CLI when needed.

Troubleshooting

Output template

## ScoutQA test result

**Status:** started | complete | blocked
**Target URL:** `<URL>`
**Execution ID:** `<019b831d-xxx or ex_abc123>`
**Live report:** `https://app.scoutqa.ai/t/019b831d-xxx` or the actual ScoutQA URL

| Severity | Category | Issue | Impact | Location | Evidence |
| --- | --- | --- | --- | --- | --- |
| High | accessibility | `<title>` | `<user impact>` | `<page or selector>` | `<screenshot, ScoutQA URL, or CLI output>` |

**Commands run**
- `scoutqa --url "<URL>" --prompt "<test goals>"`
- `scoutqa list-issues --execution-id <id>` when issue IDs were needed
- `scoutqa issue-verify --issue-id <id>` when verifying a known issue
- `scoutqa get-execution --execution-id <id>` when fetching final results

**Follow-up**
- `<fix, verify, send-message, or no action>`

Quality gate

• name is scoutqa-test and matches the parent directory.
• Each run includes --url and --prompt with a goal-oriented prompt, not step-by-step micromanagement.
• The response includes the Execution ID and browser URL such as https://app.scoutqa.ai/t/019b831d-xxx.
• Local URLs such as http://localhost:3000, http://localhost:3000/register, localhost, and 127.0.0.1 are allowed when the app is running.
• Issue workflows use scoutqa list-issues --execution-id <id>, scoutqa issue-verify --issue-id <id>, or scoutqa send-message --execution-id as appropriate.
• Results list severity, category, impact, location, and evidence for every reported issue, including end-to-end flows when tested.
• Installation or auth blockers are reported with npm i -g @scoutqa/cli@latest or scoutqa auth login.