The 2500% Bug Problem: Why AI-Generated Code Needs a New Kind of QA

Gartner recently made a prediction that stopped me mid-scroll:

By 2028, prompt-to-app approaches adopted by citizen developers will increase software defects by 2500%, triggering a software quality and reliability crisis.

Twenty-five times more bugs. Not typos. Not linting errors a CI pipeline catches in seconds.

Gartner's research points to something more dangerous: a new class of defect where AI output is syntactically correct but architecturally blind. The code runs. It compiles. It even passes a quick smoke test. But it doesn't understand the broader system it's dropping into, and it doesn't know the business rule it just silently broke.

We've seen this failure mode firsthand

In a recent engineering exercise on our own team, an AI coding assistant was asked to build a session-recording tool using a specific DOM-mutation approach, the kind of architectural detail that matters for how the tool performs at scale.

The AI understood the prompt at a surface level and produced code anyway. It just built the wrong thing: a screenshot-polling implementation instead of the DOM-mutation one that was explicitly specified.

It looked like progress. It ran. But it was structurally a different system than the one that had been asked for, and that gap wasn't obvious until someone read the implementation closely.

That's the crux of Gartner's warning. Automation bias, the tendency to trust AI output because it "looks right," is what turns a fast coding tool into a defect factory. And the more code a team ships this way, the more that gap compounds.

What we're hearing from retail and e-commerce teams

We hear a version of this constantly from teams evaluating Spur.

One national retailer we've been talking with has two QA bottlenecks stacked on top of each other:

• A monolithic codebase that requires full regression testing before any release
• A site-experience team that "self-QAs" its own promo and content changes, reviewing its own work, essentially grading its own homework

When we ran a demo against one of their live sites, our agents caught things a human reviewer had missed: a stale holiday shipping banner, and an upsell prompt urging customers to add another item for free shipping, after shipping was already free.

Small. Easy to miss. Exactly the kind of "subtle but severe" flaw Gartner describes. Nobody wrote broken code on purpose. The gap was context, not syntax.

Why traditional QA can't keep up

The traditional answer to catching these issues, more manual QA, more Selenium and Playwright scripts, doesn't scale against AI-generated code's pace or its failure pattern.

One retail brand we're working with told us their existing UI automation has roughly a 20% first-run failure rate, not because the product is broken, but because the tests are brittle: hardcoded to DOM selectors that shift every time the UI changes.

That's the traditional-testing tax, and it was already too slow before AI started multiplying the volume of code hitting production.

The fix: testing at AI speed

This is why Gartner's report calls for governance, not just better tools: architectural checkpoints, human review at the right junctures, and, critically, testing that validates intent and business logic, not just whether a page loads.

That's the layer we built Spur to be. Our agents test the way a human QA analyst would, simulating real customer journeys and checking:

• Functional correctness: does checkout actually work?
• Non-functional details: is the promo text accurate? Does the visual layout hold up? Is the copy still true?

Because tests are built around user intent rather than DOM selectors, they don't shatter every time a frontend team, human or AI, changes a class name.

The bottom line

Gartner's prediction isn't a reason to slow down on AI-assisted development. It's a reason to make sure something is actually watching what AI ships.

The teams that pair AI-speed code generation with AI-speed, context-aware QA are the ones who'll capture the productivity gains without inheriting the defect bill. The teams that don't will spend 2027 and 2028 finding out the hard way.

If you're staring down a growing backlog of AI-generated code and wondering what's actually shipping clean, that's the conversation we'd like to have.

‍

‍

Why Spur takes a fundamentally different approach to iOS and Android automation — one that requires no code changes, no instrumentation, and no brittle selectors.

TL;DR: Traditional mobile automation breaks because it depends on hooks, instrumentation, and brittle selectors. Spur runs your real app and drives it visually with an AI agent — so tests survive UI changes and reflect what users actually experience.

Mobile is where most QA strategies quietly fall apart.

Teams that have solid, automated coverage on the web often have a spreadsheet, a contractor, and a prayer on mobile. The reasons are structural: mobile operating systems — iOS especially — are built around a curated, locked-down trust model. That model is great for users and terrible for testers. The same walls that keep attackers out keep your automation out.

The industry's usual answer has been to break into the app — inject a library, swizzle the runtime, re-sign the binary, and fork low-level agents to wrestle control from the OS. It works, but it comes with a cost that rarely makes it into the sales deck:

You're no longer testing the app you ship.

Spur takes a different path. Instead of modifying your app, Spur drives it like a person would — an AI agent that looks at the screen, understands it, and acts. Here's why that matters, and what it unlocks.

What this unlocks: faster test authoring, dramatically lower maintenance, and higher trust — because you're validating the same build your users run.

Why mobile testing is hard

There are three problems every mobile automation effort runs into:

1. The OS won't cooperate. iOS provides no supported way for an external tool to reach into a running app. Android is a little friendlier, but real-device fragmentation and flaky tooling erode any head start.
2. Selectors are a moving target. Traditional frameworks bind tests to element IDs, XPaths, and accessibility identifiers. The moment a designer renames a button or reflows a screen, your suite turns red — not because the app broke, but because the test did.
3. Maintenance eats the ROI. Teams don't abandon mobile automation because they can't get it working once. They abandon it because keeping it green costs more than the bugs it catches.

Every approach to mobile testing is really an answer to problem #1 — how do you get control? The answer you choose determines whether you also inherit problems #2 and #3.

