Beyond Gatekeeping: How Omise QA Engineers Became Architects of Quality

What comes to mind when you hear "Quality Assurance"? For many, it's a team at the end of the development pipeline, a final gatekeeper whose job is to find bugs before a release. They get requirements from a Product Owner, receive the finished software from developers, and begin the hunt.

This traditional model is not the reality at Omise. We are part of a fast-moving, agile team with real ownership, contributing to mission-driven work that helps people and businesses access the digital economy. We believe that true quality isn't something you inspect at the end; it's something you build from the very beginning.

Our philosophy is simple but transformative: we are moving from being gatekeepers to becoming "Architects of Quality". We partner with our development teams to build quality directly into the system, creating a comprehensive quality ecosystem rather than relying on traditional, manual checks.

This is how we do it—Our approach is guided by the Agile Testing Manifesto developed by Samantha Laing and Karen Greaves of Growing Agile: A Coach's Guide to Agile Testing. Their framework enables us to create a dynamic, integrated approach to quality from the outset. We focus on preventing bugs over finding them, making quality a shared responsibility for the entire team from day one.

‍

Quality in Action: An Integrated Approach

To live by our manifesto, we had to redefine what "testing" means in our workflow. At Omise, testing is not a separate phase or a column on a task board. Instead, Testing is an activity integrated throughout the entire software development lifecycle (SDLC).

We visualize this using a holistic testing model that emphasizes two key strategies: Shifting Left and Shifting Right.

The Shift-Left Approach: Preventing bugs early, moving quality activities as early as possible in the development process. Since most bugs originate from the requirements phase, our goal here is to prevent them. We maximize testing on our local machines and on-demand development environment (a temporary, isolated, and fully-functional environment), and in early stages by focusing on:

• RiskStorming: Collaborative sessions to identify risks during the planning phase.
• Unit Testing, PACT Testing, and Service Testing: Ensuring individual components and their interactions are solid from the build phase onwards.

The Shift-Right Approach: Learning from production involves testing and monitoring in the production environment. This isn't about finding bugs after release; it's about learning, observing, and ensuring we are building the best possible system for our users. Key activities include:

• Synthetics and Exploratory Testing: Proactively testing in the live environment to understand real-world performance and user experience.
• Monitoring and Data Analytics: Observing system health and user behavior to inform future improvements.
• Incident Lessons Learned: Treating every production incident not as a failure, but as a valuable opportunity to learn and improve. When something goes wrong, we conduct a Post-Mortem, identifying the root cause and creating actionable feedback loops.

‍

Beyond the approaches: How we engineer our quality ecosystem

At Omise, quality isn't just a final check—it's an ecosystem we actively build and nurture. Our mission is to empower teams by scaling test automation, feature validation, and robust CI/CD quality gates across our entire platform.

Here's a look at how we apply technology to make that happen.

‍

Our Shared Automation Platforms

Instead of just using off-the-shelf tools, we’ve built upon popular open-source frameworks to create internal, shared platforms: "Omise Cypress" and "Omise Robot Framework."

These aren't simple wrappers; they are customized tool sets that provide our engineers with powerful, shared utilities right out of the box, including:

• Support for modern protocols such as gRPC.
• Customized summary reporting and test statistics logging.
• A robust, intelligent retry mechanism for handling flaky tests.
• ‍

"Test Before You Merge": On-Demand Environments

A true game-changer for our workflow is the ability to test changes in an isolated, production-like setting before they are merged. We accomplish this with on-demand development environments.

When a developer opens a Pull Request (PR), our CI/CD pipeline automatically:

1. Builds the necessary Docker images.
2. Pushes them to a container registry.
3. Uses Helm to deploy the application and its dependencies into a unique Kubernetes namespace.

Once this temporary environment is live, automated tests run against it to validate the code changes. After the PR is handled, the environment is deleted. This entire process allows developers to test their work safely and confidently without impacting shared staging environments.

‍

The Impact

Building our own quality ecosystem is a strategic investment. These custom platforms and on-demand environments ensure consistency, slash setup times, and, most importantly, empower every developer to contribute to our high standard of quality.

Ultimately, our goal is to "Deliver Quality software to support the growth" of Omise and our merchants. By embedding quality into every step and empowering our teams with the right tools and mindset, we move beyond the limitations of traditional QA and truly become architects of an exceptional product.