> ## Agent Instructions > Spur is an AI-powered QA engineer that lets teams create and run automated end-to-end tests for web and mobile apps using natural language. > When answering questions about Spur, cite the relevant page from docs.spurtest.com. # Contact Us Source: https://docs.spurtest.com/additional-resources/contact-us Get in touch with the Spur team for support, questions, or feedback. ## Your Dedicated Account Manager Every Spur account comes with a dedicated account manager. They are your primary point of contact for onboarding, technical questions, and ongoing support. If you are unsure who your account manager is, reach out to us at **[founders@tryspur.dev](mailto:founders@tryspur.dev)** and we will connect you. ## Direct Line of Communication We keep communication fast and direct. Depending on your preference, you can reach us through: > **Google Workspace** > > Chat with us directly through Google Workspace for quick questions and async communication. > **WhatsApp** > > Message your account manager on WhatsApp for real-time support. > **Slack** > > Join a shared Slack channel with the Spur team for collaborative support. > **Email** > > Reach out to us at **[founders@tryspur.dev](mailto:founders@tryspur.dev)** for any questions or requests. ## Other Resources > **[Website](https://www.spurtest.com)** > > Visit spurtest.com to learn more about Spur. > **[Book a Demo](https://www.spurtest.com/book-a-demo)** > > Want a walkthrough of Spur? Book a demo with our team. > **[Community](https://www.linkedin.com/company/spur-test/)** > > Follow us on LinkedIn for updates and to connect with the team. # Deep Links Source: https://docs.spurtest.com/additional-resources/deep-links Use deep links in Spur to navigate directly to specific screens in your mobile app during testing. Deep links are URLs that navigate directly to a specific screen within a mobile app, bypassing the normal navigation flow. Instead of tapping through multiple screens to reach a destination, a deep link takes you straight there. The most common type is a **URI scheme** — a custom protocol registered by the app (e.g., `myapp://products/12345`). This is the primary method used in Spur. ## Why Use Deep Links in Tests? * **Skip repetitive navigation** — Jump straight to the screen you want to test instead of tapping through five screens to get there. * **Isolate test scope** — Test a specific feature without coupling to login and browsing flows. * **Test deep link behavior** — Verify that your app correctly handles incoming deep links. ## How It Works In native mobile tests, Spur triggers deep links using a [JavaScript injection](/authoring-tests/test-side-peek/step-types/javascript) step with the `[Deeplink]` label. You can add this step through the native commands UI in the test editor. > [!NOTE] > > To find your app's URI scheme, ask your development team or check the app's configuration files (`Info.plist` on iOS, `AndroidManifest.xml` on Android). ## Example ![Screenshot2026 03 05at2 52 46PM](https://mintcdn.com/spur/0tOedBOf3la96KgP/images/Screenshot2026-03-05at2.52.46PM.png?fit=max\&auto=format\&n=0tOedBOf3la96KgP\&q=85\&s=06a571bd2d8f29d226a73ad8a278049e) This test deep links from the home screen directly to a product collection page: ```text theme={null} Wait for the app to load If "Sign In" is displayed, tap Sign In and log in. Otherwise, skip this step. Navigate to the home page Cached Action: [Deeplink] {{ window.location = 'myapp://collections/womens-shop-all'; }} Wait 2 seconds Verify that "Women's Shop All" is displayed ``` The URI scheme `myapp://` routes to the app, and the path `collections/womens-shop-all` tells it which screen to display. > [!TIP] > > Always add a **wait** or **verify** step after a deep link to give the app time to load the target screen. ## Best Practices * Use the [recommended starting template](/getting-started/mobile-prompting#recommended-test-starting-template) to handle login and popups before triggering the deep link. * Always verify the expected screen loaded after the deep link. * If a test starts failing after an app update, check whether the URI scheme or path has changed. ## Related Resources * [Mobile Prompting Guide](/getting-started/mobile-prompting) — Best practices for writing native mobile test steps * [JavaScript Injection](/authoring-tests/test-side-peek/step-types/javascript) — The `Cached Action` step type used for deep links # IP Whitelisting Source: https://docs.spurtest.com/additional-resources/ip-whitelisting Allow Spur agent to access your application by whitelisting our IP addresses. ## Why Whitelist Spur's IPs? Spur runs automated browser tests against your application from our cloud infrastructure. If your staging, development, or production environment is behind a firewall, VPN, or IP-restricted access layer, you need to allow traffic from Spur's IP addresses so that tests can reach your application. > [!WARNING] > > If Spur's IPs are not whitelisted, test runs will fail with connection or timeout errors because our test runners cannot reach your application. ## Spur IP Addresses Contact the Spur team to get the current list of IP addresses you need to whitelist. > **[Contact Us](/additional-resources/contact-us)** > > Reach out to the Spur team to request the IP addresses for your allowlist. ## How to Whitelist The exact steps depend on where your application is hosted. Below are instructions for common providers. > **AWS Security Groups** > > **1. Open the EC2 Console** > > Go to the [EC2 Console](https://console.aws.amazon.com/ec2/) and select **Security Groups** from the left sidebar. > > **2. Select your security group** > > Find and click the security group attached to your application's instance or load balancer. > > **3. Edit inbound rules** > > Click **Edit inbound rules** and add a new rule: > > * **Type:** HTTPS (port 443) or HTTP (port 80), depending on your setup > * **Source:** Custom, then enter each Spur IP address > * **Description:** Spur test runners > > **4. Save** > > Click **Save rules**. Changes take effect immediately. > **Google Cloud Firewall Rules** > > **1. Open VPC Network** > > Go to the [VPC Firewall Rules](https://console.cloud.google.com/networking/firewalls) page in the Google Cloud Console. > > **2. Create a firewall rule** > > Click **Create Firewall Rule** and configure: > > * **Name:** `allow-spur-test-runners` > * **Direction:** Ingress > * **Targets:** Select the target tags or service accounts for your application > * **Source IP ranges:** Enter each Spur IP address > * **Protocols and ports:** Allow TCP on port 443 (and 80 if needed) > > **3. Save** > > Click **Create**. The rule applies within a few seconds. > **Azure Network Security Groups** > > **1. Open Network Security Groups** > > Go to **Network Security Groups** in the [Azure Portal](https://portal.azure.com/). > > **2. Select your NSG** > > Click the NSG associated with your application's subnet or network interface. > > **3. Add an inbound rule** > > Go to **Inbound security rules** and click **Add**: > > * **Source:** IP Addresses > * **Source IP addresses:** Enter each Spur IP address (comma-separated) > * **Destination port ranges:** 443 (and 80 if needed) > * **Protocol:** TCP > * **Action:** Allow > * **Name:** `AllowSpurTestRunners` > > **4. Save** > > Click **Add**. The rule takes effect shortly. > **Vercel / Netlify / Cloudflare** > > Most modern hosting platforms like Vercel, Netlify, and Cloudflare do not block incoming traffic by default. If you have configured IP-based access restrictions (such as Cloudflare Access or Vercel's IP allowlisting), add Spur's IP addresses to your allowlist through that platform's dashboard. > **Nginx or Apache** > > If you manage access control at the web server level, add Spur's IPs to your configuration. > > **Nginx** — add inside your `server` or `location` block: > > ```nginx theme={null} > allow ; > allow ; > # Add all IPs provided by the Spur team > ``` > > **Apache** — add inside your `` or `` block: > > ```apache theme={null} > Require ip > Require ip > # Add all IPs provided by the Spur team > ``` > > Reload your web server after making changes. ## Verifying the Setup After whitelisting, run a quick test from Spur to confirm connectivity: **1. Create or open a test** Navigate to any existing test or create a new one that targets the environment behind your firewall. **2. Run the test** Execute the test. If the first step (navigating to your URL) completes successfully, whitelisting is working. **3. Troubleshoot if needed** If the test fails with a timeout or connection error: * Confirm the correct IPs are whitelisted * Check that the allowed ports match your application (443, 80, or a custom port) * Verify there are no additional layers (VPN, WAF, CDN) that also require allowlisting > [!TIP] > > If your infrastructure uses a Web Application Firewall (WAF) in addition to network-level rules, you may need to add Spur's IPs to both the WAF allowlist and your firewall rules. ## What Spur Does NOT Access Spur operates strictly at the browser/UI layer. We never touch the systems behind your application. > **Source code & repositories** > > No access to your source code, repositories, or build systems. > **Back-end infrastructure** > > No access to back-end systems, databases, or internal infrastructure. > **Browser-only footprint** > > Nothing beyond the browser/UI layer — no software is installed on your systems. > **No customer PII** > > No customer PII is collected or stored beyond the test data you provide. ## Security Posture > **[SOC 2 in progress](https://app.vanta.com/tryspur.dev/trust/6bd89ygtkuvxrvbm0v6huw)** > > Full details and reports available in our [**Trust Center**](https://app.vanta.com/tryspur.dev/trust/6bd89ygtkuvxrvbm0v6huw). > **Dedicated, filterable IPs** > > Easy to scope and to exclude from your analytics. > **Encrypted by default** > > Data encrypted in transit and at rest; access limited to the surfaces you designate. > **Revocable instantly** > > Access is revocable instantly, at any time, by you. # Network & Console Monitoring Source: https://docs.spurtest.com/additional-resources/network-console-monitoring Use Log steps to assert against network requests and console logs during test execution. The Log step lets you validate what happens behind the scenes during a test run. Instead of checking what the user sees on screen (that's what [Verify](/authoring-tests/test-side-peek/step-types/verify) does), Log steps assert against **network requests** and **browser console output** — giving you visibility into API calls, error messages, and other under-the-hood behavior. You describe what you expect in plain language, and the Spur agent intelligently searches through the captured data to verify your assertion. It returns the matching evidence — the endpoint, a data snippet, and timestamp — so you can see exactly what it found. To learn how to add a Log step to your tests, see the [Log Step](/authoring-tests/test-side-peek/step-types/log/log-assertions) guide. ## Understanding the Result When a Log step completes, Spur expands the result to show exactly how it verified your assertion. Here's what each part means: ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/3.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=6e33b65a14e3c5db6e449b96a4c36bc3) * **Reasoning** — The agent restates your assertion to confirm what it set out to verify. * **Verification Analysis** — The agent breaks your assertion into a **primary subject** (the request or event type to find) and a **qualifier** (the specific condition to check within it). This is how the agent decides where to look and what to look for. * **What I Found** — A detailed breakdown of the matching evidence, including the endpoint, request method, status code, URL parameters, and any relevant payload data. This is the raw proof that supports the result. * **Conclusion** — A plain-language summary of whether the assertion passed or failed and why. * **Examined requests** — A clickable badge linking to the specific network request the agent inspected. Click it to jump directly to the full request details in the Network Logs panel. ## Use Cases ### Event & Analytics Tracking Analytics, tracking pixels, and third-party event calls break silently — they don't affect the UI, so regressions go unnoticed. Log steps let you confirm these events fire correctly during key user flows. > **Check tracking events** > > ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/4.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=8ba724c0d141808231e149c83a959a4b) > **Check external service calls** > > ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/5.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=4acbb9e249916f17695400bfb589963a) ### Validate API Status Codes & Responses The UI might show a success message even when the backend returns an error or unexpected data. Log steps let you check the actual API responses your application receives. > **Check status codes** > > ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/6.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=6b0784529ef77ad6c2b8d59fefa1ae5d) > **Check response body fields** > > ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/7.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=340a66bc7ed2db5f6e5391f4b75d0f8f) > **Detect server errors** > > ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/8.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=deb2b9b2fbdd7dfa91ca449413d9d393) ### Validate Request Payloads Confirm that your application sends the correct data to the backend — not just that the form submitted successfully. > **Check submitted data** > > ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/9.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=90a25456f97479474db028c2969f023c) > **Check request headers** > > ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/10.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=a7821b0a74f750366bdeeae4844dd5e6) ## What Data Is Available During every test run, Spur captures all **network requests** and **browser console output** from your application. The Log step agent searches through this data to evaluate your assertions, and you can also inspect it directly from the test results view. > **Network Requests** > > Every HTTP request and response, including: > > * URL, method, and status code > * Request and response headers > * Request body (POST data) > * Response body > * Timing and duration > * Error details (HTTP and network errors) > **Console Logs** > > All browser console output, including: > > * Log messages (`console.log`, `console.warn`, `console.error`) > * JavaScript errors and stack traces > * Source file locations > * Timestamps ## Viewing Logs in Test Results After a test run completes, you can inspect the raw network and console data directly from the results view. ### Network Logs ![](https://mintcdn.com/spur/mhIYYsnOSr0Pa3An/images/Log/req-badge.gif?s=95102a8f9869b0aa7a58c0c29199b46b) You can inspect the exact requests examined by the Spur agent by clicking the examined request in the step result. ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/11.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=faa2579648ed3d597207752cd8a770e1) You can filter network logs by status code, HTTP method, or URL pattern. Click any entry to see full request and response details including headers and body content. ### Console Logs ![](https://mintcdn.com/spur/ouU-TQ6bqhYcyB2r/images/Log/12.png?fit=max\&auto=format\&n=ouU-TQ6bqhYcyB2r\&q=85\&s=6937213bce6b095781fb1bd9c7dede0c) Console logs display the message type, timestamp, content, and source location. You can search and filter logs to find specific entries. ## Best Practices ### Writing Effective Assertions > **Pair with Verify Steps** > > Use a Verify step to check what the user sees, then follow it with a Log step to confirm the right data was sent and received. Together they give you full coverage — UI and backend in one test. > > ![](https://mintcdn.com/spur/mhIYYsnOSr0Pa3An/images/Log/13.png?fit=max\&auto=format\&n=mhIYYsnOSr0Pa3An\&q=85\&s=3937afdd055d66cbd1283f99467d20f4) > **Give Context When You Can** > > Mention the specific assertion you want to perform: network or console. For example, "Validate the payload for collect-tag contains event\_code" should specify whether the agent needs to look for it in the console output or the network requests. So this should be rewritten as "Validate in the console ..." > **One Assertion per Step** > > Keep each Log step focused on a single check. Instead of "confirm the API returned 200 and the tracking event fired," split that into two separate Log steps. This makes results easier to interpret and debug. > > ![](https://mintcdn.com/spur/mhIYYsnOSr0Pa3An/images/Log/14.png?fit=max\&auto=format\&n=mhIYYsnOSr0Pa3An\&q=85\&s=6b018732847ba2492aebb13e7ae7adc1) > **The Agent Handles the Rest** > > You don't need to know the exact request format, header names, or payload structure. Describe the behavior you expect and the agent will figure out where and how to look for it. ### When to Use Log Steps > **Add to Regression Suites** > > Log steps are great for regression testing. Add them to your existing tests to make sure API behavior doesn't silently change between releases. > **Catch What Users Can't See** > > The UI might gracefully handle a 500 error or swallow a failed analytics call. Log steps surface these hidden issues that would otherwise go unnoticed. > **Guard Critical Flows** > > Add Log steps to your most important user journeys — signup, form submissions, data updates, key workflows. These are the flows where a broken API call has real consequences. > **Monitor Third-Party Integrations** > > Analytics, ad pixels, and third-party scripts break silently. Use Log steps to verify these calls fire on the right pages so you catch regressions early. ## Limitations * **Logs are analyzed after capture, not in real-time.** The agent evaluates network and console data that has already been recorded during the test run. It does not monitor logs as they stream in. * **Late-firing requests may not be captured.** If a network request or event fires after the test step has finished executing, it may not be included in the data the agent searches through. This can affect assertions on deferred or asynchronous calls that take a long time to complete. ## Troubleshooting > **Log step reports Not Found but the request was made** > > Make sure your assertion names the endpoint or event clearly. For example, instead of "Confirm the homepage event fired," try "Confirm the request to **/collect** contains **homepage** in the payload." Being specific about the endpoint helps the agent find the right request. > **Log step passes but shouldn't have** > > Try making your assertion more specific. Instead of "check the API response is correct," specify the exact endpoint, field, and expected value. A vague assertion could match unrelated data. > **Log step fails but the UI looks correct** > > This usually means there's a real backend issue the UI is masking. Check the network logs panel in the test results to see the actual API responses. > **Cannot find the Log step type** > > Log steps are only available for web tests. If you're authoring a native/mobile test, this step type will not appear in the step menu. # Spur for Data Science Teams Source: https://docs.spurtest.com/additional-resources/spur-for-data-science-teams Automate analytics event validation, tracking QA, and data quality monitoring — without writing code or inspecting DevTools manually. If you work in data science, analytics, or marketing technology, you know the pain: every release cycle means hours of manually checking that tracking events fire correctly, payloads contain the right fields, and downstream data pipelines receive clean inputs. When something breaks, it often goes undetected for days or weeks — leading to bad dashboards, broken attribution, and lost revenue. Spur automates this entire validation process. This guide explains how it works, why it matters, and how to get started — even if you have never automated anything before. *** ## The Problem You Are Solving Analytics and tracking implementations break silently. Unlike a broken button or a crashed page, a missing tracking event produces no visible error. The user experience looks fine. But behind the scenes: * Events stop firing after a code deploy * Required fields disappear from payloads * Data types change (string becomes number, casing shifts) * Third-party pixels and affiliate tags get dropped * UTM parameters are stripped during redirects These failures are invisible to end users — but they corrupt your data, break attribution models, and undermine every decision made from that data. ### How Teams Typically Catch These Issues Today ```mermaid theme={null} graph TD A["Open Chrome DevTools"] --> B["Navigate to page / complete flow"] B --> C["Search console or network tab for events"] C --> D["Manually inspect each payload field"] D --> E["Screenshot as evidence"] E --> F["Cross-reference with analytics platform"] F --> G["Repeat for every region, brand, browser, environment"] G --> H["File a ticket if something is wrong"] style A fill:#fee,stroke:#c33 style G fill:#fee,stroke:#c33 ``` This process has fundamental limitations: * **It does not scale.** A site with 30+ tracked events across multiple regions, brands, and browsers creates thousands of combinations to check. * **It is error-prone.** Humans miss subtle changes — a field that switched from lowercase to uppercase, a value that went from `"12.99"` to `12.99`. * **It is reactive.** Manual QA happens after deploys. Issues often reach production before anyone checks. * **It consumes analyst time.** Every hour spent in DevTools is an hour not spent on actual data analysis and strategy. *** ## How Spur Automates This Spur replaces the manual DevTools process with an automated browser agent. Here is how it works at a high level: ```mermaid theme={null} graph LR A["You define what to validate"] --> B["Spur opens a real browser"] B --> C["Agent navigates your site like a real user"] C --> D["All network traffic is captured automatically"] D --> E["Agent validates payloads against your expectations"] E --> F["Results: pass/fail with evidence"] ``` ### What the Agent Actually Does **1. Opens a real browser** Spur launches a real Chrome or Safari browser — not a simulator. It behaves exactly like a user visiting your site, including cookies, consent banners, and third-party scripts. **2. Performs the user flow** The agent navigates to the right page, clicks through the flow (view a product, add to cart, complete checkout, etc.), and triggers the same events a real user would. **3. Captures all network traffic** While the agent navigates, every HTTP request and response is captured in real time — including analytics events, tracking pixels, API calls, and third-party scripts. You can inspect this data yourself in the [Network & Console Monitoring](/additional-resources/network-console-monitoring) panel after every run. **4. Validates against your expectations** You tell Spur what to check using plain language. For example: *"Confirm the product\_detail event contains product\_id, product\_name, and price as a number."* The agent searches the captured network data, finds the matching request, and validates field by field. See [how the agent breaks down and verifies assertions](/additional-resources/network-console-monitoring#understanding-the-result) to understand exactly what happens behind the scenes. **5. Reports results with evidence** Each validation produces a clear pass or fail, along with the actual data it found — including the endpoint, request method, status code, and payload snippet. You can click through to the [full network log](/additional-resources/network-console-monitoring#viewing-logs-in-test-results) for any examined request. No digging through DevTools required. *** ## Key Concepts ### Events and Payloads An **event** is a network request your site sends to an analytics platform (like Adobe Analytics, Google Analytics, Tealium, Segment, etc.) when something happens — a page loads, a user clicks a button, an order completes. Each event carries a **payload**: a bundle of data fields describing what happened. For example, a product view event might include: ```json theme={null} { "event_name": "product_detail", "product_id": "ABC-12345", "product_name": "Classic Oxford Shirt", "price": 68.00, "currency": "USD", "category": "Men > Shirts", "brand": "Main Brand", "color": "Blue", "size": "M", "in_stock": true } ``` When Spur validates an event, it checks: * **Did the event fire at all?** (The most common failure — roughly 50% of issues) * **Are all required fields present?** (About 40% of issues) * **Are the values in the correct format?** (About 10% — wrong types, casing, etc.) ### Log Steps In Spur, you validate events using **Log steps**. A Log step is a plain-language instruction that tells the agent what to check in the captured network data. You write it like you would explain it to a colleague: ``` Log Confirm the product_detail event fired and contains product_id, product_name, and price as a number ``` The agent handles the rest — finding the right request, parsing the payload, and checking each field. > **[Network & Console Monitoring](/additional-resources/network-console-monitoring)** > > See how Spur captures network traffic and console output, how the agent verifies your assertions, and how to inspect raw logs in test results. > **[Log Assertions — Full Reference](/authoring-tests/test-side-peek/step-types/log/log-assertions)** > > Technical reference for writing Log steps, adding them to tests, and troubleshooting. *** ## Thinking Through Your Validation Strategy Before building tests, take a step back and think about what matters most. Not every event needs the same level of scrutiny. ### Prioritize by Business Impact ```mermaid theme={null} graph TD A["All Tracked Events"] --> B{"Revenue impact?"} B -->|Yes| C["P0 — Validate every deploy"] B -->|No| D{"Decision-making impact?"} D -->|Yes| E["P1 — Validate weekly"] D -->|No| F{"Compliance / legal?"} F -->|Yes| G["P0 — Validate every deploy"] F -->|No| H["P2 — Validate monthly"] style C fill:#fcc,stroke:#c33 style G fill:#fcc,stroke:#c33 style E fill:#fec,stroke:#c93 style H fill:#cfc,stroke:#3c3 ``` **P0 — Must validate every deploy:** * Order confirmation / purchase events (revenue attribution) * Affiliate and commission tracking (direct revenue impact) * Consent and privacy events (legal compliance) * Core conversion events (signup, subscription) **P1 — Validate weekly or after relevant changes:** * Product detail page views (merchandising analytics) * Search and navigation events (UX analytics) * Campaign attribution parameters (marketing ROI) **P2 — Validate monthly or on major releases:** * Page scroll and engagement events * Feature usage tracking * A/B test instrumentation ### Map Your Validation Matrix For each priority event, consider the dimensions you need to cover: | Dimension | Example | | - | - | | **Regions** | US, UK, EU, APAC | | **Brands / Properties** | Main brand, sub-brands | | **Browsers** | Chrome, Safari, mobile | | **Environments** | Staging, production | | **User states** | Logged in, guest, returning | Spur runs all of these combinations in parallel — what takes hours manually takes minutes automated. *** ## Building Your First Validation Test Here is how to approach it, step by step. ### Step 1: Pick your highest-priority event Start with the one event that would cause the most damage if it broke. For most teams, this is either: * **Purchase / order confirmation** — revenue and attribution * **Main page view event** — highest volume, most dependencies ### Step 2: Document what "correct" looks like Write down (or gather from your tech spec): * The event name or endpoint * Every required field * The expected data type for each field (string, number, boolean) * Any format requirements (e.g., currency as decimal, IDs as strings) ### Step 3: Create the test in Spur Build a test that: 1. Navigates to the page or completes the user flow 2. Uses **[Log steps](/additional-resources/network-console-monitoring)** to validate the event payload Example test structure: ``` 1. Navigate to a product detail page 2. Verify the product page loaded (UI check) 3. Log Confirm the product_detail event fired 4. Log Confirm product_detail contains product_id as a non-empty string 5. Log Confirm product_detail contains price as a number greater than 0 6. Log Confirm product_detail contains product_name, category, and brand ``` ### Step 4: Run and iterate Run the test against your staging environment first. Review the results using the [Network & Console Monitoring](/additional-resources/network-console-monitoring#viewing-logs-in-test-results) panel: * Did the agent find the right event? Click the examined request badge to verify. * Are there false positives (flagging things that are actually fine)? * Are there fields you forgot to include? Tune your Log step assertions until the test reliably catches real issues and ignores noise. See [best practices for writing effective assertions](/additional-resources/network-console-monitoring#writing-effective-assertions) for tips. ### Step 5: Schedule and expand Once validated, schedule the test to run: * **After every deploy** — catch regressions immediately * **Daily** — catch issues from third-party script updates or infrastructure changes Then repeat for your next priority event. *** ## Common Validation Patterns ### Analytics Event Validation The most common use case. Confirm that tracking events fire with the correct payload during key user flows. ``` Log Confirm the purchase event contains order_id, revenue as a number, and items as an array with at least one entry ``` ### Affiliate and UTM Parameter Validation UTM parameters and affiliate tokens in URLs drive campaign attribution and commission payouts. If they are dropped or malformed at any point in the funnel, revenue goes untracked. ``` Log Confirm the request URL to the affiliate endpoint contains utm_source, utm_medium, and utm_campaign parameters ``` ### Data Layer Validation Many analytics implementations use a data layer (like Tealium's `utag.data` or Google's `dataLayer`) that is accessible in the browser. Spur can capture and validate these attributes as part of the same test flow. ``` Log Confirm the data layer contains user_segment and page_type with non-empty values ``` ### Cross-Platform Consistency Run the same validation across Chrome, Safari, and mobile to ensure events fire consistently across all platforms. *** ## What Changes With Automation | | Manual | Automated with Spur | | - | - | - | | **Time per validation cycle** | 2–4 hours | 5–10 minutes | | **Coverage** | Spot-checking (\~30%) | 100% — all fields, every run | | **Multi-region** | Each tested separately | All regions in parallel | | **Multi-browser** | Manual switching | Chrome, Safari, mobile in parallel | | **Error detection** | Visual inspection — easy to miss subtle issues | AI flags exact discrepancies with expected vs. actual | | **Documentation** | Manual screenshots | Structured reports with network traces | | **Frequency** | Ad-hoc after releases | Scheduled daily + on-demand | | **Detection speed** | Days to weeks (or never) | Within minutes of a deploy | *** ## Getting Started Now that you understand the fundamentals of how analytics validation works with Spur, dive into the feature documentation to see exactly how to use it: > **[Network & Console Monitoring](/additional-resources/network-console-monitoring)** > > See how validation results look in practice — assertion breakdowns, evidence, and raw network/console logs. > **[Log Assertions Reference](/authoring-tests/test-side-peek/step-types/log/log-assertions)** > > Technical reference for adding Log steps to your tests. > **[Create Your First Test](/getting-started/first-test)** > > Step-by-step guide to building and running your first Spur test. > **[Running Tests](/running-tests/run-modal/run-modal)** > > Execute and monitor your validation tests across environments. > **[CI/CD Integration](/running-tests/CICD)** > > Trigger validation tests automatically on every deploy. > **[Scheduling](/running-tests/scheduler)** > > Set up recurring validation runs on a daily or weekly cadence. # Azure SSO Source: https://docs.spurtest.com/additional-resources/sso-providers/azure-sso ## Overview Spur uses Supabase Auth as its authentication provider, which enables secure OAuth 2.0-based SSO. Users can sign in to Spur using their existing identity provider credentials — no separate Spur password required. ## How SSO Works in Spur Spur's SSO uses the OAuth 2.0 / OpenID Connect (OIDC) protocol — the modern industry standard for federated authentication. Here's the flow when a user signs in: **1. Initiate sign-in** The user clicks **Sign in with Microsoft** on the Spur login page. **2. Redirect to Microsoft** Spur redirects to Microsoft's authentication endpoint. **3. Authenticate** The user authenticates with their Microsoft credentials (and MFA, if configured by your organization). **4. Token exchange** Microsoft returns a secure token to Spur confirming the user's identity. **5. Session created** Spur creates or resumes the user's session. No Spur-specific password is ever set or stored. ## What Spur Supports | Item | Details | | - | - | | **Protocol** | OAuth 2.0 / OpenID Connect (OIDC) | | **Identity Provider** | Microsoft Azure Entra ID (and Google) | | **Tenant type** | Multi-tenant — any Azure Entra organization can connect without per-tenant configuration on Spur's side | | **Account types** | Organizational accounts (work/school). Personal Microsoft accounts are not in scope. | | **User provisioning** | Just-in-time — a Spur account is automatically created on first successful SSO login | | **MFA enforcement** | Honored — if your Azure tenant requires MFA, it will be enforced before Spur grants access | | **Scopes requested** | `openid`, `email`, `profile` (read-only identity data only) | ## Current Limitations The following are not supported at this time. If any of these are requirements for your organization, please reach out to discuss your use case. * **SAML 2.0** — Spur uses OAuth 2.0/OIDC only, not SAML. * **Per-tenant app registration** — Spur uses a single multi-tenant Azure app registration rather than a dedicated registration per customer. ## What Your Organization Needs to Do For most organizations, no setup is required. Users can sign in with their Microsoft account immediately once Spur enables the provider. ### If Your Tenant Restricts Third-Party App Access Some organizations configure Azure Entra to require admin approval before users can sign into third-party applications. If this applies to your tenant, an Azure admin will need to: **1. Open Enterprise Applications** Navigate to **Azure Portal** → **Microsoft Entra ID** → **Enterprise Applications**. **2. Find Spur** Locate the Spur application. It will appear after the first sign-in attempt, or can be added proactively. **3. Grant admin consent** Grant admin consent for the scopes Spur requests: `openid`, `email`, and `profile`. > [!TIP] > > This is a one-time action that unblocks all users in your organization without each person needing to consent individually. ### Restricting Access to Specific Users or Groups If you want to limit which employees in your organization can access Spur via SSO, an Azure admin can: 1. In the Spur enterprise application in Entra, enable **User assignment required**. 2. Assign specific users or Azure groups who are permitted to sign in. > [!WARNING] > > Without this configuration, any user in your organization's Azure tenant can sign into Spur. ## Data & Security Spur requests the minimum necessary permissions to authenticate your users. Spur does not request access to email content, calendar, files, or any other Microsoft 365 data. > **Scopes Spur Requests from Microsoft** > > * **openid** — Required to use OpenID Connect for authentication > * **email** — The user's email address, used as their Spur account identifier > * **profile** — Basic profile info (name), used to populate the user's Spur profile ## Questions? If you have questions about SSO configuration, compliance requirements, or want to discuss your organization's specific setup, please contact your Spur account representative. > **[Contact Us](/additional-resources/contact-us)** > > Reach out to the Spur team for SSO support. # Google SSO Source: https://docs.spurtest.com/additional-resources/sso-providers/google-sso ## Overview Spur uses Supabase Auth as its authentication provider, which enables secure OAuth 2.0-based SSO. Users can sign in to Spur using their existing Google Workspace credentials — no separate Spur password required. ## How SSO Works in Spur Spur's SSO uses the OAuth 2.0 / OpenID Connect (OIDC) protocol — the modern industry standard for federated authentication. Here's the flow when a user signs in: **1. Initiate sign-in** The user clicks **Sign in with Google** on the Spur login page. **2. Redirect to Google** Spur redirects to Google's authentication endpoint. **3. Authenticate** The user authenticates with their Google credentials (and MFA, if configured by your organization). **4. Token exchange** Google returns a secure token to Spur confirming the user's identity. **5. Session created** Spur creates or resumes the user's session. No Spur-specific password is ever set or stored. ## What Spur Supports | Item | Details | | - | - | | **Protocol** | OAuth 2.0 / OpenID Connect (OIDC) | | **Identity Provider** | Google Workspace | | **Account types** | Google Workspace accounts (organizational). Personal Gmail accounts are not supported — this is enforced by configuring the OAuth app's user type to **Internal** in the Google Cloud Console. | | **User provisioning** | Just-in-time — a Spur account is automatically created on first successful SSO login | | **MFA enforcement** | Honored — if your Google Workspace requires MFA, it will be enforced before Spur grants access | | **Scopes requested** | `openid`, `email`, `profile` (read-only identity data only) | ## Current Limitations The following are not supported at this time. If any of these are requirements for your organization, please reach out to discuss your use case. * **SAML 2.0** — Spur uses OAuth 2.0/OIDC only, not SAML. ## What Your Organization Needs to Do For most organizations, no setup is required. Users can sign in with their Google Workspace account immediately. ### If Your Organization Restricts Third-Party App Access Some organizations configure Google Workspace to restrict which third-party apps users can sign into. If this applies to your organization, a Google Workspace admin will need to: **1. Open the Admin Console** Navigate to the [Google Admin Console](https://admin.google.com) → **Security** → **Access and data control** → **API controls**. **2. Manage Third-Party App Access** Click **Manage Third-Party App Access** and find or add the Spur application. **3. Grant access** Set the app to **Limited** so that users in your organization can sign in without individual approval. This allows the app to request access to unrestricted Google data only, which is sufficient for SSO. > [!TIP] > > This is a one-time action that unblocks all users in your organization without each person needing to consent individually. ### Restricting Access to Specific Users or Groups If you want to limit which employees in your organization can access Spur via SSO, a Google Workspace admin can: 1. In the Google Admin Console, navigate to the Spur app under **API controls**. 2. Restrict the app to specific organizational units (OUs) or groups. > [!WARNING] > > Without this configuration, any user in your Google Workspace organization can sign into Spur. ## Data & Security Spur requests the minimum necessary permissions to authenticate your users. Spur does not request access to Gmail, Google Drive, Calendar, or any other Google Workspace data. > **Scopes Spur Requests from Google** > > * **openid** — Required to use OpenID Connect for authentication > * **email** — The user's email address, used as their Spur account identifier > * **profile** — Basic profile info (name), used to populate the user's Spur profile ## Questions? If you have questions about SSO configuration, compliance requirements, or want to discuss your organization's specific setup, please contact your Spur account representative. > **[Contact Us](/additional-resources/contact-us)** > > Reach out to the Spur team for SSO support. # User Roles Source: https://docs.spurtest.com/additional-resources/user-roles Understand the difference between admin and member roles, and how admins manage your team in Spur. ## Overview Spur has two user roles: | Role | Permissions | | - | - | | **Admin** | Everything a member can do, plus: invite new users, promote members to admin, and demote admins to member. | | **Member** | Author, run, and analyze tests. Cannot manage team membership or roles. | > [!NOTE] > > Every account needs at least one admin. Removing users from an account is not yet supported — if you need a user removed, [contact the Spur team](/additional-resources/contact-us). > [!NOTE] > > If your team does not yet have an admin or you need someone promoted, email [andy@tryspur.dev](mailto:andy@tryspur.dev). ## Managing Your Team All team management happens on the [Account page](https://app.spurtest.com/account). Only admins can see the team management controls. ### Invite a New User **1. Open the Account page** Go to [app.spurtest.com/account](https://app.spurtest.com/account). **2. Add a user** Enter the new user's email address and submit. **3. User receives an email** Spur creates an account for the user and emails them a link to set their password. Once they set a password, they can sign in. > [!TIP] > > New users are added as **members** by default. Promote them to admin afterward if they need team management permissions. ### Promote a Member to Admin On the [Account page](https://app.spurtest.com/account), find the member in the team list and change their role to **Admin**. The change takes effect immediately. ### Demote an Admin to Member On the [Account page](https://app.spurtest.com/account), find the admin in the team list and change their role to **Member**. Make sure at least one admin remains on the account. ## Related > **[SSO Providers](/additional-resources/sso-providers/google-sso)** > > Set up Google or Azure SSO so users can sign in with their organization's credentials. > **[Contact Us](/additional-resources/contact-us)** > > Need a user removed or have a role question we haven't covered? Reach out. # Analysis Overview Source: https://docs.spurtest.com/analysing-tests/analysis-overview Understand where to find your test results and what you can do with them. ## Overview Once your tests have run, Spur gives you several ways to view, analyze, and act on the results. Whether you need a quick health check across all your suites or a deep dive into a specific test plan run, everything is accessible from the Spur dashboard. ## Where to Find Your Results > **[Test Plan Review (Recommended)](/analysing-tests/test-plan-review)** > > The best way to work through your results. The Test Plan Review flow walks you through every failure and warning in a test plan run, letting you triage each result, edit tests inline, and create bug tickets without leaving Spur. Start here if you run tests through test plans. > **[Test Overview Page](/analysing-tests/test-overview-page)** > > A bird's-eye view of the latest result for every test across all your suites. Use this to quickly spot which tests are failing, passing, or raising warnings. Results are split by viewport, environment, and browser. ## What You Can Do with Results Once you have your results, Spur provides several ways to take action: ### Share Results Share test results with your team without requiring a Spur login. Shareable links give the recipient full access to the test result, including steps, video replay, console logs, and network logs. > **[Shareable Links](/analysing-tests/shareable-links)** > > Generate a link to any test result and send it to anyone on your team. ### Create Bug Tickets Turn failures into trackable issues in your project management tool. Spur auto-populates tickets with failure details, screenshots, and reproduction steps. > **[Jira](/analysing-tests/integrations/jira)** > > Create Jira tickets directly from test failures. > **[Linear](/analysing-tests/integrations/linear)** > > Create Linear issues directly from test failures. > **[Azure DevOps](/analysing-tests/integrations/azure-devops)** > > Create Azure DevOps work items directly from test failures. ### Get Notified Set up alerts so your team is informed about test results automatically, whether through Slack messages or email notifications. > **[Slack Alerts](/analysing-tests/integrations/slack)** > > Receive test result notifications in your Slack channels. > **[Email Alerts](/analysing-tests/integrations/email)** > > Get email notifications for test outcomes. ### Debug with Spur MCP Pass shareable links to the Spur MCP to analyze test results and help debug failures directly in your development workflow. > **[Spur MCP](/analysing-tests/mcp/spur-mcp)** > > Use AI-powered analysis to understand and fix test failures. # Azure DevOps Work Items Source: https://docs.spurtest.com/analysing-tests/integrations/azure-devops Connect Azure DevOps to file work items from test results, set project and field defaults, and read work items in Spur AI. ## Overview Connect Azure DevOps to turn test results into work items. Spur fills in the failure reason, the steps to reproduce, and a link back to the run, then keeps the work item linked to the test. Once connected, you can: * File a work item from any test result, or while working through a test plan run. * Have Spur file one for you automatically every time a test finishes. * Reference a work item in Spur AI, so it can read the ticket before writing tests. > [!NOTE] > > Only an admin can connect or configure Azure DevOps. Once it is set up, anyone on your team can file work items. See [User Roles](/additional-resources/user-roles). ## Before you start You need: * An Azure DevOps organization on `dev.azure.com`. * A personal access token. Spur files every work item as the person who created the token, so pick an account your team is happy to see as the author. * That person added to the **Project Administrators** group on each project you want Spur to file into. ## Grant project access Add the person who will create the token to the **Project Administrators** group on every project Spur files into. That membership carries the **Create tag definition** permission. Without it, you can still pick tags that already exist, but adding a new tag makes Azure DevOps reject the whole work item. **1. Open Project settings in Azure DevOps** Go to the project you want Spur to file into, then click **Project settings** in the bottom left corner of the page. **2. Open Permissions** Click **Permissions** in the Project settings menu, then click the **Project Administrators** group in the list. **3. Add the person who will create the token** Open the **Members** tab, click **Add**, and add them. Repeat this for every project Spur files into. ## Create a personal access token In Azure DevOps, open your user settings and create a token for the organization you want to connect. Set an expiration date — Azure DevOps allows a maximum of one year, and your organization can set a policy capping it lower. Then choose **Custom defined**, click **Show all scopes**, and grant these three: | Scope | Access | Why Spur needs it | | - | - | - | | Work Items | Read & write | Creates work items from test results, and reads linked work items so their status stays current in Spur. | | Project and Team | Read | Lists your projects and work item types, so the filing form matches your organization. | | Graph | Read | Looks up assignable users, so you can pick an assignee. | Grant nothing beyond these three. Spur writes to Azure DevOps only when a work item is filed — it never changes your process templates, work item types, or field definitions. > [!WARNING] > > Every personal access token expires, and Azure DevOps caps the lifetime at one year — so this integration needs a new token at least annually. When the token expires, filing stops until an admin pastes a replacement. Set a reminder ahead of the date you chose. ## Connect Azure DevOps **1. Open the integrations page** Click the user profile button in the top right from any page, then click **Integrations**. Find the **Azure DevOps** card and click **Connect**. **2. Enter your organization** In **Organization**, enter your organization name or its full `dev.azure.com` URL — for example `spurtestorg` or `https://dev.azure.com/spurtestorg`. **3. Paste your token** Paste the personal access token into **Personal access token**, then click **Connect**. Spur checks the token against your organization before saving it, so a token with the wrong scopes fails here rather than the first time someone files a work item. Once you have entered your organization, the dialog also shows a **Create a token in Azure DevOps** link that opens the token page for it. ## Set your defaults Once connected, click **Settings** on the Azure DevOps card to choose what every new work item starts with. ![Azure DevOps Integration Settings dialog marked Active, showing an Organization field set to a dev.azure.com URL, a personal access token field reading "Token set for this organization", Default project and Default work item type dropdowns, an Automatic filing toggle with "When a test fails" and "When a test passes" both checked, and a Field defaults list of Iteration Path, Area Path, State, Tags, and Priority](https://mintcdn.com/spur/y0_mHZCb7iwRmlcM/images/Integrations/AzureDevOps/integration-settings.png?fit=max\&auto=format\&n=y0_mHZCb7iwRmlcM\&q=85\&s=f0d7ed03316f2e56408fa823e98b893c) ### Default project and work item type Pick the **Default project** your team files bugs into, then the **Default work item type** to file — `Issue` and `Bug` are the common choices. Both start at **No default**, which means whoever files a work item picks them each time. Pick the project first. The work item types on offer come from that project, and so do the field defaults below. ### Field defaults **Field defaults** are the values every new work item starts with. Whoever files the work item can change them before submitting it. Which fields appear here comes from your Azure DevOps process, so your list will not match the screenshot above. A star marks a field that Azure DevOps requires before it will accept a work item. You can leave a starred field blank — Spur asks for it in the filing form instead. ### Automatic filing Turn on **Automatic filing** to have Spur create a work item every time a test finishes, without anyone opening the filing form. Choose **When a test fails**, **When a test passes**, or both. Spur files one work item per test result, and does not file a second one if that result is processed again. > [!WARNING] > > Automatic filing has no one to prompt for a missing value, so every starred field needs a default. When one is missing, the settings dialog lists the field by name — for example, `Automatic filing will skip work items until you set a default for: State.` Until you fill that field in, Spur files nothing automatically. > [!NOTE] > > Each work item links back to its test result through a shareable link, so anyone with that link can view the run without signing in to Spur. See [Shareable Links](/analysing-tests/shareable-links). Click **Save Changes** to apply your settings. ## File a work item from a test result **1. Open the Share menu** On a test result, click **Share**, then click **Azure DevOps** under **Create a Ticket**. ![The Share menu open on a test result, showing a Share Test Result toggle with a copyable link, an Export PDF Report button, and Jira and Azure DevOps buttons side by side under the Create a Ticket heading](https://mintcdn.com/spur/y0_mHZCb7iwRmlcM/images/Integrations/AzureDevOps/share-menu-create-a-ticket.png?fit=max\&auto=format\&n=y0_mHZCb7iwRmlcM\&q=85\&s=415fa84275cd21d0c01174a972b3dacb) **2. Review what Spur filled in** Spur writes the title and the description from the test result: * **Title** — the name of the test. * **Description** — a link back to the run, the failure reason, the step the test failed on, the steps to reproduce, and the suite, test, run time, and test type. Edit either one before filing. ![The New Azure DevOps Work Item form, with Switch to Jira and Switch to Linear buttons in the header, an editable title, and a description containing a link to the run, a failure reason, the failed step, steps to reproduce, and the suite, test, run time, and test type, beside a Details panel showing Project, Work item type, Assignee, and State, and an Optional Fields panel showing Iteration Path, Area Path, Tags, and Priority](https://mintcdn.com/spur/y0_mHZCb7iwRmlcM/images/Integrations/AzureDevOps/new-work-item-form.png?fit=max\&auto=format\&n=y0_mHZCb7iwRmlcM\&q=85\&s=0c61aa1eecad6614dfe186a576f893fa) **3. Set the work item details** Under **Details**, pick the **Project** and **Work item type**, then set the **Assignee**. Every field your process requires appears here too, marked with a star and pre-filled with the default you saved. Anything your process treats as optional is grouped under **Optional Fields**. Where Azure DevOps has a description for a field, Spur shows it underneath — so **State**, for example, explains what each value means in your process. **4. Create the work item** Click **Create Work Item**. Spur files it, links it to the test, and shows you the new work item ID. > [!TIP] > > With more than one issue tracker connected, the form header carries **Switch to Jira** and **Switch to Linear** buttons. Switching keeps the title and description you have already edited. ## File a work item from Test Plan Review You can file work items without leaving [Test Plan Review](/analysing-tests/test-plan-review). Mark a result as a bug, then choose **Create Azure DevOps Work Item**. Spur opens the filing form described above, filled in from that result. To cover several failures with one work item, select those results first. Spur files a single work item and links it to every test you selected. ## Read work items in Spur AI With Azure DevOps connected, [Spur AI](/analysing-tests/spur-ai-chat) can read your work items. Paste a work item URL, or give it the ID — "write tests for work item 412" is enough, and you do not have to say which tracker it lives in. Spur AI reads the title, description, state, assignee, priority, tags, parent and child work items, comments, and any images in the description. Use it to write tests from a work item, or to check whether a test you already have still covers what the work item asks for. ## View and sync linked work items A work item you have filed appears in the test's share panel with its ID and current state. Click **Sync** to pull the latest title, state, and assignee from Azure DevOps — useful once the work item has been reassigned, triaged, or closed. ## Troubleshooting ### Replace a token, or move to another organization Open **Settings** on the Azure DevOps card, paste a new token into **Personal access token**, and click **Save Changes**. Your default project, work item type, and field defaults are kept. To connect a different organization, change **Organization** and paste a token for that organization in the same save. Your saved defaults are cleared, because projects and fields do not carry from one organization to another. ### Error messages | What you see | What to do | | - | - | | Azure DevOps rejected the PAT | The token has expired, was revoked, or belongs to a different organization. Paste a replacement and save. | | The PAT cannot access any Azure DevOps projects | The token is missing the **Project and Team: Read** scope, or the person who created it has no access to any project in the organization. | | The PAT cannot access any Azure DevOps work item types | The person who created the token cannot read the project you picked. Check their project membership. | | Azure DevOps denied this request, mentioning `TF401289` | The person who created the token is missing the **Create tag definition** permission. Add them to **Project Administrators**, or use only tags that already exist. | | Azure DevOps could not find the selected organization, project, or work item type | The project or work item type was renamed or deleted in Azure DevOps. Pick a current one in the settings dialog and save. | | Azure DevOps rate limit reached | Azure DevOps is throttling your organization. Wait a moment, then try again. | | This process requires unsupported fields | Your process requires a field of a type Spur cannot fill. [Contact the Spur team](/additional-resources/contact-us) with the field name. | | Automatic filing will skip work items until you set a default | A required field has no default. Set one under **Field defaults**, or turn automatic filing off. | | Created the work item, but Spur could not link it | The work item exists in Azure DevOps and only the link to the test failed. Click **Retry Link** — Spur links the work item it already created rather than filing a duplicate. | # Email Alerts Source: https://docs.spurtest.com/analysing-tests/integrations/email Configure email notifications for test results and alerts. ## Overview The email integration keeps your team informed about test results without needing to check the Spur dashboard. You can configure notifications for specific test outcomes and control who receives alerts from which suites. ## Setup **1. Connect Email in Spur** Navigate to the [Integrations page](https://app.spurtest.com/integrations) and select **Email** from the available integrations. **2. Configure notification preferences** Choose which notifications you want to receive: > **On Fail** > > Immediate alerts when any test fails. > **All Passing Tests** > > Confirmation when tests pass. > **End of Day Summary** > > A daily digest of all test results. > **Per-Suite Access** > > Control who gets alerts from which suites. ## Per-User Access Settings By default, every user in your application receives email notifications for all tests. You can configure specific access settings to control who gets alerts from which suites. > [!NOTE] > > If you configure access for one person, make sure to configure access for everyone else as well. Otherwise, unconfigured users will continue to receive notifications for all suites. **1. Open access settings** Go to the Integrations tab and click into **Access Settings** for the email integration. ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/Advanced_Email_Config/advanced_email.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=6f2a0a8b0405d09f3bdbf5ee33ddaaf6) **2. Set custom access per user** For each user, select which suites they should receive notifications for. This gives you fine-grained control over who sees what. ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/Advanced_Email_Config/advanced_email_people.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=68c5ef748ea6649e9bcee45f5bd6413b) # GitHub Integration Source: https://docs.spurtest.com/analysing-tests/integrations/github Connect Spur with GitHub for automated testing on pull requests. ## Overview The GitHub integration lets you run Spur tests automatically on every pull request. Test results appear as status checks directly on the PR, and you can use branch protection rules to block merges when tests fail. > **Automated Test Execution** > > Test plans run automatically on every pull request without manual intervention. > **PR Status Checks** > > Pass/fail results appear directly on the pull request in GitHub. For a full setup walkthrough including YAML workflow files and branch protection, see the [GitHub CI/CD guide](/running-tests/cicd/github). ## Quick reference Spur automatically generates the workflow YAML files for your repository. You can download them from the GitHub Integration Settings page in Spur and add them to your repository under `.github/workflows/`. > [!NOTE] > > The full CI/CD setup guide covers everything you need, including configuring test plans, downloading YAML files, and enabling branch protection. See the [GitHub CI/CD page](/running-tests/cicd/github) for step-by-step instructions. # GitLab Integration Source: https://docs.spurtest.com/analysing-tests/integrations/gitlab Connect Spur with GitLab for automated testing on merge requests. ## Overview The GitLab integration lets you run Spur tests automatically on every merge request. Test results appear as pipeline status checks directly on the MR, helping your team catch issues before merging. > **Automated Test Execution** > > Test plans run automatically on every merge request without manual intervention. > **MR Status Checks** > > Pass/fail results appear directly on the merge request in GitLab. For a full setup walkthrough including `.gitlab-ci.yml` configuration, see the [GitLab CI/CD guide](/running-tests/cicd/gitlab). ## Quick reference Add the Spur test stage to your `.gitlab-ci.yml` file to trigger test plans on merge request events. Spur provides the configuration you need from the GitLab Integration Settings page. > [!NOTE] > > The full CI/CD setup guide covers everything you need, including configuring test plans and pipeline setup. See the [GitLab CI/CD page](/running-tests/cicd/gitlab) for step-by-step instructions. # Integrations Overview Source: https://docs.spurtest.com/analysing-tests/integrations/integrations Setup instructions of integrations, and a list of all currently available integrations. # Setting up your Integrations ![Integrationsoverview 1](https://mintcdn.com/spur/ZCr4ugsX6qHth4n4/images/integrationsoverview-1.gif?s=7dfc345a658e1efd57089300ecfd9408) 1. Click the User Profile button in the top right, from any page. 2. Click Integrations in the dropdown. 3. Connect and manage your integrations! # Available Integrations ## Issue Tracking & Bug Reporting > [!NOTE] > > Jira and Linear follow the same workflow in Spur. Both let you create bug tickets from test failures with auto-populated details. The setup and ticket creation steps are identical across both integrations. > > Azure DevOps files the same auto-populated content, but it connects with a personal access token instead of an OAuth authorization, and only an admin can set it up. Follow the [Azure DevOps guide](/analysing-tests/integrations/azure-devops) rather than the steps above. > **[Jira](/analysing-tests/integrations/jira)** > > Create detailed Jira tickets directly from test failures with screenshots, logs, and reproduction steps. > **[Linear](/analysing-tests/integrations/linear)** > > Create Linear issues directly from test failures with auto-populated details and reproduction steps. > **[Azure DevOps](/analysing-tests/integrations/azure-devops)** > > Create Azure DevOps work items from test results, with project and field defaults set by an admin. ## Communication & Notifications > **[Slack](/analysing-tests/integrations/slack)** > > Real-time notifications and alerts in your Slack workspace > **[Email](/analysing-tests/integrations/email)** > > Customizable email notifications and reports ## Development Workflows > [!NOTE] > > GitHub and GitLab follow the same workflow in Spur. Both let you trigger test plans automatically on pull requests or merge requests, with results appearing as status checks. > **[GitHub](/analysing-tests/integrations/github)** > > Automated testing workflows and Vercel preview deployment > **[GitLab](/analysing-tests/integrations/gitlab)** > > Run Spur tests in your GitLab CI/CD pipelines with automated test execution on merge requests. # Jira Tickets Source: https://docs.spurtest.com/analysing-tests/integrations/jira Connect Spur with Jira to file bug tickets from failed test runs, sync ticket status back to Spur, and set project, priority, and assignee defaults. ## Setup If you have not integrated Spur with Jira, follow the setup process [here](/analysing-tests/integrations/integrations). ## Overview Connecting to our Jira integration allows you to create bug tickets directly from test failures. You can choose which project to send tickets to, along with details such as priority and assignee. ## Permissions When you authorize the integration, Spur requests the following Jira OAuth scopes. Each one maps directly to a feature of the integration: | Scope | Why Spur needs it | | - | - | | `read:jira-work` | Lists your projects, issue types, and issue fields so the ticket creation modal is pre-populated with your project's setup. Also used to fetch issue details for tickets linked to Spur tests. | | `write:jira-work` | Creates bug tickets from test failures and attaches supporting evidence, such as test videos and screenshots, to the ticket. | | `read:jira-user` | Fetches the names and avatars of assignable users so you can pick an assignee when creating a ticket. | | `manage:jira-configuration` | Reads your Jira configuration — available priorities, statuses, and fields — so the ticket creation form matches your instance. Atlassian gates read access to these configuration objects behind this scope; Spur never creates or modifies projects, workflows, or custom fields. | | `offline_access` | Keeps the integration connected by refreshing access tokens, so you don't have to re-authorize Spur. | > [!NOTE] > > Spur only acts on your Jira workspace when you create a ticket from a test failure. It never modifies your Jira configuration or deletes data on its own. ## Creating a ticket manually from a test failure **1. Review a test and initiate a bug report** After reviewing a test run, open the Share menu and click the "Create a Ticket" button to open the Jira ticket creation modal: ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/share.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=0896982aaf8882f14eb4f6cab7efb787) **2. Jira ticket creation modal** The modal opens with pre-populated information from the test failure: ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/Jira/jira_full.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=0ce55247cc93ed2ed52561a07d504198) **Auto-Generated Fields:** * **Title**: Name of the Test * **Description**: Detailed bug report including: * Failure Reason * Reproduction steps * Test name and execution details * **Project**: The default project, if chosen in the Integrations page. **3. Customize ticket details** Edit the title and description, if necessary. Choose additional ticket details. ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/Jira/jira_additional.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=cc19a833c9e3af2289c7f6ee93b6189c) **Customization Options:** * **Assignee**: Set who should handle the ticket * **Priority**: What is the urgency of this bug? * **Due Date**: When will this ticket be considered overdue? **4. Submit and track** Create the ticket! ## Viewing and syncing linked tickets Once a Jira ticket is linked to a test, Spur displays it in the test's share panel with live status information pulled directly from Jira. ### Status pill Each linked ticket shows a **status pill** reflecting its current Jira workflow state—for example, **Open**, **In Progress**, or **Done**. The status is displayed alongside the ticket key so you can see the current state at a glance without leaving Spur. ### Syncing ticket data Click the **Sync** button next to a linked ticket to pull the latest information from Jira. Syncing updates: * **Title** — Current ticket summary * **Status** — Current workflow state * **Assignee** — Current ticket owner * **URL** — Link to the Jira issue This is useful when a ticket has been updated in Jira since it was first linked—for example, if it has been reassigned, triaged, or resolved. ## Troubleshooting ### Common issues **If fields are missing:** * Your integration permissions may not be set properly. Try reintegrating from the Integrations page. **Ticket Creation Failures:** * Confirm you have chosen a proper project and issue type * Check required field configurations **Custom Required Fields:** * If your Jira project has custom required fields, [contact the Spur team](/additional-resources/contact-us) for assistance with your integration setup. # Linear Tickets Source: https://docs.spurtest.com/analysing-tests/integrations/linear Connect Spur with Linear for streamlined issue tracking and automated bug reporting. ## Setup If you have not integrated Spur with Linear, follow the setup process [here](/analysing-tests/integrations/integrations). ## Overview Connecting to our Linear integration allows you to create bug tickets directly from test failures. You can choose which team and project to send issues to, along with details such as priority, assignee, and labels. ## Creating a Ticket Manually from a Test Failure **1. Reviewing a Test and Initiating a Bug Report** After reviewing a test run, open the Share menu and click the "Create a Ticket" button to open the Linear issue creation modal: ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/share.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=0896982aaf8882f14eb4f6cab7efb787) **2. Linear Issue Creation Modal** The modal opens with pre-populated information from the test failure: ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/Linear/linear_full.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=7e53e9ac45e37b70a26deaa19a8c29d4) **Auto-Generated Fields:** * **Title**: Name of the Test * **Description**: Detailed bug report including: * Failure Reason * Reproduction steps * Test name and execution details * **Team**: The default team, if chosen in the Integrations page. **3. Customize Issue Details** Edit the title and description, if necessary. Choose additional issue details. ![](https://mintcdn.com/spur/nNuvmyM4s84IFvTw/images/Integrations/Linear/linear_additional.png?fit=max\&auto=format\&n=nNuvmyM4s84IFvTw\&q=85\&s=c51e9b094e073bfa5e8a33890e09ab61) **Customization Options:** * **Project**: Which project should this ticket be in? This is optional. * **Assignee**: Set who should handle the issue * **Priority**: What is the urgency of this bug? * **Labels**: Attach any labels that are allowed within the selected team. * **State**: Choose the current status of the issue **4. Submit and Track** Create the issue! ## Troubleshooting ### Common Issues **If fields are missing:** * Your integration permissions may not be set properly. Try reintegrating from the Integrations page. **Issue Creation Failures:** * Confirm you have chosen a proper team * Check required field configurations **Custom Required Fields:** * If your Linear workspace has custom required fields, [contact the Spur team](/additional-resources/contact-us) for assistance with your integration setup. # Slack Alerts Source: https://docs.spurtest.com/analysing-tests/integrations/slack Connect Spur with Slack for real-time test result notifications in your workspace. ## Overview The Slack integration sends test result notifications directly to a channel in your workspace. You can receive alerts when tests fail, when they pass, or get a daily summary of all results. ## Setup **1. Create a Slack channel** In your Slack workspace, create a new channel for Spur notifications (e.g. `#spur_alerts`). **2. Connect Slack in Spur** Navigate to the Integrations page and click **Connect** on the Slack card. Authorize Spur to access your workspace when prompted. > **[Connect Slack](https://app.spurtest.com/integrations)** > > Go to the Integrations page in Spur to connect your Slack workspace. ## Permissions When you authorize the integration, Spur requests the following Slack OAuth scopes. Each one maps directly to a feature of the integration: | Scope | Why Spur needs it | | - | - | | `chat:write` | Sends test result alerts and end-of-day summaries to your chosen channel as Spur. | | `channels:read` | Lists the public channels in your workspace so you can pick a notification channel when configuring alerts or test plans. | | `groups:read` | Lists private channels that Spur has been added to, so they also appear in the channel picker. | | `channels:join` | Lets Spur join a public channel automatically when it needs to deliver an alert there, so you don't have to invite the bot manually. | | `incoming-webhook` | Lets you post Spur alerts to a specific channel via a webhook URL as an alternative to selecting a channel. | | `links:read` | Detects when `app.spurtest.com` test result links are shared in your channels. | | `links:write` | Shows rich previews of shared `app.spurtest.com` links, including the test name, status, and failure reason. | | `links.embed:write` | Embeds the test recording video player directly in those link previews. | | `app_mentions:read` | Lets Spur see messages that directly @-mention the Spur app in channels it has been added to. | > [!NOTE] > > Spur can only see channel names for the channel picker and messages that contain `app.spurtest.com` links or @-mention Spur. It cannot read your other messages. ## Notification Options Once connected, you can choose when Spur sends alerts to your channel: * **On Fail** — Get notified when one or more tests fail. * **On Pass** — Get notified when tests pass. * **End of Day Summary** — A daily digest of all test results. > [!TIP] > > You can also customize the Slack channel and notification trigger per test plan. Test plans can send alerts to their own dedicated channels. See the [Running Test Plans](/running-tests/test-plans) page for details. # Spur MCP Integration Source: https://docs.spurtest.com/analysing-tests/mcp/spur-mcp Give your AI assistant access to Spur through the Model Context Protocol to run tests, analyze results, and debug failures without leaving your editor. [Loom video player](https://www.loom.com/embed/9684ca0577a94c64908ab5b23dbff14d) MCP (Model Context Protocol) is a way to give your AI assistants and agents access to external tools and data — so they can take actions on your behalf, not just answer questions. With Spur's MCP server, your AI assistant can run tests, analyze results, and help you debug failures — all without leaving your editor. ![The Spur MCP in action](https://mintcdn.com/spur/310-MD6x9ZuCaKOy/images/MCP/mcp.png?fit=max\&auto=format\&n=310-MD6x9ZuCaKOy\&q=85\&s=650ee5d3ca46b3336bf7aff8ae8ae26b) ![Using the Spur MCP alongside other MCP tools](https://mintcdn.com/spur/wB1dCdgur0RTtos6/images/MCP/mcp_github.png?fit=max\&auto=format\&n=wB1dCdgur0RTtos6\&q=85\&s=0fe18911426edce11e232f6d1ce95c39) ## Common Workflows > **Discover and Run Tests** > > *"Run any tests I have for checkout"* > > The agent finds matching tests and lets you run them directly from the conversation. > > [See this in action](/analysing-tests/mcp/spur-mcp-discover-tests) > **Analyze Failed Tests** > > *"What went wrong in this run?"* > > The agent reviews step results, console logs, and screenshots to surface the root cause. > **Summarize Test Coverage** > > *"What is missing from my checkout flow test coverage?"* > > Your agent is provided with information about all your tests across suites and environments to identify gaps. > **Fix Raised Bugs** > > *"Help me fix the bug from this failed test"* > > The agent pulls failure details, logs, and context to help you resolve issues in your code. > > [See this in action](/analysing-tests/mcp/spur-mcp-fix-bugs) > **Create Tests from Code** > > *"Generate and save tests for this PR"* > > The agent analyzes your code, generates test steps, and creates them directly in Spur via `create_test` — no manual copy-paste required. > > [See this in action](/analysing-tests/mcp/spur-mcp-in-sprint-testing) > **Run and Triage Test Plans** > > *"Run the regression suite and tell me what failed"* > > The agent triggers a full test plan run, then walks through every failure with detailed context for each one. > > [See this in action](/analysing-tests/mcp/spur-mcp-test-plans) > **Connecting with Other MCP Tools** > > *"Run the Spur test that covers this Jira ticket and this GitHub PR"* > > Connect other tools, providing additional context to optimize your testing. Let your AI agent decide what to test. > > [See this in action](/analysing-tests/mcp/spur-mcp-connecting-other-mcps) > **[In-Sprint Test Generation](/analysing-tests/mcp/spur-mcp-in-sprint-testing)** > > *"Here's PR #247 — generate test cases for the search modal changes"* > > Use Claude Code with your codebase context to generate, run, and iterate on tests directly from PRs and tickets — all within your sprint cycle. ## Available Tools > **Test Discovery** > > `list_tests` – Lists all tests in the active application with IDs, suites, URLs, and scenario table status. Accepts optional filters: `test_id` for full step-level detail (replaces the old `get_test_details`), `suite_id` to scope to a single suite, and `query` for a name search > > `list_suites` – Lists all suites with their allowed environments, URL keys, and connected scenario table. Pass `suite_id` to also return every test in that suite > > `list_folders` – Lists all folders in the active application. Without a `folder_id`, returns a summary of every folder; with a `folder_id`, returns that folder's details and the suites it contains > > `list_scenarios` – Lists all scenario tables with columns and row names. Pass `table_name` to see the full cell values for every row — use this when you need actual data to build test steps or configure a test plan > > `list_environments` – Lists all environments with type, validity status, and how many suites can use each one. Pass `env_name` to see every property and its configured value (URLs, headers, secrets, build references) > > `list_login_tests` – Lists login tests compatible with a suite and test type: tests that save login state, cover every environment the suite runs on, and match the platform (web or native). Pass a returned id to `create_test` or `update_test` as `from_login_test_id` > > `list_test_plans` – Lists all test plans with suite counts, environments, and last run time. Pass `plan_id` to get the full editable configuration — required before calling `update_test_plan` > **Test Authoring** > > `get_test_guidance` – Returns Spur's test-writing best practices and the full step format reference (browser actions, verifies, extracts, JavaScript injection, network log assertions, email, variables). Call this before `create_test` or `update_test` so generated steps use the correct syntax > > `create_test` – Creates and saves a new test to a suite. Requires a `suite_id`, `title`, `env_key_name`, and `steps`. Use `list_suites` first to discover valid values. The agent will show you a full summary and ask for approval before saving > > `update_test` – Updates an existing test by `test_id`. Accepts any combination of `title`, `env_key_name`, and `steps`. Replaces all steps when `steps` is provided. The agent will show you what will change and ask for approval before saving > > `generate_test_steps_from_loom` – Turns a public Loom video into a DRAFT list of test steps (server-side analysis of screen and narration). Does not save anything on its own — normalize the draft with `get_test_guidance`, confirm suite and environment, then call `create_test` > > `save_suite` – Creates a new test suite or updates an existing one. Can also move tests into the suite, place the suite in a folder, or replace the suite's full dependency graph (test ordering and variable flow). Validates every change up front and rejects moves that would break environments, dependencies, or scenario tables > > `create_scenario_table` – Creates a scenario table with optional columns and rows. Use `list_scenarios` first to check what already exists > > `update_scenario_table` – Edits a scenario table's columns or rows. Use `list_scenarios` first to see the current state > > `add_scenario_rows` – Adds new rows to an existing scenario table. Provide the `table_name` (from `list_scenarios`) and an array of rows, each with a unique `name` and a `values` map of column name → value > > `connect_scenario_table` – Connects or disconnects a scenario table from a suite. A suite can only have one scenario table at a time. Use `action: "connect"` or `"disconnect"` along with the `table_name` and `suite_id` > **Test Execution** > > `run_tests` – Runs one or more tests in a single collection run, grouped by shared configuration. Specify `env_name` (environment name) along with optional `viewport`, `browser`, and `scenario_row_name` > > `run_test_plan` – Triggers a full test plan run across all configured suites and environments > **Run Analysis** > > `get_test_run_overview` – **Start here.** Summarizes a run's status, step results, warnings, and failures > > `get_test_run_details` – Deep dive into steps, sub-steps, configs, and artifacts. Use after the overview > > `get_test_runs` – Lists the last 50 runs for a given test > > `get_recent_runs` – Returns the most recent runs across the application or filtered by suite or test within a time window. Results are grouped by collection run and include status, metadata (scenario, browser, viewport, environment, test type), duration, and `task_id` for drilling into individual runs > > `get_coverage_snapshot` – Whole-window coverage aggregates computed server-side over every run in the window: runs and failures per environment, distinct tests run per suite × environment, suites with zero runs, browser and viewport totals, and every failed run. Use this for coverage reports instead of paging `get_recent_runs` > **Debugging** > > `get_test_run_console_logs` – Browser console output and JavaScript errors. Supports `contains` for case-insensitive substring search and `limit`/`offset` for paging > > `get_test_run_network_logs` – HTTP requests and responses captured during the run. Supports `contains` (URL fragment, status code, or method) and `limit`/`offset` for paging > > `get_test_run_screenshots` – Screenshots from the test execution for visual inspection > **Test Plans** > > `list_test_plans` – Lists all test plans with their names, suites, environments, and last run time. Pass `plan_id` to get the full editable configuration needed for `update_test_plan` > > `create_test_plan` – Creates a new test plan grouping suites and environments for coordinated execution. The agent will show you the full plan summary and ask for approval before saving > > `update_test_plan` – Updates an existing test plan. Always call `list_test_plans` with `plan_id` first to get the current configuration — the new suites list replaces the existing one entirely > > `get_test_plan_runs` – Returns recent run history for a test plan: timestamps, pass/fail counts, and run IDs > > `get_test_plan_run_overview` – **Key triage tool.** Shows every test result in a plan run — failures first with failure reasons. Use `task_id` values from here to drill into individual failures with the run analysis tools > **Application Management** > > `applications` – Lists all applications on your account, or switches the active one. Omit `application_name` to list; provide it to switch. All subsequent tool calls will use the newly selected application ## How to Set Up > **[Setup Instructions](/analysing-tests/mcp/spur-mcp-setup)** > > Get started with Cursor, Claude Code, GitHub Copilot in VS Code, or ChatGPT. Authentication uses OAuth. When you connect for the first time, your browser will open to authorize access to your Spur account. ## Best Practices * **Allow all tool calls except test execution and authoring**: Set your MCP client to auto-approve read-only Spur tool calls. Keep `run_tests`, `run_test_plan`, `create_test`, `update_test`, `create_test_plan`, `update_test_plan`, `save_suite`, `create_scenario_table`, `update_scenario_table`, `add_scenario_rows`, and `connect_scenario_table` on manual approval — these tools write or trigger things on your behalf, so you should review what will happen before they proceed. * **Model quality matters**: More capable models produce better results when choosing the right tools and interpreting test output. Smaller models may need more explicit guidance. # Connecting with Other MCP Tools Source: https://docs.spurtest.com/analysing-tests/mcp/spur-mcp-connecting-other-mcps Combine the Spur MCP with GitHub, Jira, Linear, and other tools to give your AI assistant richer context for testing. The Spur MCP becomes more powerful when your AI assistant has access to other tools alongside it. By connecting MCPs for project management, source control, or communication, your agent can pull in context from across your workflow — and make smarter decisions about what to test, when to test it, and how to interpret results. ## GitHub Connect a GitHub MCP so your agent can read pull requests, commits, and code changes — then match them to the right Spur tests. ![Using the Spur MCP alongside GitHub](https://mintcdn.com/spur/wB1dCdgur0RTtos6/images/MCP/mcp_github.png?fit=max\&auto=format\&n=wB1dCdgur0RTtos6\&q=85\&s=0fe18911426edce11e232f6d1ce95c39) ### Example prompts * *"Run any Spur tests that cover the files changed in this PR"* * *"This commit broke checkout — find the relevant Spur test and show me what failed"* * *"What Spur test coverage do I have for the code in PR #142?"* ### How it works **1. Agent reads the PR or commit** Your agent uses the GitHub MCP to fetch the changed files, commit messages, or PR description. **2. Agent matches changes to tests** Using the context from GitHub, the agent calls `list_tests` and `get_test_details` to find Spur tests that cover the affected areas. **3. Agent runs and reports** The agent runs the matching tests with `run_test`, then summarizes results — so you know whether your changes are safe before merging. ## Jira Connect a Jira MCP so your agent can read tickets, acceptance criteria, and bug reports — then tie them directly to Spur test runs. ![Using the Spur MCP alongside Jira](https://mintcdn.com/spur/wB1dCdgur0RTtos6/images/MCP/mcp_jira_1.png?fit=max\&auto=format\&n=wB1dCdgur0RTtos6\&q=85\&s=61f2ced8c49d0c29682a99f4ae09551f) ### Example prompts * *"Run the Spur test that covers Jira ticket SHOP-451"* * *"This Jira bug says checkout is broken — find and run the relevant Spur tests"* * *"Check if I have Spur test coverage for the acceptance criteria in SHOP-302"* ### How it works **1. Agent reads the Jira ticket** Your agent uses the Jira MCP to fetch the ticket summary, description, and acceptance criteria. ![Agent matching Jira ticket to Spur tests](https://mintcdn.com/spur/wB1dCdgur0RTtos6/images/MCP/mcp_jira_2.png?fit=max\&auto=format\&n=wB1dCdgur0RTtos6\&q=85\&s=4890bfa1fc7658a9ebc797c44f3f7449) **2. Agent matches ticket to tests** The agent calls `list_tests` and `get_test_details` to find Spur tests that match the ticket scope, then presents them for you to run. ![Agent reporting Spur test results for a Jira ticket](https://mintcdn.com/spur/wB1dCdgur0RTtos6/images/MCP/mcp_jira_3.png?fit=max\&auto=format\&n=wB1dCdgur0RTtos6\&q=85\&s=1b7167267faee51099506ac03b5e5f85) **3. Agent runs and reports** The agent runs the matching tests with `run_test`, then summarizes the results — so you know which acceptance criteria are passing and which need attention. ## Linear Connect a Linear MCP so your agent can read issues, project context, and cycle priorities — then link them to your Spur test suite. ![Using the Spur MCP alongside Linear](https://mintcdn.com/spur/wB1dCdgur0RTtos6/images/MCP/mcp_linear.png?fit=max\&auto=format\&n=wB1dCdgur0RTtos6\&q=85\&s=6f78e4f783b6c71188b51c8a5cbd2642) ### Example prompts * *"Run Spur tests related to the issues in the current sprint"* * *"This Linear issue says the login flow is broken — find and run the matching Spur test"* * *"What Spur test coverage do I have for the issues assigned to me?"* ### How it works **1. Agent reads the Linear issue** Your agent uses the Linear MCP to fetch issue details, labels, and project context. **2. Agent matches issues to tests** The agent calls `list_tests` and `get_test_details` to find Spur tests that align with the issue scope. **3. Agent runs and reports** The agent executes the relevant tests and reports back with results mapped to the Linear issue, so you can update the issue status with confidence. ## Other tools Any MCP that gives your agent context about *what changed* or *what matters* pairs well with Spur. The pattern is always the same: the external tool provides context, and Spur provides the testing. Examples of other MCPs that work well alongside Spur: * **Slack** — *"Someone reported a bug in #engineering — find and run the relevant Spur test"* * **Notion** — *"Run Spur tests for the features listed in this Notion spec"* * **GitLab** — *"Run tests covering the files in this merge request"* # Discover and Run Tests Source: https://docs.spurtest.com/analysing-tests/mcp/spur-mcp-discover-tests Use your AI assistant to explore what tests are available in Spur and run them without leaving your editor. [Spur MCP product walkthrough](https://www.loom.com/embed/3096323fa3f94ff3bd8836248a2a781d) ## Who is this for? If you've just joined a team using Spur — or you are taking a look at tests someone else wrote — you may not know what test coverage already exists. Rather than clicking through the Spur dashboard to find out, you can ask your AI assistant to tell you. This workflow is especially useful when you: * Are new to a codebase and want to understand what's already tested * Need to run tests for a feature you're working on but aren't sure what's available * Want to quickly check if a specific flow has coverage before writing new tests ## Walkthrough **1. Ask what tests exist** Start with a broad question like *"What tests do I have?"* or narrow it down: *"What tests do I have for Adding to Cart?"* Your agent calls `list_tests` to pull all tests in your active application, then filters by name and description to find relevant matches. **2. Choose the Tests** The agent returns a list of matching tests with their IDs, suites, URLs, and descriptions. You can ask follow-up questions like *"What does the checkout test cover?"* to get full step details via `list_tests` with the `test_id`. **3. Run tests directly** Once you've found the right test, tell your agent to run it: *"Run this on staging."* The agent calls `run_tests` with the correct environment name and configuration, then monitors the run status. The agent will prompt you to fill in any configurations that it is missing. **4. Review results** When the run completes, ask *"How did it go?"* The agent calls `get_test_run_overview` to summarize the results — passing steps, failures, and warnings — so you can decide what to do next. # Fix Raised Bugs Source: https://docs.spurtest.com/analysing-tests/mcp/spur-mcp-fix-bugs Use your AI assistant to pull failure details from Spur and resolve bugs directly in your code.