If this sounds familiar: "We tried mobile automation… it worked for a week… then the suite became a full-time job."

Two philosophies: instrument the app, or drive the app

Most tools get control by going inside the binary.

The instrumentation approach injects a dynamic library at install time, re-signs the app with custom certificates, and uses runtime hooks to expose test controls. It's clever engineering — but it means:

• You test a modified build, not your production binary.
• You inherit an integration burden (signing exceptions, CI/CD injection, managed devices, forked agents to maintain).
• Coverage becomes capability-by-capability (camera, mic, barcode, etc. each needs bespoke hooks).

Spur gets control the way a human tester does: by looking at the screen and interacting with it.

There's no library in your binary, no re-signing requirement, no swizzling. Spur runs your real app on real iOS simulators and Android emulators, and an AI agent perceives the UI visually and performs actions — taps, types, scrolls, swipes, gestures — based on plain-English instructions.

The difference in one line:

Instrumentation changes the app so the test can see it. Spur teaches the test to see the app.

How Spur tests mobile

1) You write tests in plain English

No selectors. No coordinates. No code.

"Open the app, continue as guest, search for 'white jackets', and confirm results appear."

That's a Spur test. You describe the goal the way you'd hand it to a teammate holding the phone, and the agent figures out the interactions. Anyone on the team — QA, PM, support — can author coverage, not just SDETs.

Example prompt: "Sign in, skip tracking permission, add any item to cart, and confirm checkout loads."

2) An AI agent sees the screen and acts

Under the hood, Spur's agent uses a vision-language model to understand what's actually on screen and decide the next action. Because it reasons about the UI the way a person does, it:

• Adapts to change. Renamed buttons and layout tweaks don't automatically break the test.
• Handles messy mobile reality. System permission dialogs, tracking prompts, onboarding screens, and interstitials get handled in-flow instead of derailing the run.
• Self-heals. No selector graveyard to maintain.

3) It runs unmodified — on real simulators and devices

Your app runs exactly as built. Spur orchestrates the device, launches the app, drives native gestures, and observes results. Native actions — relaunch, foreground, deep links, back navigation, device rotation, shake, keyboard input, toast assertions — are all first-class, expressed in the same natural-language flow.

4) Environments and builds are handled

Point a test at a build (iOS or Android) and an environment, and Spur manages install, configuration, credentials, and deep links per environment. Promote the same test across dev, staging, and production without rewriting a thing.

What you can automate first on mobile

If you're not sure where to start, the highest-leverage journeys are the ones that break most often — and hurt most when they do:

• Onboarding & auth — email/social sign-up, login, SSO, "continue as guest," plus the permission and ATT prompts that derail brittle scripts.
• Search & discovery — queries, filters, sorting, and empty/error states.
• Commerce — add-to-cart, checkout, payments, promo codes, order confirmation.
• Account & settings — profile edits, notification toggles, plan changes, logout.
• Deep links & navigation — universal/app links into a specific in-app screen, plus back-navigation and tab flows.
• Content & media — feeds, playback, pull-to-refresh, infinite scroll, uploads.
• Regression & smoke packs — a core suite that runs on every build, in every environment.
• Cross-platform parity — the same journeys on iOS and Android from one set of instructions.

Start with your highest-traffic, highest-revenue path, describe it in a sentence, and let the AI draft it. You'll have real coverage running in minutes, not sprints.

A quick mental checklist for "good" mobile tests

• User-language steps (not implementation details)
• Stable assertions (what the user sees + what the backend did)
• Permission/onboarding resilience (the stuff that flakes first)
• Evidence attached (video + network + logs for every failure)

Watch it happen: live streaming

Automation you can't see is automation you can't trust. Spur lets you stream a live, interactive session of the device right in your browser — tap through the app yourself, reproduce an issue, or watch a test drive the flow in real time.

Every run is recorded, with network and console logs captured, so a failure comes with the evidence attached instead of a stack trace and a shrug.

Beyond the screen: network + console observability

A passing tap isn't proof that everything worked. The most damaging mobile bugs are the ones the screen doesn't show — a checkout that looks successful but fires a 500 to the payments API, an analytics event that silently stops sending, a token that leaks in a request header, a retry storm quietly draining battery.

Spur runs two dedicated observability agents alongside every mobile test so those failures can't hide.

The network agent

The network agent captures the requests your app makes — to your own backend and to third-party SDKs — and turns invisible behavior into something you can assert on:

• Catch silent backend failures (UI says "Order placed," but POST /checkout returned 500).
• Verify integrations and analytics (Segment, attribution SDKs, internal APIs).
• Guard performance and cost (redundant calls, retry storms, oversized payloads, slow endpoints).
• Check privacy and security (see what data leaves the device, and where it goes).

The console log agent

The console log agent captures the app's own logs — warnings, errors, and stack traces that rarely surface in the UI. When a test fails, you don't get "element not found"; you get the underlying exception, correlated to the step that triggered it.

Together, these shift mobile QA from "did the screen look right?" to "did the app actually behave correctly end-to-end?"

Why this wins

• App under test — Instrumentation-based tools: a re-signed, dylib-injected build. Spur: your real app, unmodified.
• Authoring — Instrumentation-based tools: code + selectors. Spur: plain English, no code.
• Resilience to UI change — Instrumentation-based tools: break on selector changes. Spur: AI adapts — self-healing.
• Setup — Instrumentation-based tools: signing exceptions, CI/CD injection. Spur: point at a build + environment.
• Cross-platform — Instrumentation-based tools: per-platform tooling. Spur: one model for web, iOS, and Android.
• Maintenance — Instrumentation-based tools: grows with the suite. Spur: minimal selector upkeep.

