Deze documentatie wordt actief uitgebreid — kom regelmatig terug.

ADR-00017: Test Automation Using Playwright with TypeScript

Approval Status

Status flow: Proposed → Accepted → Reviewed → Approved (or Rejected), or Not Required. A superseded ADR keeps its file; only its status changes to Superseded by NNNNN.

Governance body	Status	Last update
CTN Project Team	Proposed	2026-06-22
CTN Technical Advisory Board	Pending	—
CTN Steering Committee	Pending	—
BDI Conformance Team	Pending	—
BDI Framework Team	Pending	—

RdN Question: this seems to overlap with 00015

Relationship to other test ADRs. This ADR defines the strategic UI-automation framework for the production portal (Playwright + TypeScript, TAaaS-owned, layered Page Object / Service / Utility architecture). It is complementary to — not a duplicate of — ADR-00015, which covers the tactical, in-repo Java e2e tier bound to the backend’s Maven build for the throwaway demo frontend. The two use different toolchains on purpose because they test different surfaces; the overall test strategy in ADR-00023 sets out the full picture, layer ownership, and the fact that convergence of the two toolchains is a deferred, future decision.

Context and Problem Statement

The project requires a reliable, maintainable, scalable, and reusable testing approach to support quality assurance activities across the application lifecycle.

Testing will initially be performed manually to validate functionality, understand business workflows, and identify stable, repeatable test scenarios. As the application matures, selected test cases will be prioritized for automation using Playwright with TypeScript. Priority will be given to smoke tests, critical business workflows, regression scenarios, and tests that provide the highest return on investment through repeated execution.

This phased approach allows the team to establish confidence in the application while building a sustainable and maintainable automation suite.

The selected solution must:

Support modern web application testing.
Enable cross-browser testing.
Integrate with CI/CD pipelines.
Provide reliable and maintainable automated tests.
Support collaboration between developers and testers.
Generate meaningful test execution reports and diagnostics.
Align with the organisation’s quality engineering strategy.

In addition, the solution must support the implementation of automation engineering standards, including:

SOLID design principles.
DRY (Don’t Repeat Yourself).
Separation of concerns.
Reusable automation components.
Consistent coding standards.
Scalable framework architecture.
Automated quality gates and continuous integration practices.

The solution must enable the creation of a sustainable automation framework that can evolve alongside the application while minimising technical debt and long-term maintenance effort.

Considered Options

Option 1: Playwright with TypeScript

Description: A modern automation framework supporting Chromium, Firefox, and WebKit browsers. Combined with TypeScript, Playwright enables the development of maintainable, scalable, and reusable automation solutions through strong typing, modern language features, structured framework design, and robust test execution capabilities. The Test Automation as a Service (TAaaS) team has extensive knowledge and practical experience with Playwright and TypeScript, reducing implementation risk and enabling the rapid establishment of a maintainable automation framework.
Pros:
- Supports Chromium, Firefox, and WebKit.
- Fast execution through parallelisation.
- Built-in waiting mechanisms and reliability features.
- Native TypeScript support.
- Strong support for maintainable framework design.
- Enables implementation of SOLID and DRY principles.
- Supports reusable Page Object and Component Object patterns.
- Facilitates separation of concerns through layered architecture.
- Integrated screenshots, video recording, and trace viewer.
- Strong CI/CD integration.
- API testing capabilities.
- Open-source and actively maintained.
- Improved maintainability through type safety and compile-time validation.
Cons:
- Initial framework implementation effort is still required.
- Team discipline is needed to maintain framework standards and architecture consistency.
- Ongoing maintenance is required as the application and tests evolve.

Option 2: Cypress with TypeScript

Description: A popular end-to-end testing framework focused on modern web applications. Cypress provides a strong developer experience and supports TypeScript-based automation development. While effective for many web testing scenarios, its limitations around browser support and enterprise-scale automation architecture make it less suitable for the long-term objectives of this project.
Pros:
- Easy setup and onboarding.
- Strong developer experience and interactive test runner.
- Native TypeScript support.
- Automatic waiting and retry mechanisms.
- Good debugging capabilities.
- Large community and ecosystem.
- Strong CI/CD integration.
- Extensive documentation and learning resources.
Cons:
- Does not support WebKit, limiting full cross-browser validation.
- Limited support for multi-tab and multi-window testing scenarios.
- Less comprehensive API testing capabilities than Playwright.
- Some advanced execution, reporting, and parallelisation features require commercial services.
- Less flexibility for implementing complex enterprise automation architectures.
- Reduced suitability for long-term framework scalability and reuse.
- Lower alignment with the organisation’s strategic requirement for broad browser coverage and maintainable automation frameworks.

Option 3: Selenium WebDriver with Java

