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.
Digital collaboration across Germany, also for German- and English-speaking software teams outside Germany. Focus on Playwright test automation for websites, portals and web applications (Node.js/TypeScript).
Already have automated tests? We start from scratch with clean architecture and best practices - for maintainable, stable tests that grow with your application.
- 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 Analysis and Scope Workshop
Critical flows, prioritization, browser/viewport matrix, test data strategy, reset mechanism. Result: clear Prio-1 test list and implementation plan.
M2 Framework Setup
Project structure, conventions, Page Object Model, documentation, local execution. TypeScript as standard.
M3 Initial Package: 10 Prio-1 Checks
Stable assertions, traceable scope, Playwright HTML report. Desktop, Chromium as base.
M3a Add-on Module: Tablet/Mobile Viewports
Extension to additional viewports (significantly higher effort due to UI variants).
M4 CI Pipeline (GitHub Actions)
Automatic execution in client repo, report as artifact, traces/screenshots by agreement.
M5 Handover and Training
Remote session: project structure, local/CI execution, troubleshooting basics.
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, net plus VAT. 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