Get started

If mobile has been the gap in your automated coverage — the platform where you're still paying for manual QA or skipping it entirely — Spur closes it without asking you to modify your app or hire a team to babysit selectors.

Write your first mobile test in plain English today. Start with one critical flow (signup, search, or checkout), describe it in a sentence, and let Spur draft the full test.

FAQ

Do I have to modify or re-sign my app?

No. Spur runs your real app on managed simulators/devices and drives it externally with an AI agent.

Do I need to write code or maintain selectors?

No. Tests are natural-language steps. The agent interprets the screen visually, so there are no element IDs or XPaths to keep in sync with your UI.

What happens when the UI changes?

The agent recognizes intent ("the primary button," "the search field"), so cosmetic and layout changes that shatter selector-based suites generally don't break Spur tests.

iOS and Android both?

Yes — and the same authoring model covers web too. One way to write tests across all three.

Can I see what the tests are doing?

Yes. Stream a live, interactive session in your browser, and every run is recorded with network and console logs.

Can I assert on network requests and console logs?

Yes — in the same natural language you use for on-screen checks (e.g., "expect a successful POST /checkout", "fail if there are any console errors").

‍

Throughout the history of automated QA testing, there have been two big inflection points that drove great leaps in QA productivity. Today, we introduce the third.

‍

The first was the introduction of ergonomic testing script languages, such as Playwright. QAs were able to automate tens of flows, test stable pages with scripts that would run through selectors. Teams started to pick up processes around this – Test driven development, requiring tests with every feature. 

‍

The second unlock was the advent of agents and LLMs. With each new SOTA model, the need for brittle selectors and script syntax became less relevant. With products such as Spur, automated QA has moved out of the realm of niche technical knowledge and into pure systems-thinking. QA stopped being limited by a mastery of automation languages.

‍

The QA that uses Spur now spends their time thinking about what needs to be tested, and manages a swarm of agents to surface new insights.

Today, we are proud to launch the third jump in QA productivity with the release of our MCP. We’ve greatly expanded Spur’s agentic capabilities. AI can now handle the entire testing loop, and now the only thing a QA needs is intent, while Spur handles all the busy work. 

‍

What is an MCP?

An MCP Server is a protocol initially described and published by Anthropic, and has since become the primary way AI can use third-party features. The Spur MCP allows your AI chats or agents (ChatGPT conversations, Claude agents, Copilot chats, …) to use Spur itself – writing tests, running them, even analyzing them. We’ve built parity to almost every feature on our application, so your AI agents have the full capability to operate your testing.

A note about AI hallucinations: The Spur MCP server gets used by your AI chats, so improper outputs from the model are not under our control. However, we have introduced several safeguards, as well as getting approval for any potentially destructive action. 

‍

We’ve rolled this feature out to all customers for a few weeks now, and already we are seeing extremely powerful usages of these tools.

‍

Use Case 1: Writing Tests

Early in our development of Spur, the idea of generating the tests themselves was an enticing one. But the problem was that AI generated tests were often aimless and would assume large jumps in the user flow. Since then, two big changes have occurred. The first is the jump in model capabilities. The difference in agents and models from even late 2025 to now has been the difference between a fantastic, even fun generation experience and a frustrating one. The second was developing the MCP to bring novel context to the agent. Some users use the MCP in their codebase, giving literal complete context to the test writing, while others look internally at their own tests, learning from past test runs to map out their product. Improving intelligence and context led to shockingly good tests.

‍

A big focus for us at Spur was how we could develop this feature while keeping Enterprise level diligence. QA has long since trailed behind development in adopting AI features, as hallucinations are unacceptable in the last line of defense. Early adopters of the Spur MCP have shown us ways they use the MCP to bulletproof their QA.

‍

We’ve given agents the ability to operate Spur, to create tests and run them. A beta user of this feature showed us his Skills – files that contain instructions for the agent. His create-tests Skill instructs the agent to first review existing tests, pulling the writing style before creating these tests. Agents controlling Spur made it possible to then continuously run and review the results, polishing them until they were production ready. This continuous polish allowed him to create Production-ready tests from one prompt.

‍

We tell our customers to treat the Spur agent like a colleague new to your product. Now, users can treat the Spur agent like a senior colleague – one who’s learned the product inside and out. 

‍

Use Case 2: Complete Testing Loop in CICD

Our customers continue to inspire us. An engineering firm we work with showed us the workflow they’ve set up with MCP, which we very quickly folded into our own dogfooding process. A PR opens, and a testing agent is instantly spun up. The agent looks over available Spur tests, finds the ones that test the feature, writes new tests if those don’t exist, and fully tests the feature. For teams that are always finding themselves ahead of their testing (like us!) this changes everything. 

Test coverage automatically grows with your application. 

‍

“The future will increasingly be built for agents” is a common statement nowadays. By making all possible operations on Spur accessible for agents, workflows such as the ability to choose, create, and run only relevant tests on feature push go from the realm of wishful thinking to production ready. At Spur, we are making QA built for agents.

‍

What does a QA look like now?

Software developers have long felt the productivity benefits of AI, while often leaving QA behind as an afterthought. The Spur MCP has provided the 10x productivity jump so desperately needed to the QA team. Creating resilient, useful and valuable tests has never been easier, to the point where 100% test coverage can become the starting point rather than the distant goal. An important milestone when code is pushed faster and faster.

