> For the complete documentation index, see [llms.txt](https://docs.does.qa/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.does.qa/choosing-a-test-automation-approach/doesqa-compared.md). # DoesQA, Playwright, Cypress, and Selenium compared Playwright, Cypress, and Selenium are coded frameworks for browser automation. DoesQA is a complete testing product: [Scenario editor](/platform/scenario-editor.md), [Flow Builder](/platform/flow-builder.md), hosted Test Runners, Results, schedules, and the journey features teams usually assemble themselves. If you are comparing tools, start with whether you are buying a **framework** or a **product**, then check the journeys and costs that sit around the tests. ## Is DoesQA just a wrapper around Playwright or Selenium? No. DoesQA is not a thin UI on Playwright or Selenium. DoesQA is the full stack your team runs every day: * Authoring in the Scenario editor and Flow Builder * Tried and tested [Test Steps](/getting-started/terminology.md) shared across every customer * Hosted Test Runners included with the product * Results with step timeline, screenshots, and video * Schedules, recipes, CI/CD triggers, and notifications A framework gives you APIs to drive a browser. You still design the suite, host or buy runners, wire reporting, and integrate mail, MFA, accessibility, and the rest. DoesQA ships that as one product. When something fails, it is DoesQA's responsibility to fix the platform. See [Maintenance and reliability](/choosing-a-test-automation-approach/maintenance-and-reliability.md). ## Hidden costs of free Playwright, Cypress, and Selenium are free to download. The expensive part is everything around them. Those costs show up as people, tools, and calendar time, not a licence line. | Cost | What teams pay for with a free framework | | ------------------------ | ------------------------------------------------------------------------------ | | Runners | Host browsers yourself, or buy a third-party cloud runner and integrate it | | Third-party integrations | Mail inbox, MFA helpers, a11y libraries, visual services, reporters, storage | | Creating tests | Engineering time to write and review automation code | | Running tests | Pipeline design, concurrency, flake retries, and waiting on serial suites | | Understanding failures | Dev time reading logs and stack traces across your stack and the runner vendor | | Flakiness | Time wasted re-running Tests and debating whether the app or the suite failed | | Ownership gaps | Runner vendor blames your tests; your team blames the runner | DoesQA puts authoring, runners, Results, and common journey features in one product so those costs stay inside a system you can trust. For how fast a large pack can run, see [Coverage and speed](/choosing-a-test-automation-approach/coverage-and-speed.md#how-quickly-can-doesqa-run-a-regression-suite). For flake-free Results and single-vendor ownership, see [Maintenance and reliability](/choosing-a-test-automation-approach/maintenance-and-reliability.md). Coded frameworks can still reach most of the same ground if your team has the **time and skills** to build and maintain the missing pieces. The question is whether that investment is what you want to own. ## Build model | | Playwright | Cypress | Selenium | DoesQA | | ------------------- | ------------------------------------ | ------------------------------------ | ------------------------------------ | --------------------------------------------------------------------------------------------- | | How you build tests | Code | Code | Code | [Scenario editor](/platform/scenario-editor.md) and [Flow Builder](/platform/flow-builder.md) | | Who maintains them | Engineers and SDETs who own the code | Engineers and SDETs who own the code | Engineers and SDETs who own the code | Testers working in DoesQA | | Branching journeys | You design the structure in code | You design the structure in code | You design the structure in code | [Flow Branches](/getting-started/doesqa-concepts.md) create Test Cases from shared steps | ## Platform around the tests | | Playwright | Cypress | Selenium | DoesQA | | ------------------------- | ---------------------------------------------------- | ---------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------- | | Test runners | You host them or use a cloud service | You host them or use a cloud service | You host them or use a cloud service | Included Test Runners from signup | | Screenshots and video | Available; storage and review are part of your setup | Available; storage and review are part of your setup | Available; storage and review are part of your setup | Stored with the Run | | Scheduling | Usually through CI or your own jobs | Usually through CI or your own jobs | Usually through CI or your own jobs | [Schedules](/configuration/schedules.md) | | Result notifications | Usually through CI or added services | Usually through CI or added services | Usually through CI or added services | [Slack](/configuration/notifications/slack.md), email, and webhooks | | Reusable step collections | Shared code you maintain | Shared code you maintain | Shared code you maintain | [Step Groups](/better-coverage/reuse-steps-with-step-groups.md) | ## Journey coverage DoesQA is built so a Flow can follow real user journeys end to end, including paths coded teams often split across tools or leave thin: | Journey | DoesQA | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Register with email confirmation | [Registration and email verification](/guides/test-registration-and-email-verification.md) | | Log in with MFA | [Test MFA login](/guides/test-mfa-login.md) | | Forgotten password | [Forgotten-password guide](/guides/test-a-forgotten-password-flow.md) | | Checkout and payments | [Checkout guide](/guides/test-checkout-and-payments.md) | | Post-login accessibility | [Accessibility checks](/better-coverage/add-accessibility-checks.md) on authenticated pages | | Dynamic UI (modals, popups, overlays) | Ordinary steps on Elements that appear mid-journey | | SEO and load time | [SEO](/better-coverage/test-seo.md) and [performance](/better-coverage/test-page-performance.md) beside the functional path | | Tabs, windows, frames, files, API-in-UI | [Windows and frames](/guides/test-tabs-windows-and-frames.md), [files](/guides/test-file-uploads-and-downloads.md), [API in a Flow](/guides/test-apis-in-a-flow.md) | Full journey and capability detail: [Coverage and speed](/choosing-a-test-automation-approach/coverage-and-speed.md). ## Journey capabilities These are areas where teams usually add libraries or services around a framework. In DoesQA they are Test Steps or product features inside an ordinary Flow. With enough time and skill, a coded team can assemble most of these; DoesQA ships them together. | Capability | Playwright | Cypress | Selenium | DoesQA | | ------------------------------------ | --------------------------- | -------------------------------- | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Mouse, keyboard, and standard checks | Core framework | Core framework | Core framework | [Action](/test-steps/action/touch.md) and [Check](/test-steps/check/check-displayed.md) Test Steps | | Tabs, windows, and frames | Core framework | More limited in the core product | Core framework | [Browser](/test-steps/browser/next-tab.md) and [Runner](/test-steps/runner/switch-frame.md) Test Steps | | Shadow DOM | Core framework | Core framework | Core or added setup | [Shadow DOM](/elements/selector-types/shadow-dom.md) Selectors | | Visual checks | Framework or added tools | Usually added tools or services | Usually added tools or services | [Element Snapshot](/test-steps/vision/element-snapshot.md) and [Element Position](/test-steps/vision/element-position.md) | | Accessibility | Usually added libraries | Usually added libraries | Usually added libraries | [Accessibility](/test-steps/validator/accessibility.md), [Axe](/test-steps/validator/axe.md), and [Pa11y](/test-steps/validator/pa11y.md) | | SEO and performance checks | Usually added libraries | Usually added libraries | Usually added libraries | [SEO](/test-steps/validator/seo.md) and [Performance](/test-steps/validator/performance.md) | | Test email inbox | Usually an external service | Usually an external service | Usually an external service | [Mail](/test-steps/mail/wait-for-email.md) Test Steps | | MFA tokens | Usually an external helper | Usually an external helper | Usually an external helper | [Set MFA](/test-steps/action/set-mfa.md) and [MFA](/configuration/mfa.md) | | API and SFTP steps | Core or added code | Core or added code | Core or added code | [Integration](/test-steps/integration/get.md) Test Steps | | File generation and upload | Core or added code | Core or added code | Core or added code | [Generate File](/test-steps/runner/generate-file.md) and [File](/test-steps/action/file.md) | ## What the same test looks like In DoesQA, a journey is a list of plain-language steps on the Scenario tab or chips on the Flow Builder canvas: Open, Touch, Check, Wait for email, Set MFA, and the rest. Testers with basic automation knowledge can read and edit that Flow. In Playwright, Cypress, or Selenium, the same journey is code: page objects or locators, asserts, waits, and helpers your team owns in a repository. Engineers and SDETs create and review that code, then connect runners and reporting around it. Both can prove a website. DoesQA optimises for speed of creation and maintenance inside the product. Coded frameworks optimise for teams that already treat automation as engineering work. See [Codeless vs coded test automation](/choosing-a-test-automation-approach/codeless-vs-coded.md). ## Outsourced QA If your team wants DoesQA experts to help build or expand coverage, DoesQA also offers outsourced QA. The product stays the same: Flows, Runs, and Results in DoesQA, whether your testers or ours author the pack. ## How to use this comparison 1. Decide whether you want to own a coded framework stack or a complete product. 2. Add up the [hidden costs of free](#hidden-costs-of-free) for your team size. 3. Confirm the journeys on [Coverage and speed](/choosing-a-test-automation-approach/coverage-and-speed.md). 4. Confirm maintenance and reliability on [Maintenance and reliability](/choosing-a-test-automation-approach/maintenance-and-reliability.md). ## Related * [Codeless vs coded test automation](/choosing-a-test-automation-approach/codeless-vs-coded.md) * [Coverage and speed](/choosing-a-test-automation-approach/coverage-and-speed.md) * [Maintenance and reliability](/choosing-a-test-automation-approach/maintenance-and-reliability.md) * [Security and trust](/choosing-a-test-automation-approach/security-and-trust.md) * [DoesQA concepts](/getting-started/doesqa-concepts.md) * [Create and run your first Flow](/getting-started/create-and-run-your-first-flow.md)