> 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/codeless-vs-coded.md).

# Codeless vs coded test automation

The choice is not only “code or no code.” It is whether you want to **run great QA** in a complete product, or **run a second engineering effort** to build and operate a framework stack.

DoesQA is codeless end-to-end testing for web journeys: testers author Flows, hosted runners execute them, and Results stay trustworthy. Coded frameworks such as Playwright, Cypress, and Selenium are powerful when your main job is engineering automation itself. For the product versus framework comparison, see [DoesQA, Playwright, Cypress, and Selenium compared](/choosing-a-test-automation-approach/doesqa-compared.md).

## When DoesQA fits

Choose DoesQA when you value **great QA** over managing a second dev team and all the complexities that come with it: repositories, runners, reporters, flake debates, and a web of integrations.

DoesQA fits when you want to:

* Let people with basic automation knowledge build and maintain coverage in the [Scenario editor](/platform/scenario-editor.md) and [Flow Builder](/platform/flow-builder.md)
* Keep runners, Results, schedules, and common journey features in one product
* Grow real user journeys quickly, including email, MFA, accessibility, SEO, and performance ([Coverage and speed](/choosing-a-test-automation-approach/coverage-and-speed.md))
* Maintain shared Elements, Step Groups, and branches in minutes, not across a coded codebase ([Maintenance and reliability](/choosing-a-test-automation-approach/maintenance-and-reliability.md))
* Trust red Results and a single owner for the platform ([Maintenance and reliability](/choosing-a-test-automation-approach/maintenance-and-reliability.md#how-reliable-are-doesqa-tests))

You still get engineering-grade outcomes: parallel Runs, CI/CD triggers, and clear evidence on every Test Case. You do not need a dedicated automation-engineering organisation to keep the stack alive.

## When a coded framework fits

Choose a coded framework when your **main job is not browser end-to-end journeys** for a website, or when non-web / non-browser systems are the centre of the work.

Coded frameworks also fit teams that already treat automation as a software product of its own: every detail in their repositories, every integration owned in-house, and the calendar time to maintain that machine. With enough time and skill you can assemble most of what DoesQA includes. See the [hidden costs of free](/choosing-a-test-automation-approach/doesqa-compared.md#hidden-costs-of-free) frameworks.

If the job is web E2E quality at scale, DoesQA is built for that job.

## What you need alongside DoesQA

For **end-to-end browser coverage**, teams often need **nothing else**. DoesQA is the product for those journeys: authoring, runners, Results, and the steps that follow real users.

Other layers stay optional and complementary when your quality strategy includes them, for example:

* Unit tests close to application code
* Heavy load or stress tools for volume beyond a functional pack

DoesQA sits as the product-facing E2E safety net you can run at scale and trust. It does not force you to rip out every other check you already value.

## How the work gets built

|                       | Coded frameworks                                            | DoesQA                                                                                                                                            |
| --------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| How tests are written | In code, often with Playwright, Cypress, or Selenium        | In the [Scenario editor](/platform/scenario-editor.md) or [Flow Builder](/platform/flow-builder.md)                                               |
| Who can contribute    | People comfortable writing and reviewing automation code    | Testers who know the journey, with basic automation knowledge                                                                                     |
| What you operate      | Framework plus runners, reporting, and add-ons you assemble | One product: Flows, runners, Results, and journey features included                                                                               |
| Reuse                 | Shared helpers and page objects you design                  | [Elements](/elements/creating-elements.md), [Values](/values/value-store.md), and [Step Groups](/better-coverage/reuse-steps-with-step-groups.md) |

## Support that matches the product

DoesQA includes **amazing support** with the product. When something is unclear or blocked, you talk to people who own the same platform your Tests run on, not a chain of framework and runner vendors.

If you also want help building or expanding coverage, DoesQA offers outsourced QA on the same Flows and Results. See [DoesQA, Playwright, Cypress, and Selenium compared](/choosing-a-test-automation-approach/doesqa-compared.md#outsourced-qa).

## See DoesQA in practice

* [Create and run your first Flow](/getting-started/create-and-run-your-first-flow.md)
* [DoesQA concepts](/getting-started/doesqa-concepts.md)
* [DoesQA, Playwright, Cypress, and Selenium compared](/choosing-a-test-automation-approach/doesqa-compared.md)
* [Hidden costs of free](/choosing-a-test-automation-approach/doesqa-compared.md#hidden-costs-of-free)
* [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)