‍

And yet, quality-thinking has never been more important. Spur can create, perform, and analyze tests, but knowledge and expertise is needed to identify where platforms are likely to break, and to direct Spur. The QA of today, using Spur, is no longer running through flows manually, nor writing brittle Playwright scripts, nor writing Spur tests by hand. They are directing and managing agents, to cover more application surface than entire teams could.

We are excited to release these use cases as Agent Skills for your team to use today. Book a demo here!

‍

We are hiring across engineering and sales to build the 10x productivity boost to QA so necessary in the age of 10x developers. Come join us!

Nobody budgets for tracking QA

Ask a data science team what slows them down and you'll hear the usual suspects: messy data, unclear requirements, stakeholder whiplash. Fair enough. But there's another time sink that rarely gets mentioned because it doesn't feel like "real work" — manually verifying that analytics events actually fire correctly.

Every deploy cycle, someone on the team opens Chrome DevTools, clicks through a user flow, eyeballs the Network tab, and checks whether the right events showed up with the right payloads. It's tedious. It's error-prone. And it eats way more hours than anyone wants to admit.

The problem with silent failures

Here's what makes tracking QA particularly painful: when it breaks, nothing visibly breaks. The site works fine. Users don't complain. But behind the scenes, events stop firing, required fields go missing, data types shift from strings to numbers, and third-party pixels get quietly dropped.

You don't find out until someone pulls a report two weeks later and the numbers look wrong. By then, the data gap is permanent. You can't backfill events that never fired.

We talk to data teams regularly and the pattern is consistent:

• About half of tracking issues are events that simply stopped firing after a code change
• Another 40% are missing or malformed fields in the payload
• The remaining 10% are subtler — wrong data types, casing changes, format drift

None of these throw errors. None of them show up in monitoring dashboards. They just silently corrupt your data.

What manual QA actually costs

Let's be honest about the math. A site with 30+ tracked events across multiple regions, browsers, and environments creates thousands of combinations to check. No one checks all of them. Teams spot-check the important flows and hope for the best.

That looks something like this every release cycle:

1. Open DevTools on the target page
2. Click through the flow (product view, add to cart, checkout)
3. Search the Network tab for the right request
4. Manually inspect each payload field
5. Screenshot as evidence
6. Cross-reference with whatever analytics platform you're using
7. Repeat for every region and browser combination you have time for
8. File a ticket if something looks off

Realistically, this takes 2-4 hours per validation cycle. And because it's manual, coverage sits around 30% at best. The other 70% is trust and luck.

Here's the part that stings: every hour spent in DevTools is an hour not spent on actual analysis. Data scientists didn't sign up to be QA engineers for tracking implementations. But someone has to do it, and it usually falls on the people who understand the data best.

Why this gets worse over time

Tracking implementations aren't static. New events get added. Existing events get modified. Third-party scripts update themselves without warning. Marketing asks for new UTM parameters. The consent management platform changes behavior.

Each change is a new surface area for breakage. And because the QA is manual, the gap between what's tested and what's deployed keeps growing. Teams that were keeping up six months ago are now drowning, and they can't always explain why — it just takes longer to validate everything.

Multi-region and multi-brand setups make this exponentially worse. An event that works fine on the US site might be broken on the UK site because of a locale-specific code path nobody thought to check.

What automated validation looks like

The fix isn't hiring more people to stare at DevTools. It's automating the validation itself.

Spur replaces the manual DevTools workflow with an AI agent that runs a real browser, performs user flows exactly like a human would, captures all network traffic, and validates event payloads against your expectations. You describe what to check in plain language — "confirm the purchase event contains order_id, revenue as a number, and items as an array" — and the agent handles finding the request, parsing the payload, and reporting pass/fail with the actual data it found.

The same validation that takes a person 2-4 hours runs in under 10 minutes. Every field gets checked, every time. Across Chrome, Safari, and mobile. Across regions. In parallel.

You schedule it to run after every deploy, or daily, or both. When something breaks, you know within minutes — not two weeks later when a report looks wrong.

Where to start

If you're on a data team dealing with this, start with the one event that would cause the most damage if it broke. For most teams that's the purchase or order confirmation event — it's tied directly to revenue attribution and commission payouts.

Document what "correct" looks like: the event name, every required field, expected data types, format rules. Then automate that single check and schedule it to run on every deploy.

Once that's solid, expand to your next highest-priority event. Within a few weeks you'll have automated coverage over the flows that matter most, and your team can get back to the work they were actually hired to do.

The real cost isn't the hours

The hours matter, yes. But the bigger cost is what happens when broken tracking goes undetected. Bad data leads to bad dashboards, which leads to bad decisions. Attribution models trained on incomplete data misallocate budget. A/B tests with corrupted event data produce meaningless results.

Most data teams have experienced this at least once — the sinking feeling of realizing that a key metric has been wrong for weeks because an event silently stopped firing. That's the real tax. And it's entirely preventable.

We all know what happens next

Someone ships a promo banner update. Checkout breaks on mobile Safari. A customer screenshots it on Twitter before Slack even lights up.

Every e-commerce team has this story. Most have it more than once.

The standard playbook is Selenium or Cypress. Write a test, pin it to a CSS selector, pray the selector survives the next sprint. It usually doesn't. A designer moves a button, the merchandising team swaps a carousel, and suddenly half your suite is red. Not because anything is actually broken. Because your tests are brittle.

