Selenium vs Cypress vs Playwright: Choosing an Automation Testing Framework for QA Teams in Indonesia
Over the past decade the automation testing landscape has changed drastically. Selenium, dominant for 15 years, now faces serious competition from Cypress and Playwright — two modern frameworks promising faster execution, easier debugging, and a far better developer experience. For QA teams at Indonesian fintechs, banks, and e-commerce companies, this choice is not merely a technical preference. It is an architectural decision affecting team velocity, test coverage, and ultimately the quality of a product shipped to millions of users.
This article dissects all three frameworks in depth from the perspective of a practitioner who has implemented each across Indonesian industry contexts. We cover internal architecture, performance benchmarks, tooling ecosystems, and give concrete recommendations based on your team's situation.
Understanding the Architecture: Why It Matters
Before comparing features, it helps to understand how each framework works under the hood. Architecture determines everything — from execution speed to the kinds of bug you can catch.
Selenium WebDriver Architecture
Selenium uses a client-server architecture over the WebDriver protocol (a W3C standard). When a test script issues a command, it travels as an HTTP request to a WebDriver binary (chromedriver, geckodriver, and so on), which translates it into native browser instructions.
The implications of that architecture:
- Language agnostic: Because communication is over HTTP, Selenium supports Java, Python, C#, Ruby, JavaScript, and any other language that can issue an HTTP request
- Network overhead: Every command incurs an HTTP round trip, adding 10-50ms of latency per command
- Real browser control: WebDriver controls the browser exactly as a real user would — rendering, JavaScript execution, and network stack included
- Inherent flakiness: An out-of-process architecture means race conditions between the test script and browser state are a recurring problem
Selenium architecture is covered in depth in the Web Automation Fundamentals and Selenium WebDriver modules of our Web Automation Testing course, where participants study the WebDriver protocol internals to understand why flaky tests happen.
Cypress Architecture
Cypress takes a radically different approach. Rather than driving the browser from outside, Cypress runs inside the browser itself — in the same iframe as the application under test. It uses a Node.js server on the backend for tasks needing OS access (file system, network proxy, and so on).
The implications of an in-process architecture:
- Automatic waiting: Running inside the browser, Cypress observes DOM changes in real time without polling — reducing flaky tests significantly
- Native network interception: Cypress can intercept and mock requests at browser level with no external proxy
- JavaScript only: Tests can only be written in JavaScript/TypeScript
- Single browser tab: The architecture means Cypress cannot natively control multiple tabs or multiple browsers
- Same-origin limitation: Cypress struggles with scenarios involving cross-origin navigation
The Cypress Framework module covers how this architecture shapes test design strategy and when its limitations become a deal-breaker.
Playwright Architecture
Playwright, developed by Microsoft (by the same team that built Puppeteer at Google), uses the Chrome DevTools Protocol (CDP) plus custom protocols for Firefox and WebKit. That gives far more granular control than the WebDriver protocol.
The advantages of Playwright's architecture:
- Native multi-browser: Chromium, Firefox, and WebKit (the Safari engine) are supported first-class through bundled browser binaries
- Browser context isolation: It can run multiple isolated browser contexts within one browser instance — far more efficient than launching a new browser
- Built-in auto-wait: Like Cypress, Playwright waits intelligently, but without the single-origin limitation
- Multi-language: Supports JavaScript, TypeScript, Python, C#, and Java
- Tracing and debugging: The built-in trace viewer records screenshots, DOM snapshots, network logs, and console output for every step
A Detailed Technical Comparison
Execution Speed
Speed is critical for teams running thousands of test cases in a CI/CD pipeline. From a benchmark on an e-commerce application with 500 test cases:
- Playwright: ~8 minutes (with built-in parallelisation, 4 workers) — fastest
- Cypress: ~14 minutes (parallelisation requires Cypress Cloud or a plugin) — mid-range
- Selenium Grid: ~18 minutes (with 4 parallel nodes) — slowest
The difference comes from architectural overhead. Selenium needs an HTTP round trip per command, while Playwright and Cypress communicate over WebSocket or in-process calls that are far more efficient.
A scenario from the field: A QA team at a Jakarta fintech managing a digital payments application had 2,300 automated test cases in Selenium. Their CI/CD pipeline took 47 minutes to complete. After a partial migration to Playwright, starting with the critical test suite, that fell to 22 minutes for the same coverage — a 53% reduction. The impact was significant: developers stopped ignoring test results because the wait was too long.
Browser Support
Browser support requirements depend heavily on your users:
- Selenium: Chrome, Firefox, Edge, Safari, Opera, and any browser with a WebDriver implementation. The broadest coverage.
- Playwright: Chromium, Firefox, WebKit (the Safari engine). It bundles its own browser binaries, ensuring consistency.
- Cypress: Chrome, Chromium, Edge, Firefox, and Electron. No native Safari or WebKit support.
For the Indonesian market, where Chrome holds around 70% and Safari around 15% (concentrated in the premium segment), Playwright gives the best coverage thanks to WebKit support. If your application targets premium iPhone users (banking, wealth management), the absence of Safari testing in Cypress is a real risk.
Debugging and Developer Experience
This is where the modern frameworks genuinely outclass traditional Selenium:
Cypress has a Test Runner GUI letting you watch each step visually, time-travel debugging (click a step to see the DOM state at that moment), and automatic screenshots and video on failure. Cypress offers the best developer experience for test development and iterative debugging.
Playwright offers Trace Viewer — a tool recording a complete trace of each test run, including DOM snapshots, the network waterfall, console logs, and source code mapping. You can open a trace file and step through the test as though replaying it. Playwright also has a codegen tool that records browser interaction and generates test code automatically.
Selenium has no built-in debugging tool. You depend on an IDE debugger, manual screenshots, and log analysis. That is why Selenium test development and maintenance is significantly slower.
Handling Asynchronous Operations
A major source of flaky tests is handling asynchronous operations — API calls, animations, lazy loading, single page application routing.
- Selenium: Requires explicit or implicit waits configured manually.
WebDriverWaitwithExpectedConditionsis the standard pattern, but it demands significant boilerplate. - Cypress: Automatic retry on assertions. Cypress keeps retrying an assertion until timeout (4 seconds by default). Highly effective for SPAs. That said, hardcoded
cy.wait()is still frequently misused by junior developers. - Playwright: Auto-waiting on actionability checks (visible, enabled, stable). Playwright waits for an element to become actionable before clicking, filling, and so on, plus
expect().toBeVisible()with auto-retry on assertions.
CI/CD Integration: A Production-Ready Pipeline
The Framework Design & CI/CD module covers integrating each framework into a CI/CD pipeline in detail. A practical comparison:
Docker Support
Playwright provides an official Docker image (mcr.microsoft.com/playwright) with every browser dependency included. CI/CD setup is the most straightforward:
Cypress also provides official Docker images, but configuring headless mode and video recording needs extra attention to resource allocation (memory and CPU).
Selenium requires Selenium Grid (or Selenoid) for parallel execution in CI/CD. Setup is more complex but mature and well documented.
Parallel Execution
- Playwright: Parallel by default with a configurable worker count. Built-in sharding for distribution across CI nodes.
- Cypress: Parallel execution requires Cypress Cloud (paid) or a community plugin. This is often a bottleneck for smaller teams.
- Selenium: Parallel via Selenium Grid, TestNG (Java), or pytest-xdist (Python). Requires infrastructure setup.
Reporting
All three support a JUnit XML reporter compatible with mainstream CI/CD tools. Playwright has a highly informative built-in HTML reporter. Cypress Dashboard provides analytics and flaky test detection. Selenium is usually paired with Allure Report or ExtentReports.
An implementation scenario: A digital bank in Indonesia built a GitLab CI pipeline where every merge request triggers the Playwright test suite. They use sharding to split 1,800 tests across 6 parallel runners, with a total execution time of 12 minutes. Trace files from failed tests upload as CI artefacts so developers can debug without re-running. This pattern is covered in the Framework Design & CI/CD module with a hands-on lab.
When Should You Use Which?
Choose Selenium When:
- Your team works primarily in Java, C#, or Python and does not want to add JavaScript to the stack
- You need very broad cross-browser testing, including legacy browsers
- You already have a large existing Selenium test suite and migration cost is not justified
- The project needs mobile testing (Selenium plus Appium is the standard combination)
- The organisation has vendor lock-in concerns and wants a W3C standard
Choose Cypress When:
- Your application is a modern SPA (React, Vue, Angular) and developers write the tests
- You prioritise developer experience and fast iteration during test development
- Component testing is a primary need (Cypress has it built in)
- Your team is relatively small and wants a low learning curve
- Cross-browser testing is not a priority (most users are on Chrome/Chromium)
Choose Playwright When:
- You need cross-browser testing including WebKit/Safari
- CI/CD speed is a critical factor (built-in parallel execution and sharding)
- You handle complex scenarios: multi-tab, multi-user, iframes, popups
- Your team is mixed-language and wants programming language flexibility
- You are starting from scratch and want the most future-proof framework
- API testing and UI testing need to be integrated in one framework
A Migration Strategy from Selenium
Many Indonesian teams still run Selenium and are weighing migration. From experience helping several teams through the transition, here is the approach we recommend:
Phase 1: Parallel Running (Weeks 1-4)
- Pick the single module or feature that is tested most often
- Rewrite that module's test suite in the new framework
- Run both frameworks in parallel in CI/CD
- Compare: execution time, flaky rate, maintenance effort
Phase 2: Gradual Migration (Months 2-6)
- All new tests are written in the new framework
- Migrate old tests whenever the feature they cover changes
- Build shared utilities and page objects in the new framework
- Train the team progressively
Phase 3: Full Cutover (Months 6-12)
- Migrate the remaining test suite
- Decommission the Selenium infrastructure
- Optimise parallel execution and reporting
The Page Object Model & Best Practices module covers designing page objects that are framework-agnostic, which makes migration far easier. The separation of concerns between test logic and page interaction stays relevant across all three frameworks.
Real-World Implementation: An E-Commerce Checkout Flow
To make this concrete, here is how the same test looks in each framework. The scenario: a user adds a product to the cart and checks out.
In Selenium, you write an explicit wait for every element, manage WebDriverWait and ExpectedConditions, and manually confirm the page has loaded. Tests tend to be verbose — a checkout flow can run to 40-60 lines.
In Cypress, the code becomes more declarative. Automatic waiting removes the need for explicit waits. Command chaining makes the flow easy to read. But you need cy.intercept() to handle API calls and ensure data is available before asserting. The same checkout flow runs around 20-30 lines.
In Playwright, you get a balance of control and convenience. Auto-waiting as in Cypress, but with more robust handling of multiple pages and network conditions. The checkout flow runs around 25-35 lines with excellent readability.
The Workshop Project module uses real-world scenarios like this, where participants implement a complete test suite for a web application across all three frameworks hands-on.
Considerations for Indonesian QA Teams
Several factors are specific to the Indonesian context:
- Talent availability: Developers and QA engineers with Selenium skills remain the most plentiful in the Indonesian job market. The Cypress and Playwright talent pool is growing quickly but is still smaller.
- CI/CD infrastructure: Many Indonesian companies still run on-premise CI/CD. Playwright and Cypress need fewer resources than Selenium Grid, an advantage where infrastructure is constrained.
- OJK and Bank Indonesia regulation: For banking and fintech, automated testing is not merely best practice but part of technology risk management requirements. Frameworks producing evidence (screenshots, traces, video) help satisfy audit requirements.
- Network conditions: Applications accessed from across Indonesia face varying network conditions. Playwright has built-in network throttling, useful for testing under poor connectivity.
What the Course Covers
The Web Automation Testing: Selenium & Cypress course is designed to build practical capability across all three frameworks, not merely a theoretical comparison. The module map:
- Web Automation Fundamentals: Browser architecture, DOM interaction, WebDriver protocol versus CDP, and waiting strategy concepts. Foundations that apply to every framework.
- Selenium WebDriver: Environment setup, locator strategies, WebDriverWait, handling dynamic elements, multi-browser execution, and Selenium Grid configuration.
- Cypress Framework: Cypress architecture, command chaining, custom commands, intercept and stub, component testing, and configuration best practice.
- Page Object Model & Best Practices: A framework-agnostic design pattern, separation of concerns, data-driven testing, and test data management.
- Framework Design & CI/CD: Custom framework architecture, Docker containerisation, GitHub Actions/GitLab CI integration, parallel execution, and reporting and artefact management.
- Workshop Project: End-to-end implementation — participants build a complete test suite for a web application in both Selenium and Cypress, then compare the results directly.
Related Courses for Building QA Capability
- API Testing: Postman & REST Assured — Complement UI testing with API testing for comprehensive coverage
- SDET & Test Automation Engineering — The career path for QAs moving toward Software Development Engineer in Test
- Performance & Load Testing: JMeter — Performance testing that complements functional testing
- Mobile Application Testing — Extending automation to mobile platforms with Appium
FAQ: Selenium vs Cypress vs Playwright
Is Selenium obsolete and should it be abandoned?
No. Selenium remains the most mature automation testing framework with the largest ecosystem. Selenium 4 brought significant improvements including native CDP support and an improved WebDriver protocol. What has changed is that Selenium is no longer the only viable choice. For new projects, Playwright or Cypress are often more efficient, but Selenium remains solid for teams with a large existing investment in it.
Which framework is easiest for a QA beginner to learn?
Cypress has the lowest learning curve, thanks to an intuitive API, excellent documentation, and a Test Runner GUI that makes debugging straightforward. Playwright comes second with a clean API and good tooling. Selenium has the steepest curve, requiring an understanding of the WebDriver protocol, explicit waiting, and more complex setup. That said, understanding Selenium gives you a strong foundation for the others.
Playwright or Cypress for a new project in 2026?
For new projects, Playwright is increasingly the default: broader cross-browser support (WebKit included), built-in parallel execution at no extra cost, multi-language support, and better handling of complex scenarios. Cypress still leads on developer experience and component testing. If your team is 100% JavaScript and focused on SPA testing, Cypress remains excellent. If you need flexibility and scalability, Playwright is more future-proof.
How long does migrating from Selenium to Playwright take?
From experience helping Indonesian QA teams, a gradual migration typically takes 6-12 months depending on suite size. A team with 500 test cases can usually complete in 4-6 months using the parallel running approach. The key to success is not rewriting tests but redesigning the test architecture — page objects, utilities, and the CI/CD pipeline. Migrating without redesign simply moves the problem into a new framework.
Can one framework handle both UI and API testing?
Yes, both Playwright and Cypress support API testing. Playwright has a request context allowing API calls without a browser, very useful for test setup and teardown. Cypress has cy.request() for the same purpose. For comprehensive API testing, though, we still recommend a dedicated tool of the kind covered in the API Testing: Postman & REST Assured course — particularly for contract testing and performance testing at the API layer.