Beyond Theory: Building a Testing Standard for the Frontlines

At Envíame, we weren’t just facing a simple code problem; we were facing a challenge of scale. With more than 500 repositories (and that’s a conservative estimate) coexisting in a microservices ecosystem, the absence of a declared quality standard wasn’t just technical debt — it was a direct risk to our operational continuity.

Our reality was a fragmented frontline: elite units operating with cutting-edge tech stacks living alongside battalions holding the line in trenches dug years ago, defending legacy code that still powers critical business processes. The symptom was inconsistency. The challenge was to standardize without bureaucratizing, giving every developer the tools to survive in their own trench without suffocating the speed of the business.

Strategic definition

At Envíame, as we previously described in **Why don’t we have a QA department at Enviame?**) we do not have a dedicated QA department. Over time, we moved from virtual “watercooler” chats to closed-door leadership discussions. We knew quality shouldn’t be optional, but it couldn’t be a rigid imposition either. We couldn’t just demand a test coverage percentage and call it a day. We defined quality as multidimensional: a unit test, on its own, can be a mirage if context is ignored. Code can pass its logical tests and still be inefficient, vulnerable, or so tightly coupled that it’s impossible to maintain.

We established three technical pillars:

• Static Analysis: we implemented tools like Ruff (Python) and ESLint (JS) to standardize style and eliminate noise during peer reviews.
• Code Health: while already in use, we turned SonarQube into a pillar for monitoring code smells, vulnerabilities, and duplication, in addition to reflecting metrics like code coverage shared through our CI/CD pipelines.
• Architecture: although it has been part of our best practices for years, we determined that Clean Architecture was our greatest enabler. If code follows the Dependency Inversion Principle (DIP), it is testable by design; therefore, without solid architecture, testing is just a band-aid.

Validation in the field: listening to the trenches

Once the framework was defined, we took it to the battlefield. We gathered feedback from the teams and identified two key pain points: the difficulty of dealing with highly cohesive (coupled) architectures and the constant pressure of deadlines. We understood the standard had to be flexible to be realistic.

This is how our Critical Flow was born. Instead of chasing a global 80% coverage — a figure that often incentivizes “garbage” tests — we asked each team to identify the most vital use cases in their README.md. These are the flows that, if they fail, compromise the operation, generate a disastrous economic impact, or halt the business. A 10,000-line repository can be reliable with 30% coverage if that percentage protects the heart of the business.

For legacy systems where decoupling was unfeasible, we decided to move up the testing pyramid. We proposed using tools like Robot Framework (as Matias Angeli covers in detail in **Engineering quality without QA: Our playbook at Envíame**) to perform E2E testing. This provided an extra safety net: if we can’t test the internal logic without breaking the monolith, we at least ensure the system’s output remains correct and the flow remains functional.

Culture over “Story Points”

Another recurring debate was the impact of adding tests on our time-to-market and development velocity: Should we increase Story Points to account for testing? After many discussions, our conclusion was a hard “No.” Testing is not an “extra” you pay for separately; it must be an intrinsic part of our Definition of Done (DoD). That time is an investment we recover by avoiding hours of debugging buried bugs or side effects in seemingly unrelated features.

To sustain this vision, we had to pave the way. You cannot demand quality without facilitating it. We have dedicated — and continue to dedicate — a massive effort to hardening our pipeline infrastructure. It’s not a one-time task; given the sheer number of repositories, standardizing technical baselines and configuring automated security and quality steps for every merge is a constant grind. It is a living process that requires permanent vigilance to ensure tests run correctly, removing friction so the developer can focus on what really matters: the business logic.

The Ambassadors: The human factor

How do you make this vision breathe across all fronts without becoming “code police”? The solution was profoundly human: the creation of Testing Ambassadors.

We didn’t look for supervisors; we looked for advocates. We identified developers in each team with a natural interest in technical quality and empowered them to be the bridge between the standard and the trenches. These ambassadors, chosen for their expertise and enthusiasm, evangelize by example. They are the ones currently preparing to maintain the standard, support their peers, and ensure that testing is a real requirement in daily operations.

This structure is not static. By staying connected, ambassadors share learnings, allowing the standard to be a living organism. Today, this group is already exploring how to automate the definition of Critical Flows and how AI can help us generate edge cases and test boilerplate. Although we still live with historical technical debt, thanks to this network, quality stopped being an external imposition and became a shared goal.

Reflections and continuous improvement

After this journey of definitions and rollout, these are the lessons that stand out:

1. Quality is an agreement: a standard that isn’t socialized is doomed to be forgotten.
2. Pareto’s Law: prioritize the critical flow. Ten vital tests are worth more than a thousand syntax tests.
3. Architecture is the foundation: if it’s hard to test, check the coupling. Clean Architecture, Hexagonal, or DDD are long-term investments.
4. Make the right path the easiest path: automate your pipelines. Developers should spend energy creating, not configuring.
5. Create advocates, not auditors: quality is contagious through admiration and support, not sanctions.

We haven’t reached the summit yet; we are just starting the climb, and there is a long road ahead. Implementing a standard in an organization that changes every day is an exercise in continuous improvement. Today, we have a more constant monitoring system where we review metrics and progress, and most importantly, we keep our pulse on our Ambassadors. If a team falls behind, we don’t look for culprits — we look for blockers: Data issues? Delivery pressure? Architecture?

This standard is our compass. We continue to work on environment standardization and AI tools to make the developer’s life easier. At the end of the day, success isn’t a 100% coverage report; success happens when, in every Pull Request, quality stops being a burden and becomes a visible, measurable, and, above all, shared commitment by the entire team. We keep iterating because, at scale, the only constant is change.

Acknowledging Our Testing Ambassadors

Special thanks to our first group of ambassadors for leading this change:

• Bryan Gomez
• Rodrigo Echeverría
• Jose Espinosa
• Carlos De la Cruz
• Juan Garcia
• Pablo Herrera
• Juan De Giorgi
• Gonzalo Rojas

Recommended reading to dive deeper into testing:

• *Elevate Your Code with Automation: Pipelines in Bitbucket and SonarQube Analysis for Node.js Bryan Gomez*
• *Mastering code quality Jose Espinosa*
• *Level up your frontend with unit testing Erikagonza25*