Quality assurance is the dimension of software development that most teams handle reactively: a bug reaches production, the team adds a test to prevent that specific bug, and the test suite grows organically in response to failures rather than by design. This approach works at small scale. At 10+ engineers shipping across multiple simultaneous feature tracks, it collapses.

Without intentional QA architecture, the test suite becomes slow, brittle, and progressively unmaintained actively slowing delivery rather than protecting it. Engineers learn to bypass slow CI pipelines. Intermittent test failures get ignored. Production incidents multiply as coverage degrades relative to codebase complexity.

Building QA automation infrastructure that scales requires the same intentionality as any other engineering architecture decision. This article presents the framework Cafeto uses when building QA capability for US tech companies and why Colombian SDET engineers are particularly well-positioned to deliver it.

The QA automation pyramid: The foundational framework

The QA Automation Pyramid, introduced by Mike Cohn in “Succeeding with Agile” (2010), provides the structural model for sustainable test automation. Most teams violate it systematically.

UNIT TESTS (Base — ~70% of your test suite)

Fast, isolated tests of individual functions and components. Written by developers during implementation. Run in seconds. The cheapest tests to write and maintain, catching bugs at the lowest cost of the development cycle.

INTEGRATION / SERVICE TESTS (Middle — ~20%)

Tests that verify interactions between components, API contracts, database interactions, service-to-service communication. Slower than unit tests but faster than UI tests. Contract testing (using tools like Pact) belongs in this tier and is dramatically underinvested in most codebases.

END-TO-END / UI TESTS (Top — ~10%)

Full workflow tests from the user’s perspective. Powerful but expensive: slow to run, brittle to UI changes, difficult to maintain. These should test critical user journeys only checkout flow, authentication, core business operations. Not everything.

The violation: most teams have the pyramid inverted. Too many brittle Selenium/Playwright tests at the top, too few fast unit tests at the base. The result: test suites that take 45 minutes to run, fail intermittently, and get bypassed by engineers under deadline pressure.

Reference: Cohn, M. (2010). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional.

Tooling choices that scale in 2026

For modern web and mobile applications, this tooling stack provides a strong foundation:

END-TO-END TESTING: PLAYWRIGHT

Microsoft’s Playwright has become the dominant choice for browser automation in 2025–2026, displacing Selenium for most new projects. Key advantages: built-in auto-wait eliminates the flaky timing issues that plagued Selenium, native TypeScript/JavaScript API, cross-browser testing (Chromium, Firefox, WebKit) in a single framework, and strong VS Code integration.

UNIT TESTING: JEST / VITEST / PYTEST

For TypeScript/JavaScript codebases, Jest and the newer Vitest (with identical API but significantly faster execution via Vite’s native ESM support) are the standard. For Python backends, Pytest with its powerful fixture system handles unit and integration testing.

CONTRACT TESTING: PACT

For microservices architectures, Pact enables contract testing verifying that service interfaces match consumer expectations without requiring a full integration environment. This is the most underused test type in modern engineering teams and the one that would prevent the most integration failures.

PERFORMANCE AND LOAD TESTING: K6

Developer-friendly JavaScript API, integrates into CI/CD pipelines as code, supports threshold-based CI gates. K6’s cloud offering (Grafana Cloud k6) provides distributed load testing without infrastructure overhead.

Building a CI/CD-Integrated test pipeline

The test suite is only as effective as its integration into the development workflow. A comprehensive test suite that runs weekly in a cron job is not a QA strategy it is theater.

Pull request gates (every PR):

• Static analysis (ESLint, SonarQube, TypeScript strict mode): catches syntax, style, and type errors before human review

• Unit tests: all existing tests must pass; new code requires test coverage

• Security scanning (Snyk, Dependabot, GitHub Advanced Security): dependency vulnerabilities and secrets scanning

Merge-to-main gates:

• Integration and contract tests against staging environment

• Smoke tests verifying critical user journeys

• Build and deployment to staging

Scheduled full runs (nightly):

• Full Playwright E2E suite

• Performance tests with baseline comparison

• Dependency audit

Flaky test protocol:

A test that fails intermittently is worse than no test it trains engineers to ignore CI failures. Dedicate explicit engineering time each sprint to identifying and fixing flaky tests. Track flaky test rate as a KPI.

The SDET role: Why traditional QA is insufficient

The traditional QA tester role manual test case execution, bug reporting, regression testing — cannot scale with modern high-velocity engineering teams. The required profile is the Software Development Engineer in Test (SDET): a QA professional with strong software engineering skills who builds and maintains the automation infrastructure.

SDETs:

• Write code. They design test architectures, build CI/CD integrations, and maintain test frameworks as first-class software products.

• Participate in requirement definition. By reviewing user stories before development begins, SDETs ensure that acceptance criteria are testable preventing the “not testable as specified” failures that emerge late in development.

• Own test infrastructure quality. They track flaky test rates, test execution time, and coverage gaps as ongoing engineering metrics, not as periodic cleanup tasks.

In Latin America, the SDET profile is in high demand and growing supply. Colombia’s engineering ecosystem has developed a particularly strong SDET talent pool, due in part to the emphasis on applied engineering education at institutions like Universidad de los Andes and Universidad EAFIT.

Cafeto places SDETs with US clients for both staff augmentation (embedding in existing teams) and dedicated QA capability builds (standing up the entire QA function from scratch).

The nearshore QA advantage

Time zone alignment is particularly critical for QA integration. CI/CD pipeline failures, test infrastructure issues, and pre-release regression runs require immediate response. A QA engineer in a 12-hour-different time zone cannot provide this.

Colombian SDET engineers working in US Eastern Time have full overlap with the US development team, enabling:

• Same-day resolution of CI pipeline failures

• Live participation in sprint ceremonies (planning, review, retrospective)

• Real-time pair programming with developers during test architecture decisions

• Immediate response to pre-release regression failures

Cafeto’s 7% attrition rate is especially valuable for QA engineering: test automation expertise takes 3–6 months to build on a specific codebase. Engineers who leave reset that accumulation. Engineers who stay compound it.

QA automation is an engineering discipline that determines whether your product can scale. Teams that invest in QA architecture pyramid-based strategy, appropriate tooling, CI/CD integration, and SDET capability ship faster and with higher confidence than those that don’t.

Cafeto’s Colombian SDET engineers bring this architectural discipline to US clients who are ready to build their QA capability properly. The talent is there, the time zone is right, and the compounding value of low-attrition QA expertise is real.

Let’s build your testing infrastructure so it grows with your product.

Bibliography

• Cohn, M. (2010). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional.

• Humble, J., & Farley, D. (2023). Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. Addison-Wesley Professional.

• Microsoft. (2025). Playwright documentation. https://playwright.dev

• Pact Foundation. (2025). Pact: Contract testing for microservices. https://docs.pact.io

• Arachchi, S. A. I. B. S., & Perera, I. (2024). Continuous testing in DevOps: Techniques and challenges. Journal of Software Engineering and Applications.

Book a Consultation to learn about engineering operations to Colombia:

https://outlook.office.com/book/[email protected]/?ismsaljsauthenabled

Learn about: The Changing Economics of the H-1B Visa here