Description: A mature and widely adopted automation framework supporting multiple browsers and programming languages. While Selenium remains a recognised industry standard, it requires significantly more framework engineering effort to achieve the same capabilities that are available natively in Playwright.
Pros:
- Mature and widely adopted technology.
- Extensive browser support.
- Large community and ecosystem.
- Broad integration capabilities.
- Strong enterprise adoption.
Cons:
- Higher framework implementation complexity.
- Increased maintenance overhead.
- More code required to implement reliable synchronisation and waiting strategies.
- Slower development lifecycle compared to modern automation frameworks.
- Additional tooling required for reporting, tracing, screenshots, and diagnostics.
- Higher long-term cost of ownership due to framework maintenance.
- Greater risk of inconsistent implementation across teams.
- Longer onboarding time for automation engineers.
- Increased effort to enforce modern automation engineering standards and reusable framework patterns.

Decision Outcome

Chosen option: Option 1 - Playwright with TypeScript.

Playwright with TypeScript is selected as the strategic automation solution due to its strong support for modern web application testing, maintainable framework design, cross-browser compatibility, CI/CD integration capabilities, and alignment with the organisation’s quality engineering and software development standards.

Rationale

Business alignment:
- Supports faster release cycles through automated validation.
- Reduces regression effort and associated testing costs.
- Improves overall software quality and release confidence.
- Enables consistent testing standards across teams.
- Provides a scalable foundation for long-term automation growth.
Technical considerations:
- Native support for Chromium, Firefox, and WebKit browsers.
- Strong TypeScript ecosystem and developer tooling.
- Built-in reporting, screenshots, video recording, and trace capabilities.
- Supports parallel execution for rapid feedback.
- Integrates seamlessly with Azure DevOps and GitHub Actions.
- Supports both UI and API testing requirements.
- Supports the implementation of a layered automation architecture.
- Enables separation of concerns through dedicated test, page, component, service, and utility layers.
- Supports reusable framework components that reduce duplication and improve maintainability.
- Facilitates adherence to SOLID principles through modular design.
- Supports DRY principles through shared abstractions, fixtures, services, and utilities.
- TypeScript compile-time validation reduces implementation defects and improves code quality.
- Aligns with enterprise automation engineering practices and long-term framework scalability.
Risk assessment:
- Low technology risk due to active community support and industry adoption.
- Reduced production risk through increased automated regression coverage.
- Framework risks are mitigated through established coding standards, peer reviews, architectural governance, and adherence to SOLID and DRY principles.
- Technical debt risks are reduced through reusable framework components and consistent automation design patterns.
Cost/benefit analysis:
- Costs:
  - Initial framework implementation effort.
  - Ongoing maintenance of automation assets.
  - Continuous enhancement of automation coverage and framework capabilities.
- Benefits:
  - Reduced regression testing effort.
  - Faster feedback during development.
  - Improved defect detection.
  - Better release confidence.
  - Lower long-term testing costs.
  - Improved framework maintainability and scalability.
  - Reduced technical debt through reusable automation components.
  - Consistent automation implementation across teams.

Consequences

Positive:
- Faster feedback on application quality.
- Improved regression coverage.
- Increased confidence in cross-browser compatibility.
- Reduced manual testing effort.
- Strong debugging support through traces, screenshots, and videos.
- Improved maintainability through TypeScript.
- Improved framework maintainability and scalability.
- Reduced technical debt through reusable automation components.
- Consistent automation implementation across teams.
- Improved code quality through engineering standards and automated quality controls.
- Greater long-term sustainability of automation assets.
Negative:
- Initial investment is required to establish the framework and supporting standards.
- Automation assets require continuous maintenance as the application evolves.
- Teams must consistently follow agreed architectural and coding standards to preserve maintainability.
Neutral:
- Existing exploratory testing practices remain unchanged.
- Test management processes remain independent of the automation framework.

Implementation Plan

Phase 1: Framework Establishment
- Create the Playwright TypeScript framework repository.
- Establish the automation framework architecture.
- Implement a layered framework structure consisting of:
  - Test layer
  - Page object layer
  - Component layer
  - Service layer
  - Utility layer
- Define coding standards and engineering principles.
- Establish SOLID and DRY implementation guidelines.
- Configure ESLint and Prettier standards.
- Integrate reporting capabilities.
- Configure CI/CD pipeline execution.
- Establish framework documentation.
Phase 2: Automation Rollout
- Execute manual functional and regression testing.
- Identify repeatable and high-value test cases suitable for automation.
- Prioritise critical business workflows for automation.
- Implement smoke test automation.
- Introduce regression test coverage incrementally.
- Implement API test automation where applicable.
Phase 3: Optimisation and Scaling
- Expand regression coverage.
- Optimise execution performance.
- Implement test data management strategy.
- Introduce quality gates and release criteria.
- Monitor framework effectiveness and maintenance metrics.
- Continuously improve framework architecture and reusable components.