Skip to main content

Technical assurance

Playwright test automation for browser-based software

We build maintainable Playwright E2E tests for critical user paths in web applications of any kind and connect the project to your CI/CD. That covers building a suite from scratch as well as extending an existing one, so regressions surface earlier.

Playwright E2E CI/CD integration TypeScript Stage/QA/UAT Portals & web apps
Request a technical intro call FAQ on technical assurance

Is This Right for Your Team?

Browser automation with code - symbol for technical assurance of important web flows © Velvionix

Need the quality process first?

If it is still unclear which user paths should be automated, or which workflows actually matter, QA consulting is the better first step. It structures and prioritizes the test basis before a Playwright project starts.

Good Fit If

  • + You operate browser-based software and want to reliably secure releases
  • + A stage/QA/UAT environment with stable test accounts and test data is available
  • + Your team can provide robust locators (roles, labels, or data-testid or equivalent)

Not a Fit If

  • - You want to run automated checks permanently against production
  • - Test data is not controllable or the environment is regularly unstable
  • - WAF/rate limits/anti-bot block test executions and cannot be adjusted

Modular Implementation with Clear Acceptance

We deliver in modules. Everything outside the agreed module sheet is offered transparently as a change request before we implement.

M1 Access and Feasibility

We check the test environment, repository access, test accounts, test data, selectors and technical dependencies. This establishes which flows can be automated reliably before a larger commission.

Before a larger commission

  • Test environment, repository access and technical dependencies
  • Test accounts, test data and selectors
  • A clear view of which flows can be automated reliably

M2 Representative Pilot Flows

A small selection of typical flows is implemented as a technical pilot. This validates the architecture, access and interaction with the application under real project conditions.

Technical pilot

  • A small selection of typical flows
  • Architecture and access under review
  • Interaction with the application under real project conditions

M3 Agreed Scope

Critical user flows, priorities, browsers and viewports, test data strategy and acceptance criteria are agreed together and documented clearly in the proposal.

Agreed together

  • Critical user flows and priorities
  • Browsers, viewports and test data strategy
  • Acceptance criteria, documented clearly in the proposal

M4 Architecture and Implementation

We develop the agreed Playwright flows with stable assertions, a maintainable TypeScript structure, clear documentation and the appropriate desktop or mobile viewports.

What is delivered

  • Agreed Playwright flows with stable assertions
  • A maintainable TypeScript structure
  • Clear documentation and the appropriate viewports

M5 CI and Reporting

The automated checks are integrated into the existing CI as agreed. Reports, traces and screenshots make results and causes of failures easier to understand.

Visible results

  • Integration into the existing CI as agreed
  • Reports, traces and screenshots
  • Results and causes of failures that are easier to understand

M6 Handover and Support

In a remote session, we explain the project structure, local and automated execution, and troubleshooting basics. Further maintenance can be agreed separately.

Remote session

  • Project structure, local and automated execution
  • Troubleshooting basics
  • Further maintenance only if agreed separately

Scope Rules

  • • Default scope: exclusively the client's webapp via the web interface.
  • • Automated checks are implemented as focused flows - no monolithic flows that cover multiple areas in a single test and create long run times.
  • • External systems (payment, SSO, email) only if explicitly commissioned as add-on module and realistically automatable with sandbox/test access.
  • • No real mobile devices or emulators - mobile only via Playwright viewports.
  • • Production is excluded by default.

Prerequisites for Stable Tests

  • • Working stage/QA/UAT access, test accounts and test data must be available.
  • • Test data must be reliably provided or reset (reset mechanism).
  • • WAF/rate limits/anti-bot must not block automation. If necessary: whitelisting or identification mechanism.
  • • Robust locators are a prerequisite. Roles, labels and other stable attributes are preferred; for elements that are hard to address uniquely, test IDs such as data-testid can be agreed. Without a reliable locator strategy we pause and request improvement.

CI/CD and Reporting

Standard is the Playwright HTML report. Reports, traces and screenshots are provided in your existing CI. GitHub Actions is a common example; other CI systems are possible. Additional reporting integrations (e.g. JUnit, Allure, test management) only by separate commission.

Acceptance and Quality Criteria

  • Acceptance is per module (agreed test scope), not per test case.
  • For demonstrably incorrect or incomplete tests, there are two correction loops per module.
  • Flaky sources are cleanly documented and attributed (test issue vs. environment/test data/rate limits).

Billing and Commissioning

We do not automate the entire web application in one go. In the first call we agree a first sensible scope that can be delivered in one manageable step.

We implement that part and present it for acceptance. After acceptance we invoice that step. Only then does the next agreed part begin.

How we split the work into milestones is decided together. What matters are the critical paths, the technical starting point and which next step helps most.

Optional: Maintenance Contract for Updates and CI

  • Monthly updates of Playwright and dependencies (incl. required adjustments to restore functionality within agreed scope).
  • Maintenance and adjustment of CI workflows within the agreed scope, for example jobs, reports and artifacts. GitHub Actions is a familiar example; the integration follows your existing CI. Support for secrets rotation and required checks if access is available. Infrastructure, VPN access and setup or operation of self-hosted runners are not included and are provided by the customer's DevOps team.
  • Response time for critical CI or test failures (jointly classified as critical): analysis and feedback with plan within 48 hours on business days.

Frequently asked questions about E2E test automation

What is technical assurance with Playwright?

We develop automated checks for browser-based software, portals and web applications via the user interface and integrate them into your CI/CD. The goal is release security: critical flows are checked automatically on a regular basis, instead of being manually retested with every update.

Are tests run in the production system?

By default, no. Automation runs against stage/QA/UAT. Production is excluded unless explicitly agreed in writing.

What is needed for tests to run stably?

Working stage access, stable test accounts, and reliable test data that can be provided or reset reliably (reset mechanism). Additionally, WAF/rate limits/anti-bot must be configured so automation is not blocked.

Are special test selectors required?

Robust locators are a prerequisite. Roles, labels and other user-facing attributes are preferred; data-testid or an equivalent test ID can be agreed when those are not enough. Without a reliable locator strategy we pause and request improvement.

What's included in the standard scope?

Automated checks of the web application under test via the browser user interface. External systems (e.g. payment, SSO, email) are only included as separately commissioned add-on modules and exclusively with sandbox or test access.

Is mobile testing supported?

Browsers and viewports are agreed according to the critical user flows and documented in the proposal. The scope can use agreed desktop or mobile Playwright viewports; real devices and emulators are not included.

How is billing handled?

We do not automate the entire web application in one go. In the first call we agree a first sensible scope that can be delivered in one manageable step. We implement that part and present it for acceptance. After acceptance we invoice that step. Only then does the next agreed part begin. How we split the work into milestones is decided together. What matters are the critical paths, the technical starting point and which next step helps most.

How does the initial call for technical assurance work?

In the technical initial call, the objectives, critical user flows (priority 1) and the technical baseline are clarified. This includes in particular stage/QA/UAT, stable test accounts, reliable test data, a reset mechanism and WAF/rate limits. Subsequently, an initial module (test scope) is defined and a transparent offer including acceptance criteria and timeline is created.

Technical Initial Call

We check scope, stage, selectors and CI prerequisites and suggest a sensible first step.

Request a technical intro call