Manual QA catches what automation misses, but it doesn't scale. You can't manually click through 400 checkout permutations before every deploy. So teams do what teams do: they ship and hope.

What is agentic QA?

Agentic QA replaces brittle test scripts with AI agents that interact with your site visually, the same way a real customer would.

Instead of telling a script "click the element with id=checkout-btn," you tell an AI agent "go buy something." The agent looks at the page, figures out where the checkout button is, and clicks it. When someone redesigns the page, the agent still finds the button. It doesn't care that the class name changed. It can see.

You write tests in plain English. Something like:

"Search for blue running shoes. Add the first result to cart. Apply coupon SAVE20. Go through checkout. Confirm the discount shows up."

That's the whole test. No page objects, no locator strategies, no framework boilerplate. If your site changes next week, the same test still works.

Why e-commerce teams need this most

Most SaaS apps have a relatively stable UI. You build a dashboard, it stays a dashboard. E-commerce is different.

Constant UI changes

Product pages change daily. Promos rotate. A/B tests shuffle layouts. Search results are personalized. The homepage during Black Friday looks nothing like the homepage in February. Selector-based tests can't handle this kind of churn. We've talked to teams where 60-70% of their automation effort goes to maintenance, not new test coverage.

Checkout bugs cost real money

A broken checkout flow isn't just a bug report. It's lost revenue, every minute it's live. Agentic QA tests the full purchase flow end-to-end on every deploy, across payment methods, currencies, and regions, without someone writing a separate script for each combination.

Seasonal pressure

You need the most testing coverage during Black Friday and holiday sales, which is exactly when your team has the least bandwidth to babysit flaky tests. Agentic tests scale without hiring contract QA or pulling engineers off feature work.

Multi-geography complexity

Selling globally means testing across currencies, languages, tax rules, and shipping options. AI agents can run these combinations in parallel without a separate test file for every locale.

What the results actually look like

We've been running agentic QA with e-commerce teams for a while now. Here's what consistently shows up:

How to get started with agentic QA

Nobody should rip out their existing test suite on day one. The smarter approach:

You don't need to learn a new framework or hire automation engineers. If you can describe what your site should do, you can write agentic tests.

The future of e-commerce testing

E-commerce testing complexity is going up. Headless storefronts, AI-generated product content, hyper-personalization, multi-channel selling. The surface area keeps growing, and writing individual scripts for all of it isn't sustainable.

Agentic QA is still relatively early, but the direction is clear. Tests that can see and adapt will replace tests that rely on structural assumptions about your HTML. It's already happening.

If you want to try it, Spur can get your first tests running in about 10 minutes. No scripts, no framework setup. Just describe what your site should do and watch it run.

2025 was a big year for Spur. Here's a look at the features that changed how teams create and run automated tests using natural language, from smarter ways to model scenarios and organize suites to richer execution, debugging, and integrations that plug directly into the tools teams already use every day.

Scenario Tables

Scenario Tables help you create dynamic tests that handle multiple scenarios within a single user flow using parameterized test data.

Instead of maintaining many nearly identical tests with different inputs, you define one test and run it through multiple rows of data, which reduces redundancy, improves maintainability, and makes it easier to cover variations and edge cases.

Environments and Browsers

Spur lets you run the same test suites across multiple environments such as dev, staging, and production without duplicating suites.

By configuring Environments and Environment Values, you can centralize environment-specific settings and then run suites across deployments, making it easier to compare results and maintain consistent test logic.

Test Plans and Suites

A test suite in Spur is a collection of related tests that validate specific functionality, with Flow View giving you a visual representation of test dependencies.

When you run a test suite, Spur executes tests in order, respects dependencies, and provides real-time feedback on status, progress, errors, and execution time, which makes Test Plans and suites a foundation for organizing your testing around features and user journeys.

Bulk Actions and Retry-style workflows

Spur supports multiple test execution methods, including scheduled tests, cached tests, manual execution, and CI/CD, so you can repeatedly run suites and tests as part of your regular workflow.

Using features like scheduling, snoozed tests, and cached runs, teams can re-run tests and keep execution focused on the most relevant suites, which functions as a practical retry pattern for stabilizing and iterating on coverage over time.

Reporting, Debugging, and Integrations

The Spur Dashboard gives a centralized view of currently running tests, past runs, scheduled tests, and recent failures, making it easier to monitor results and understand your testing environment.

For deeper analysis and debugging, Spur provides Statistics, full browser observability, video replay, console and network logs, and agent logs, so you can see step-by-step what happened in a run.

Spur's integrations turn those results into action.

With Jira and Linear, you can create detailed tickets directly from failures with screenshots, logs, and reproduction steps, while Slack, Email, and GitHub integrations handle real-time notifications, reports, and automated workflows in your existing tooling.

The Early Days of Customer Success

Something we started doing from even before Spur was born was talking to customers and validating the problem. At Spur, we've internalized a simple truth: our customers' success is our success.

Why Invest So Heavily in CS?

At Spur, we believe quality is core to every digital experience. No matter the company, everyone who has a digital presence wants to provide a high-quality journey for their customers and users - and that starts with testing.

Spur is an AI-native platform powering that foundation. Our product runs every day, with every release, and directly impacts how companies perform. But our agentic, AI-driven approach to testing is a shift from the old model—and that means it requires deep customer understanding.

Customer Success is a Team Sport: Company-Wide Integration

We insist customer success is a team sport. We've woven customer-centric thinking into the DNA of every department.

