%20(1).png)
A checkout test passes. Does that mean the discount was applied correctly, the mobile app worked, and the result is recorded against the release requirement? The answer depends partly on what your testing platform was designed to manage.
PhotonTest and Spur both help teams create and execute tests with AI. PhotonTest brings test case management, automation creation, and execution into one QA workflow. Spur centers on AI agents that interact with web and mobile applications to validate user journeys. There is substantial overlap: both support natural-language test creation, existing-test imports, organized suites, and CI/CD workflows. The differences become clearer when you examine how each capability works in practice.
PhotonTest vs Spur at a Glance
The table reflects the vendors’ published materials, not an independent test of either product. Here is what each row means for a QA team.
1. Primary Focus: What Is the Platform Built Around?
PhotonTest puts the test case and its lifecycle at the center. A team can create or import cases, organize suites and preconditions, generate automation, review tests, run them, and inspect results. That makes it relevant when QA work currently spans a test management tool, a separate automation project, and spreadsheets or reports used to connect the two. PhotonTest’s value proposition is the continuity between those activities.
Spur puts executable validation at the center. Its agents interact with the application to check whether a flow works. Spur describes use across pull requests, pre-release regression, launch validation, and ongoing production checks. Its documentation also contains substantial test organization and analysis functionality, so describing it as only an execution tool would miss part of the product. Still, its clearest emphasis is getting user journeys running frequently across web and mobile surfaces.
Imagine a team with 600 established cases and a requirement to show which tests were reviewed for each release. PhotonTest’s management-first workflow may be especially relevant. A team whose immediate problem is validating checkout across browsers, mobile, locales, and production several times a day may find Spur’s agent-led approach more directly aligned with the work.
2. Starting Point: How Do You Create the First Test?
PhotonTest offers several routes into automation. Teams can describe a flow and expected result in natural language, create cases in its test management system, or import existing cases from sources including TestRail, Qase, and Xray. Its agentic automation page also describes starting from a Jira ticket, user story, requirement, or product specification; agents generate scenarios and automation code for review. This makes existing QA documentation a potential starting asset rather than something the team must rewrite before automating.
Spur has a broad set of authoring inputs too. Its documentation describes writing steps manually, generating steps from a video or Loom recording, uploading an automation script, and using AI to generate tests from files, existing suites, or a plain-language description. Spur’s site says it can import cases from tools such as qTest and Zephyr and turn them into runnable tests. It can also generate parameterized scenario tables, allowing one test to run with multiple sets of data.
What to verify in a pilot: Import five representative cases, including one with setup conditions, test data, and a precise expected result. Check what survives the import, what the AI infers, and how much editing is needed before the test can be trusted. “Supports import” alone does not tell you how faithfully a complicated case becomes an executable one.
3. Test Organization: Can the Team Manage Coverage Over Time?
PhotonTest describes a test management system for cases, suites, preconditions, and execution history. Its pricing page lists roles and permissions in the free Start plan. The Business plan adds requirements traceability, test reviews and approvals, and advanced reporting. Its test case management page also describes version history and audit trails. These are relevant when a team needs to understand why a test exists, who changed it, and how it connects to the feature being released.
Spur has a more developed organization layer than a simple list of agent prompts. Tests belong to suites; folders group suites by product area or team. Scenario tables hold reusable data variations. Test plans combine suites for runs across environments, browsers, and viewports, while saved configurations and schedules make those runs repeatable. Its review flow lets a tester work through failures and warnings, add notes, edit tests, create bug tickets, and export a PDF.
The distinction is therefore not “PhotonTest organizes tests; Spur does not.” Both do. The closer comparison is between PhotonTest’s stated emphasis on managing test cases and requirements through a QA lifecycle and Spur’s emphasis on organizing executable suites, configurations, and run review. Teams that need formal case approval or requirements traceability should inspect those workflows in PhotonTest’s relevant plan. Teams that need complex combinations of environments and test data should inspect Spur’s test plans and scenario tables.
4. Execution Approach: What Happens When a Test Runs?
PhotonTest describes multiple execution options: its own infrastructure, connected device farms, and AI-powered execution. Its product and automation pages also describe generating test code for standard frameworks such as Selenium, Cypress, and Playwright, reviewing that code, and running it within an engineering workflow. The important point is flexibility: PhotonTest presents both managed execution and an approach where the team can inspect and own generated automation code. The exact execution path available for a particular test should be confirmed during a demo.
Spur describes a different execution model. Its agents operate against the application from the outside, interacting with what a user sees. Spur says a team supplies a URL for a web application or a build file for a native app; access to the codebase is not required for the basic testing flow. Its hosted infrastructure runs the tests, and results can include video, screenshots, steps, console logs, and network evidence. Spur also supports parallel runs across selected environments and browsers.
These approaches raise different evaluation questions. For PhotonTest, ask to inspect generated code and see how a test is updated after a product change. For Spur, ask to watch the agent handle an ambiguous UI state and then examine the evidence behind its pass or fail decision. For either product, a successful run is less useful if the team cannot explain what was checked and diagnose a failure.
5. Manual Testing: Does “Manual Run” Mean a Human Performed the Test?
This terminology matters. PhotonTest explicitly says it supports manual and automated test execution from one platform. That is relevant for teams whose release process still includes exploratory work, manual checks, or cases that are not yet suitable for automation. They can evaluate whether the same system adequately records both kinds of work and their results.
Spur’s “manual run” means a person starts an automated test on demand. Before it begins, that person can select environments, browsers, viewports, platforms, and scenarios. Spur recommends these on-demand runs for debugging and one-off checks, and saved test plans for recurring execution. Its public documentation centers on agent-executed tests; it does not establish an equivalent workflow for a tester to perform a case by hand and record each result as manual execution. That is a product question to verify if manual test management is essential to your team.
A team seeking to automate its regression suite should consider both. A team seeking one record for its human-executed and automated testing should examine PhotonTest’s manual execution workflow closely and ask Spur for a demonstration of any comparable capability.
6. Mobile Testing: What Is Actually Supported?
Spur documents native mobile testing with natural-language steps run on an iOS Simulator or Android Emulator. Its mobile materials describe visually guided interaction with the app: the agent sees the screen and performs actions such as tapping, typing, scrolling, and swiping. In Spur’s run interface, native mobile tests use platform selection, while web tests use browser and viewport selection. That is a meaningful distinction for teams testing a native app rather than only a website displayed at mobile width.
PhotonTest’s execution page lists connected device farms as an option, and its Business plan names BrowserStack, LambdaTest, Sauce Labs, and TestingBot among advanced integrations. Those statements establish a route to connected testing infrastructure, but the public pages reviewed do not specify the same native-app authoring and simulator workflow that Spur documents. A buyer should verify the required platform, device provider, build-upload process, and available evidence in a PhotonTest demo.
If native iOS or Android testing is a primary purchase reason, Spur has the more explicit public description. If the team already relies on a particular device cloud and wants execution connected to its wider test management process, PhotonTest’s integration options deserve investigation. Neither a “mobile” label nor a mobile-sized browser viewport should be treated as proof that a tool covers the native app workflow you need.
7. AI Feature Testing: Can It Handle Outputs That Vary?
Testing an AI search or support chatbot differs from checking whether a fixed price appears on a page. Several answers may be acceptable, while some are irrelevant, unsafe, in the wrong language, or inconsistent with the user’s request.
Spur has a dedicated AI Feature Testing offering. It describes agents that interact with AI search, chat, recommendations, and other AI features as customers would, including unpredictable inputs and multi-step behavior. Its documentation gives a chatbot test example that checks whether replies make sense and meet qualitative expectations. For teams whose product contains customer-facing AI, this is a concrete area to test in a Spur evaluation.
PhotonTest has published guidance on testing non-deterministic software and describes approaches based on behavior, constraints, and acceptable outcomes rather than exact text matches. However, the product pages reviewed do not present a dedicated AI Feature Testing package with a comparable list of supported scenarios. The responsible comparison is to say that PhotonTest discusses the testing problem, while Spur explicitly markets and documents a specialized offering for it. PhotonTest’s ability to validate your particular AI feature should be demonstrated with your own acceptance criteria.
For example, ask both vendors to test a support bot in two languages across a long conversation. Define failures in advance: inventing a refund policy, switching language, or losing an earlier constraint. Then compare the actual checks and evidence, not just whether each tool can start a chat.
8. CI/CD and Integrations: How Does Testing Fit Into Delivery?
PhotonTest lists imports from TestRail, Qase, Xray, and other sources. Its product page names Selenium, Cypress, and Playwright; TestRail and Xray; and CI/CD tools including GitHub Actions, Jenkins, GitLab, and CircleCI. Its pricing page puts Jira and GitHub among basic integrations and lists SAML SSO, device-cloud services, Slack, and Microsoft Teams in Business. PhotonTest also advertises MCP connections to AI assistants. Because these capabilities appear across different product and pricing pages, confirm the exact action and plan you need – for example, importing cases, syncing results, triggering a run, or creating an issue.
Spur documents running test plans through GitHub Actions and GitLab CI/CD, with results on pull or merge requests. It also documents webhook triggers that can be used from other CI/CD systems, including Jenkins and CircleCI. For triage, its integration documentation covers creating issues from failures in Jira, Linear, and Azure DevOps, plus Slack notifications. Spur’s MCP server lets compatible AI assistants discover tests, run them, examine failures, and work with test coverage from an editor or chat.
There is one detail worth checking directly: Spur’s homepage FAQ specifically names GitHub Actions when answering which CI/CD tools it supports, while its documentation also describes GitLab and webhook-based triggers. Ask Spur which integrations are currently available in your proposed plan and whether your team receives the same status checks, merge controls, and artifacts on its chosen platform.
9. Pricing: Which Usage Pattern Changes the Cost?
PhotonTest publishes a free Start plan for up to five seats with test case management, roles and permissions, basic integrations, API access, imports, and MCP access. Its Business plan is listed at $25 per seat per month with monthly billing, or $255 per seat annually on the annual option. Business adds features including requirements traceability, test reviews and approvals, advanced integrations, and reporting. PhotonTest also uses credits for usage-based operations: its site states that one credit equals $0.01 and that consumption varies with the work a test requires. A free seat therefore should not be interpreted as unlimited AI generation or execution.
Spur says its plans are annual and based on test-run volume, not seats. It does not publish a standard price on the homepage; teams book a demo for a quote. Spur says plans include parallel execution and support, and that it flags usage before agreeing on changes rather than automatically billing overages. It also says higher tiers include full test management, so a quote should specify which management features are included.
The two prices cannot be compared by looking only at seats or only at the number of tests stored. Model a real month: number of users, tests created, test runs, browser and environment combinations, scheduled production checks, and expected growth. A five-person team running a small suite occasionally has a different cost profile from a twenty-person team checking several locales every hour.
Which Platform Fits Your Team?
PhotonTest is the stronger candidate to investigate when you want the test case, its review history, manual work, generated automation, and execution results connected within a broader QA process. It is also relevant if your team wants to inspect and own framework-based automation produced from existing cases or requirements.
Spur is the stronger candidate to investigate when the pressing need is frequent agent-led execution of customer journeys, particularly across native mobile apps, AI features, multiple environments, or production. Its detailed documentation for scenario tables, test plans, scheduled runs, and failure review makes it more than a simple prompt-to-test interface.
A useful evaluation should give both platforms the same three challenges: migrate an existing complex case, catch an intentionally introduced business-logic defect, and adapt after a UI change. Add a native mobile or AI-feature scenario if either is central to your product. Review the test definition, execution evidence, maintenance work, and projected cost after repeated runs. That will reveal more than a feature checklist can.
