Playwright E2E in action
How Playwright later controls mouse, keyboard and browser.
Control the robot for a moment: every movement follows a clear instruction. In the same way, Playwright later runs programmed E2E scenarios in the browser from the user's perspective - with clicks, keyboard input and automated checks.
Move your mouse across the robot. In a real project, Playwright takes over these repeatable browser flows automatically, so developers do not have to retest the same paths manually after every update. Touch the robot. In a real project, Playwright takes over repeatable browser flows automatically, so regressions after updates do not have to be checked manually every time.
We work remotely with companies in Germany, Austria and Switzerland. We also take on English-language projects for companies in other European Union countries. The focus is on Playwright test automation for websites, portals and web applications (Node.js/TypeScript).
Before a larger implementation, we validate access, the test environment and representative flows in a technical pilot. Once feasibility is established, we agree the wider test scope together.
- Stage/QA/UAT as standard, production only by explicit written agreement
- Stability through deterministic selectors (data-testid) instead of fragile XPath/CSS
- Maintainable architecture (TypeScript, Page Object Model) plus documentation, handover and training
© Velvionix Is This Right for Your Team?
Good Fit If
- +You operate large websites, portals or web applications and want to reliably secure releases
- +A stage/QA/UAT environment with stable test accounts and test data is available
- +Your team can provide stable selectors (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.
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.
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.
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.
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.
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.
Optional: UI/UX Analysis as a Separate Commission
If required, we can also review usability, user guidance and visible friction points in the web application. Findings are documented in a separate report with prioritized observations. Scope, objectives and fees are agreed independently from the test automation work.
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.
- • Stable selectors (data-testid) are mandatory. Without these, we pause and request improvement.
CI/CD and Reporting
Standard is the Playwright HTML report. In GitHub Actions, the report is provided as artifact. 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
Compensation is modular based on a module sheet, exclusive of VAT. VAT may apply depending on the client's location and tax status. Each module is described before implementation with scope, acceptance criteria and a fixed price. After completion, the module is made available for acceptance. After acceptance, we issue the invoice for the completed module. Work on further modules begins only after the previous invoice has been paid, unless otherwise agreed in writing. Change requests are offered transparently before implementation and only carried out after approval, including scope description, effort/price and effects.
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 (GitHub Actions) within agreed scope, e.g. workflow and job adjustments, reports/artifacts and 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.
Technical Initial Call
We check scope, stage, selectors and CI prerequisites and suggest a sensible module package.
Request a technical intro call