Everyone at Spur is deeply integrated in Customer Success. This diagram illustrates our holistic CS framework: the customer journey stages (onboarding, activation, expansion) are supported by Spur's services (blue circles on the left), measured by key metrics (green diamonds on the right), and fueled by a cross-functional team effort (bottom).

Engineering:

Our engineers don't hide behind feature backlogs and sprint boards, isolated from end-users. Instead, each engineer looks over 2–3 customer accounts. In practice, that means developers regularly sit in on customer calls and Spurring Sessions for the accounts they own.

Design:

‍Our design team is equally involved. Great UX in an AI-driven testing tool can be a differentiator, so our designers want to understand users deeply. They routinely analyze PostHog sessions and other analytics to see which features customers use and where they might get stuck.

Sales:

‍You might wonder, where does Sales fit after the deal is signed? At Spur, Sales doesn't throw the customer over the wall and disappear. Our sales team stays involved as a stakeholder in the customer's ongoing success. In fact, during handoff, the salesperson spends extensive time (often 3+ hours over multiple meetings) with the new customer.

Spurring Sessions and the Power of Continuous Feedback

While Spur is a SaaS product, we offer customer support to all of our customers. Earlier we mentioned Spurring Sessions – a term you won't find in a generic CS handbook, because it's something we coined at Spur. Spurring Sessions are essentially high-touch, collaborative working sessions with our customers. Think of them as a blend between a coaching call, a consulting session, and a feedback forum, all rolled into one.

What makes Spurring Sessions particularly powerful is how they feed into our continuous feedback loop. Every session is an opportunity not just for the customer to learn from us, but for us to learn from the customer. For example, during a session, a customer might ask, "Can Spur do X?" If we hear questions like that repeatedly, it's a huge flag for us to improve UI or develop a new feature.

At Spur, customer success isn't just a department—it's a mindset. It shapes how we build, how we ship, and how we support. In an AI-first world, where technology evolves rapidly, the human feedback loop becomes even more essential. That's why we'll keep showing up—week after week, session after session—to ensure every customer gets more than a tool. They get a partner in quality.

Agentic AI: The New Backbone of Resilient E-Commerce

Tariffs are climbing, uncertainty around global trade is at an all-time high, and online brands are facing immense pressure to cut costs without sacrificing quality or customer experience. Yet amid the uncertainty, a clear message is emerging from forward-thinking ecommerce brands: now's the time to innovate.

AI is pivotal in transforming e-commerce by enhancing operational efficiency, making it essential for businesses aiming to thrive in today's digital economy. - Brian Priest, CFO of eBay

One clear area of opportunity is in leveraging Agentic AI for your QA stack. QA is a high leverage space because it's work no engineer wants to be doing and, by freeing them up, they can devote their efforts to important tasks like new product development and innovation.

Maximize QA Impact on a Tighter Budget

QA testing has historically been a manual, resource-intensive process. With tariffs straining budgets, there's no room for inefficiency. AI agents automate repetitive test cases, catching critical errors early and freeing your team to focus on growth, not maintenance.

Protect your price-sensitive customers

With margins under threat, every bug becomes more costly. 89% of consumers say they'll abandon a brand after a negative digital experience—especially if they're feeling economic pressure. Agentic AI catches nuanced errors human testers might miss, protecting your reputation and revenue and boosting conversions.

Transform Core QA Processes with Agentic AI

1000+ tests in a month isn't just fast. It's what made bi-weekly releases and real test confidence possible. - Chloe Lu, E-Commerce Manager, LivingSpaces.com

Companies that adopt AI-driven testing see 50% faster test execution and 70% less test maintenance. These aren't marginal improvements—they're foundational changes. Agentic AI continuously adapts to site changes, UI updates, and user behavior, keeping your QA agile and responsive.

Cut real costs

With tariffs and tightening budgets, doing more with less isn't optional—it's essential. AI-powered QA helps teams expand test coverage, deploy confidently, and scale sustainably, all while reducing overhead.

Agentic AI isn't a luxury for calmer times; it's your strongest hedge against uncertainty today.

ROI with Spur

Spur's agentic AI helps e-commerce teams save time, cut costs, and deliver better digital experiences. Here's what our customers see:

- Up to 90% cost reduction in test case creation and maintenance
- 2–3× faster release cycles, powered by AI agents that execute and adapt in minutes
- 80–95% bug detection accuracy, even in edge cases manual QA typically misses
- >90% test coverage across critical revenue flows, with zero added headcount
- Less churn, more conversions: brands avoid the hidden cost of broken experiences

When we started Spur, we kept hearing the same frustrations from engineering teams: "Setting up automated testing takes months," "We don't have dedicated QA engineers to write test scripts," "Our tests break every time we update the UI." These aren't unreasonable concerns - the testing world is littered with automation projects that drag on for quarters, require specialized technical expertise, and create more maintenance headaches than they solve.

Companies approached implementation inefficiently. Unlike other tools with one-size-fits-all implementation, Spur curates a personalized experience for each customer.

Introduction to Agentic QA sessions tailored to you. Most testing tools treat every setup the same way, ignoring your specific application and business needs. We do the opposite. We study what works and create a personalized experience for each customer. The result is our 1-week pilot program that combines preparation with hands-on guidance designed around your team's needs.

Why Personalized Onboarding Changes Everything

At Spur, we've internalized a simple truth: your testing success is our success. Quality is core to every digital experience, and that starts with understanding your specific challenges before we ever touch your application.

