QA Stages in Release Pipeline at Dashlane

Introduction

In the world of modern software development, the "move fast and break things" mantra has largely been replaced by "move fast and fix things before they ship." At ParisTestConf, I shared insights into how we at Dashlane re-engineered our QA stages to maintain high security and reliability while scaling our delivery pipeline.

For engineering teams struggling with slow releases or flaky builds, our journey offers a blueprint for maturity. It details the move from manual bottlenecks to a seamless and automated Continuous Delivery (CD) model.

The Challenge: Scaling Quality with Speed

As we grew, manual testing became a significant bottleneck. The solution was not just "hiring more testers" but fundamentally restructuring how quality was delivered. Our goal was simple but ambitious: achieve painless, fast, and reliable releases.

The QA Stages in the Pipeline

In my talk, I outlined a pipeline where quality is not a final phase but a series of gates embedded throughout the development lifecycle:

The Developer Stage (Shift-Left)

Quality begins before code is even committed. Developers are responsible for the base of the testing pyramid. This includes mandatory code reviews and writing comprehensive unit tests. Static analysis tools like SonarQube run automatically to catch code smells and security vulnerabilities early.

Continuous Integration (CI) & Build

Once code is pushed, the automated pipeline kicks in. This stage runs integration tests to ensure new modules play nicely with existing ones. If a build fails here, the "line stops" and fixing it becomes the top priority. This prevents bad code from ever reaching the QA environment.

Automated Functional/E2E Testing

This is where the heavy lifting of regression testing happens. We employ a specialized team structure here. Automation Engineers build and maintain the frameworks using tools like Selenium and Appium while QA Analysts define the test scenarios and strategy. This separation ensures the tooling is robust while the tests themselves remain relevant to user needs.

The "Release Train" Model

Not all platforms move at the same speed.

• Backend/Web: Deploys continuously, sometimes multiple times a day.
• Mobile (iOS/Android): Follows a strict "release train" schedule, such as every two weeks. If a feature is not ready or quality-checked by the departure time, it misses the train and waits for the next one.

This brings predictability to our release cycle.

Post-Release: "Morning Gymnastics"

QA does not end at deployment. We practice what we call "Continuous Operations" or "Morning Gymnastics" by proactively checking dashboards and business metrics immediately after releases to catch issues before users report them.

Key Takeaways for Your Team

1. Invest in Automation Infrastructure: Do not just write tests. You must build a stable platform for running them. We invested in dedicated automation engineers to treat the test suite as a product itself.

2. Clarify Roles: Split the burden of quality. Developers own the code quality via unit tests while QA focuses on user flows and system integrity.

3. Monitor Production: A green build is not the finish line. Real success is measured by stability in the hands of the user.

Conclusion

Our approach at Dashlane demonstrates that a robust release pipeline is more than just tools. It is a culture. By defining clear stages for QA and automating the repetitive work, teams can free up humans to do what they do best: creative exploratory testing and solving complex problems.