This is a guest post from Ambassador Frits Van Der Sloot
Hi, I'm Frits. I’ve been in software testing for over 10 years and became a Cypress Ambassador in February 2025. I’m passionate about making complex things simple and helping teams build better, faster tests. I’ve worked on everything from testing 2,000 websites with one codebase to coaching manual testers into automation pros. I enjoy refactoring legacy tests, scaling testing teams, and integrating Cypress into CI/CD workflows. My focus areas include Cypress, TypeScript, JavaScript, automation, and team coaching.
You can find me sharing more thoughts on testing, automation, and scaling quality on LinkedIn or at a future Cypress community event.
The Netherlands Enterprise Agency — called Rijksdienst voor Ondernemend Nederland in Dutch, or RVO in short — plays a central role in helping Dutch businesses and public organizations in areas such as innovation, sustainability, and international collaboration. Like many large public-sector institutions, RVO historically approached software testing in a fragmented, informal way.
Until early 2024, testing was not a formally recognized discipline. Application managers and business analysts were often responsible for functional verification, though this occurred without standardization or long-term vision. A bevy of software testing consultants were hired through their teams in a first effort to bring expertise to the RVO.
That changed in January 2024, when RVO officially committed to embedding quality assurance into its software development process. Cypress was a key driver of the transformation.
Where It All Started
In June 2023, I joined RVO’s national division (UPNL) as part of a platform team. My task was to help automate testing processes across a variety of projects.
What I found was a common story:
- Most teams were using Cypress, but with heavy reliance on outdated automation patterns — many of them inherited from Selenium;
- Projects had forked versions of the same core codebase;
- Teams had built deep, class-based Page Object Models (POMs), adding multiple layers of abstraction around basic test actions;
- Something as simple as calling an API often involved four or five layers of abstraction, making it nigh-on impossible to read, debug, and maintain tests.
At the same time, fellow Cypress Ambassador Paul de Witt was brought in to support the European branch (UPEU) of RVO. Unlike UPNL, this part of the organization had almost no test automation in place, giving him the opportunity to start fresh.
Language-first Strategy
In January 2024, RVO officially recognized testing as a separate discipline. A team manager was appointed to lead this new discipline. One of his first actions was to ask Paul and me to help define the foundation for a test architecture that could scale within our respective departments and even across departments.
We introduced what we called a language-first testing strategy. Instead of prescribing specific tools, we encouraged teams to align on TypeScript as the shared language for all testing efforts. This meant that regardless of the tool — whether it was Cypress, or another tool — the testing code would be written in a unified, strongly-typed, and maintainable way.
To put this strategy into motion, we hosted a joint session for all testers, scrum masters, and product owners in both divisions. This was the official launch of the Unified Test Strategy. We used this moment to promote modern Cypress practices, simplify abstractions, and shift from framework-heavy approaches to test code that was readable, idiomatic, and built for humans.
Simplifying Cypress Use
The Cypress code we encountered in many legacy projects was often bloated and wrapped in layers of Page Objects.
One example involved a class-based API wrapper where calling a simple GET request meant traversing through five layers of abstract builders, base classes, and chained setup methods.
A more maintainable and idiomatic approach for API calls looks something like this, using a single Cypress command and referencing an environmental variable when needed:
cy.contcy.request({
method: 'GET',
url: `/api/users/123`,
headers: {
Authorization: `Bearer ${Cypress.env('token')}`,
},
}).then((response) => {
expect(response.status).to.eq(200);
});
Another example included a one-liner Cypress code wrapped in a custom command:
Cypress.Commands.add(‘clickButton’, (label) => {
cy.get(‘button’).contains(label).click();
})
Rather than wrapping one-liner Cypress code inside custom commands, we moved the refactored code of these commands directly to the spec files that were using the custom commands.By moving the code directly to the spec files, we reduced the complexity of the supporting files and enabled testers to directly read how test automation interacted with the application from the spec files.
We also encouraged teams to remove unnecessary complexity and focus on clarity and intention. Common abstractions, like authentication flows or state setup, were moved into shared Cypress custom commands, published via private npm packages, reducing duplicate code and allowing teams to reuse and share useful code snippets. Moreover, by publishing via private npm packages, rather than public packages, we ensured code never left the premises of the RVO, a requirement from a security perspective.
Aside from this, we focused on programming fundamentals – establishing peer reviews, introducing branching strategies and agreeing on overarching naming conventions. Introducing these fundamentals allowed testers to cooperate across teams and even domains.
Tailored for Two Architectures
Paul and I worked within different divisions with different architectures.
The European branch had a centralized infrastructure, making it possible to create a project template in GitLab with Cypress and all required dependencies preconfigured. A helper monorepo was also developed, containing reusable test state, data builders, and utility commands that could be used across all new projects.
The national branch, by contrast, had a more fragmented containerized environment. We created several private npm packages and GitLab pipeline templates to enable consistent, scalable automation in this setting. These packages included shared test configuration, custom commands, state builders, and reporting tools.
The common thread between both approaches was Cypress and TypeScript — supported by tooling that enabled reuse, but did not enforce rigidity.
Growing Internal Capacity
When we started, about 75% of the testers at RVO were external consultants. This level of external hiring was not sustainable as no knowledge regarding quality assurance processes was embedded in the organization. Moreover, this facet of the RVO did not adhere to the Roemer-norm, a Dutch government directive that states that no more than 10% of total personnel expenditures should be spent on hiring external personnel.
Our strategy and tooling allowed RVO to begin hiring testers who were eager to work with TypeScript, Cypress, and a clearly defined way of working. Instead of inheriting chaos, new hires received documentation, structure, and support from test guilds and platform teams.
Consultants were phased out gradually and respectfully and replaced with internal hires, who all had at least a year of experience with JavaScript or TypeScript and at least one modern test tool. New hires were further trained and guided with a multiple-week onboarding program as well as workshops on topics like Cypress Best Practices. Transitions typically included a 2–3 month overlap period to ensure smooth handovers between the consultants and the new hires. By the end of 2024, about half a year into the strategy, RVO had reversed its ratio to 75% internal staff and 25% external — ensuring long-term internal ownership of quality processes, setting a significant step toward aligning with the Roemer-norm and saving the Dutch taxpayer upwards of a million euro a year in consultancy fees alone.
Maturing Beyond Tools
A unified testing approach is more than just writing test automation scripts in a unified manner. From job descriptions and career paths to setting up analytics or defining test processes: a lot of ground still needs to be covered.
With Cypress and the language-first approach well embedded, RVO kicked off 2025 by using the TMMi (Test Maturity Model integration) framework to assess where the organization stands in terms of test process maturity. After assessing the situation, many initiatives are to follow to further improve their test maturity.
To ensure that test maturity and quality assurance as a whole remains a long-term focus, both divisions now have dedicated test leads.
With strong leadership in place, Paul and I have begun transitioning duties and responsibilities to the leads and other testers in the organization, so we can both move on to help other organizations later on in the year.
Final Thoughts
Cypress was the right tool at the right time — not just because of its power or popularity, but because it aligned with our philosophy: keep things simple, focus on clarity and empower testers to work effectively across teams.
By adopting a language-first strategy with Cypress, we were able to:
- Eliminate unnecessary complexity;
- Unify testing across legacy and greenfield systems;
- Reduce consultant dependency;
- Build a culture where quality is everyone's responsibility.
Cypress didn’t just help us write tests — it helped modernize the way RVO thinks about testing altogether.