Every pilot begins with custom preparation tailored specifically for your company. Before Day 1 of your pilot, our team has already analyzed your application, studied your user flows, and prepared personalized recommendations that align with your business priorities. We don't just demo our tool - we create an experience designed around your unique testing needs.

The key insight was this: while every application is unique, the fundamentals of successful test automation follow predictable patterns. We weren't implementing a testing tool - we were onboarding your AI QA engineer while simultaneously building a resilient QA program that scales with your growth.

This shift in perspective changed everything. Instead of technical setup phases, we now think about personalized onboarding phases: introducing Spur to your specific application context, training it on your critical user journeys, and helping you build testing practices that grow with your team. Just like you wouldn't throw a new QA engineer into testing without proper context, Spur needs to understand your application deeply and align with your team's goals.

The 1-Week Personalized Pilot Framework

Pre-Pilot Custom Preparation (1-2 weeks)

Before your pilot begins, we analyze your application, identify your highest-priority user flows, and prepare recommendations tailored to your development workflow. You get an experience built specifically for your team from day one.

Our customers typically fall into two categories:
1. Modernizing existing QA Practices - Moving from current automation frameworks to an AI-driven approach with Spur
2. Building a QA Program from scratch - No existing automation structure, everything is manual or ad-hoc

Phase 1: Discovery & Alignment
We start by understanding your current testing workflow (Automation Frameworks, Teams, Reporting Practices). We will recommend a pilot program depending on where your team is currently at with testing: Modernization / Building a Program.

Phase 2: Scope & Prioritization
We identify your highest-impact user flows and create a testing roadmap aligned with your development workflow.

Phase 3: AI Training for the Team
We prepare your team with personalized training on how to work effectively with AI-driven testing.

Phase 4: Onboarding and High Velocity 1-Week Pilot
Everything is set up for a smooth transition into your intensive pilot week. We recommend specific features on Spur based on the top use-cases on the platform to make sure teams make the most out of the pilot period.

1-Week High-Velocity Pilot

Day 1: Kickoff & Introduction to Agentic QA
Onboarding and Spur deep dive to get your team familiar with AI-driven testing approaches.

Day 2: Use Cases Covered with Your Application & Spur Functionality
Using our deep understanding of your specific application, we help you describe your key testing scenarios in natural language. "Test that users can complete checkout with different payment methods" becomes a sophisticated test suite designed around your exact payment integration, user interface, and edge cases we've identified specifically for your application.

Days 3-5: Hands-On Test Writing
Focus on onboarding and covering your critical user flows. Spur runs your tests while we provide guidance tailored to your team's workflow. We don't just show you test results - we help you understand how to build testing practices that work for your specific development process and scale with your product changes.

Ongoing Throughout Week: Spurring Sessions
Ad-hoc, on-demand support sessions available as needed. Our team is here to support and ensure your success throughout the way.

End of Week: Pilot Wrap Up
By the end of the week, you have major ROI to show -- Coverage Achieved, Bugs Found, Team Members Onboarded & Process Established.

Our Team will work with you to build your business case post pilot as well. Leave it to us!

‍

Results That Speak Volumes

The results consistently demonstrate the power of this personalized, tailored approach. Teams that complete our 1-week pilot typically see immediate value, with many expanding to comprehensive test coverage within their first month - guided by the customized recommendations we develop together.

What we've learned building Spur is that the teams that succeed with AI testing aren't necessarily the most technical or the largest, but the ones that get personalized guidance that fits their specific challenges, workflow, and team dynamics.

“The cookie banner appears at random points of the flow – major cause of test flakiness with traditional automation. Spur handled it automatically.”

“I love seeing that actually many of the times automation tests do fail. Oh, there is this unexpected pop-up and now you have to insert some additional code in there to handle it.”


“Seeing you roll out small fixes within a day is great—that velocity matters to us!”

“Issues got triaged same-day, often within hours.”

What we've learned building Spur is that the teams that succeed with AI testing aren't necessarily the most technical or the largest, but the ones that get personalized guidance that fits their specific challenges, workflow, and team dynamics.

Beyond Implementation: Building Testing That Scales

What sets Spur apart isn't just our AI technology - it's how we tailor the entire experience to your team's specific needs. We don't just automate your current processes; we help you build testing practices that grow with your product and team.

During your pilot week, you get dedicated guidance from our team who understands both the technical aspects of your application and the practical realities of your development workflow.

Every recommendation we make is designed around helping your team build resilient testing that becomes an accelerator for development velocity, not a bottleneck - all tailored to how your specific team works and grows.

Ready to see how quickly your team can achieve reliable, maintenance-free test automation with guidance tailored specifically to your needs? Reach out to learn more about our 1-week pilot program!

‍

The holiday shopping season isn't just coming. It's already here. With Deloitte forecasting up to $1.62 trillion in U.S. retail sales between November 2025 and January 2026, ecommerce teams are facing unprecedented pressure to deliver flawless digital experiences at scale. But there's a problem: traditional QA approaches weren't built for the complexity and velocity that modern holiday commerce demands.

The Scale Problem Traditional QA Can't Solve

Modern ecommerce platforms must test an impossible matrix before the holiday season: multiple payment providers across devices, BOPIS workflows, inventory sync, email campaigns reaching millions, mobile apps on dozens of OS combinations, flash sales under extreme load, personalization algorithms, and cross-border transactions.

