One test framework for seven PostNL teams

Seven teams, seven ways of testing

PostNL is the national postal and parcel service of the Netherlands. Behind its consumer platform sit multiple development teams, each shipping software that millions of customers depend on for tracking, delivery and notifications.

When spriteCloud's SDET lead joined the consumer platform teams, every team tested differently. One used Cypress, another SpecFlow with C#, others ran legacy tools nobody else in the building recognised. A problem solved in one team stayed solved in one team. Knowledge didn't travel.

Standardise testing without standardising teams

PostNL wanted seven teams working the same way: shared tooling, shared solutions, and a setup new testers could learn fast. The constraint made it hard. Each team needed its own pipeline and its own way of testing, while still conforming to a standard. Some teams had mature automation. Others had none at all, run by manual testers without programming experience.

Any framework that interfered with how a team worked would be rejected. Any framework that required every team to manage its own dependencies would rot. The design brief wrote itself: make teams write tests, and nothing else.

A framework split into cores

The answer was a modular framework in Java with Maven and Cucumber, chosen for its track record and for how quickly junior testers can be trained on it. The framework splits into independent cores.

A parent POM holds every dependency: Selenium, Appium, RestAssured, logging, reporting. Teams add one dependency and Renovate keeps everything updated automatically. Outdated-dependency warnings and the security risks that come with them disappeared from team pipelines overnight.

A web core and a mobile core wrap all browser and device handling, including a BrowserStack profile for switching between local and cloud runs. Teams write tests in plain Gherkin and never touch the Selenium or Appium plumbing underneath.

A utility core collects shared helpers: barcode generators, OTP handling, JSON mappers, video recorders. When a tester in one team builds something useful, it moves into the utility core and every other team gets it in the next version, with a changelog.

Teams subscribe only to what they need. A web-only team deletes the mobile core and its setup class, and the framework keeps working.

Wired into the pipelines teams already had

A framework that lives outside the delivery pipeline gets ignored. spriteCloud and PostNL's DevOps engineers wrote the GitLab CI configuration together, so the framework runs as a build step in each team's existing pipeline. Maven profiles switch browsers, users and environments straight from the pipeline.

SonarQube and Datadog were integrated into the same setup, giving teams code quality checks and monitoring alongside their test runs without extra configuration work.

Adoption was the hard part

Replacing familiar tools with an unfamiliar language met real resistance, and adoption was slow. The framework won teams over by removing the work they disliked: no dependency management, no boilerplate, no framework maintenance. Just tests.

The effect compounded. Manual testers asked for programming training because they saw what the framework did for neighbouring teams. Teams that had zero automation started building their first regression packs. A contract testing core (Swagger and RestAssured) and a performance testing core (JMeter) are next, installed the same way as the others.

Hours of clicking became half an hour of waiting

• Regression: 10 to 30 minutes, down from hours of manual testing per release.
• One framework across seven teams, each with its own pipeline and test artifacts.
• Zero dependency management for teams: Renovate updates everything centrally.
• Teams with no automation now build and run their own regression packs.
• Faster, cheaper releases as automated regression replaced manual cycles.