FAQ

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.

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

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.

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.

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.

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.

In the client's repository, in the existing CI. GitHub Actions is a common example; other CI systems are possible. Execution runs automatically in the client's repo, and the report is provided as an artifact. As part of an optional maintenance contract, we additionally support secrets rotation on request if access is granted.

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 integrations (e.g. JUnit, Allure, test management) only by commission.

"Flaky" means: a test randomly switches between pass and fail even though the system is unchanged. The cause is cleanly documented and attributed: a test issue, or environment/test data/rate limits/WAF.

Any browser-based software, for example SaaS, online shops, portals, admin interfaces, ERP/SAP web interfaces, CRM systems, inventory tools or internal business applications.

No. QA consulting is not an outsourced manual testing department. The goal is to improve test coverage, prioritization, QA processes and testability so quality can be managed systematically.

When it is not yet clear which workflows are truly critical, which tests are required or which scenarios are suitable for automation. In that case, the test basis should be structured and prioritized first.

Yes. Within the agreed scope, usability reviews and accessibility checks can also be included. Usability findings are recorded as prioritized observations. Accessibility can cover keyboard operation, focus behaviour, semantic structure and screen-reader usage.

The free virtual initial call is used to understand the product, current needs and desired work package. Velvionix can then provide a clearly scoped proposal with deliverables, acceptance criteria and price.

Effort depends heavily on application complexity, onboarding, documentation, test access, existing processes and the desired outcome. A reliable price is only possible once the specific work package is understood.

Yes. QA consulting and Playwright test automation can be commissioned separately. If the relevant journeys and technical prerequisites are already clear, automation can start directly.

Yes. If further support is useful, the next area is agreed separately. This allows a long-term collaboration to develop without creating an unlimited engagement.

No. Meetings, workshops, analysis and technical delivery take place fully remotely.

Acceptance is carried out modularly according to the agreed check scope. For demonstrably incorrect or incomplete checks, two correction loops per module are included. Automated checks are implemented as focused flows - no monolithic flows that cover multiple areas in a single test and create long run times.

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.

Yes - optional but clearly recommended. Depending on the agreement, maintenance includes monthly Playwright and dependency updates (including required adjustments to restore functionality within the agreed scope), maintenance and adjustment of CI workflows (for example job adjustments, reports and artifacts, support for secrets rotation and required checks if access is available), and a response within 48 hours on business days for analysis and feedback with a plan for jointly classified critical CI or test failures. Infrastructure, VPN access and setup or operation of self-hosted runners are not included and are provided by the customer's DevOps team. New test cases or new areas must be commissioned separately.

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.

Implementation is structured in modules: 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. Everything outside the agreed module sheet is offered transparently as a change request before implementation.