The math doesn't work. Even with dedicated resources, testing every critical journey across these touchpoints takes weeks—time you don't have when deploying daily features and promotions in November and December. Manual testing doesn't scale, scripted automation breaks constantly, and by the time your team finds a critical bug, thousands of customers have already hit it.

How Agentic QA Works Around the Clock

Agentic QA operates fundamentally differently. AI agents autonomously explore your application 24/7, discovering issues before customers encounter them.

While your team sleeps, agents are:
- Executing thousands of realistic user journeys
- Testing new deployments immediately
- Validating checkout and payment flows
- Monitoring performance degradation
- Adapting coverage based on real usage patterns

From Reactive Fire Drills to Proactive Confidence

The typical drill: two weeks before Black Friday, QA works nights and weekends, developers abandon features to fix bugs, product managers nervously monitor every deployment. Reactive, exhausting, and still incomplete.

Agentic QA flips this entirely. By November, AI agents have continuously validated your platform for months, delivering:

Real-time visibility into what's working and breaking across every critical journey

Automatic adaptation when you deploy new promotions or products—no new test scripts required

Edge case coverage human testers miss: customers who abandon cart twice, switch payment methods mid-transaction, or stack multiple promo codes

Handling the Complexity Modern Commerce Demands

Today's ecommerce platforms are exponentially more complex than three years ago. AI-powered recommendations, real-time inventory, dynamic pricing, and AR try-ons each create new failure points. Traditional QA teams can't manually test every integration, maintain scripts through constant UI changes, and keep pace with daily releases. It's technically impossible at modern scale.

Agentic QA handles this by understanding your application holistically. When you add a buy now, pay later provider, AI agents automatically test it across all platforms. When your personalization engine changes, agents validate that the entire purchase flow still works. This isn't faster automation. It's an intelligent system that thinks like your best QA engineer but operates at machine speed and scale.

The Black Friday Reality

Black Friday traffic doesn't increase steadily. It spikes unpredictably. A viral post can send 50,000 users to one product page in minutes, overwhelming your checkout flow in seconds.

Traditional load testing prepares for expected patterns. But modern ecommerce is unpredictable. You need QA that continuously validates system behavior under real conditions, identifies degradation before it becomes catastrophic, and handles whatever the holiday season brings.

Agentic QA runs constantly against production-like environments, catching performance issues and race conditions that only surface under real-world complexity. When traffic patterns shift, AI agents automatically focus testing on the highest-load user journeys.

Making the Shift Now

If last year's holidays exposed testing gaps—downtime, customer complaints, revenue-impacting bugs—now is the time to evolve.

The winning teams this season aren't adding more manual testers or Selenium scripts. They're deploying intelligent, autonomous QA systems working 24/7 to ensure flawless customer interactions.

The question isn't whether your platform will be tested. It's whether your testing can match the scale of what you're about to face.

Start your journey toward autonomous holiday readiness with Spur's agentic QA platform. The best time to prevent Black Friday failures is right now.

Get Your Free Holiday Ecommerce Test Pack

Not sure where to start with your holiday testing strategy? We've created a comprehensive Holiday Ecommerce Test Pack that includes:

- Critical test scenarios for Black Friday/Cyber Monday readiness
- Checkout flow validation checklists
- Payment integration test cases
- Mobile commerce testing templates
- Performance monitoring guidelines

Enter your email below to get instant access to the Holiday Test Pack and ensure your platform is ready for the busiest shopping season of the year.

‍

2025 was a big year for Spur. Here's a look at the features that changed how teams create and run automated tests using natural language, from smarter ways to model scenarios and organize suites to richer execution, debugging, and integrations that plug directly into the tools teams already use every day.

Scenario Tables

Scenario Tables help you create dynamic tests that handle multiple scenarios within a single user flow using parameterized test data.

Instead of maintaining many nearly identical tests with different inputs, you define one test and run it through multiple rows of data, which reduces redundancy, improves maintainability, and makes it easier to cover variations and edge cases.

Environments and Browsers

Spur lets you run the same test suites across multiple environments such as dev, staging, and production without duplicating suites.

By configuring Environments and Environment Values, you can centralize environment-specific settings and then run suites across deployments, making it easier to compare results and maintain consistent test logic.

Test Plans and Suites

A test suite in Spur is a collection of related tests that validate specific functionality, with Flow View giving you a visual representation of test dependencies.

When you run a test suite, Spur executes tests in order, respects dependencies, and provides real-time feedback on status, progress, errors, and execution time, which makes Test Plans and suites a foundation for organizing your testing around features and user journeys.

Bulk Actions and Retry-style workflows

Spur supports multiple test execution methods, including scheduled tests, cached tests, manual execution, and CI/CD, so you can repeatedly run suites and tests as part of your regular workflow.

Using features like scheduling, snoozed tests, and cached runs, teams can re-run tests and keep execution focused on the most relevant suites, which functions as a practical retry pattern for stabilizing and iterating on coverage over time.

Reporting, Debugging, and Integrations

The Spur Dashboard gives a centralized view of currently running tests, past runs, scheduled tests, and recent failures, making it easier to monitor results and understand your testing environment.

For deeper analysis and debugging, Spur provides Statistics, full browser observability, video replay, console and network logs, and agent logs, so you can see step-by-step what happened in a run.

Spur's integrations turn those results into action.

With Jira and Linear, you can create detailed tickets directly from failures with screenshots, logs, and reproduction steps, while Slack, Email, and GitHub integrations handle real-time notifications, reports, and automated workflows in your existing tooling.