Automação de QA e engenharia de release para uma plataforma SaaS B2B dos Estados Unidos

O cliente é uma empresa de software B2B sediada em Boston que fornece uma plataforma de automação de fluxos de trabalho a clientes de mercado intermediário e grandes empresas na América do Norte. No início do projeto, a empresa tinha aproximadamente USD 68 milhões de receita recorrente anual após uma rodada Série C, com uma organização de engenharia de 82 pessoas. Seu plano de crescimento exigia um aumento expressivo na velocidade de release sem um aumento correspondente nos incidentes em produção.

A velocidade de release havia se tornado a restrição determinante do roadmap. A empresa entregava aproximadamente 3,4 releases de produção por mês contra uma meta de releases semanais por equipe. O gargalo era um ciclo manual de regressão que consumia de cinco a sete dias antes de cada release. A automação de testes existia, mas não era confiável. A cobertura ficava em cerca de 35% e a suíte carregava uma taxa de instabilidade alta o suficiente para que os engenheiros reexecutassem as falhas em vez de investigá-las, de modo que falhas genuínas às vezes eram descartadas. Uma suíte em que não se confia é pior do que nenhuma, porque consome tempo enquanto oferece uma falsa garantia.

Os defeitos que escapavam estavam subindo com o volume de releases, com seis críticos e dezoito de alta gravidade escapando no trimestre anterior ao projeto, vários chegando a clientes corporativos.

A contratação não havia resolvido. Os engenheiros de automação de QA de Boston pediam uma remuneração que a empresa achava difícil justificar contra contratações de funcionalidades, e duas contratações de QA haviam ambas migrado para equipes de funcionalidades em poucos meses.

O cliente selecionou a Corpshore Colombia principalmente por fuso horário e talento. Medellín é um polo de tecnologia reconhecido, com uma forte base de engenharia, e QA e engenharia de release são funções intensivas em colaboração, nas quais o cliente havia concluído, a partir de uma experiência offshore anterior, que o repasse assíncrono, e não a habilidade, era a causa raiz do fracasso. A Corpshore propôs tratar o projeto como transferência de capacidade em vez de aluguel de capacidade, comprometendo-se a deixar o cliente com uma suíte de testes confiável e documentada e um processo de release que seus próprios engenheiros pudessem operar, com marcos definidos de transferência de conhecimento. O líder proposto pela Corpshore passou dois dias com a equipe de plataforma do cliente e identificou a taxa de instabilidade, e não a cobertura, como o principal problema, reformulando o entendimento do cliente.

Vinte e dois engenheiros em Medellín: dois líderes técnicos, seis sêniores, dez plenos e quatro juniores, abrangendo automação de QA, DevOps e engenharia de release. A equipe trabalha das 09:00 às 18:00 do horário do Leste dos EUA, o mesmo relógio de Boston, participando das reuniões diárias ao vivo. Stack: TypeScript, Playwright, Jest, GitHub Actions, Terraform, AWS, Datadog. Todos os engenheiros são dedicados à conta.

Corrigir a instabilidade antes de adicionar cobertura. As primeiras oito semanas trataram da confiabilidade da suíte em vez da cobertura, sob o argumento de que adicionar testes a uma suíte não confiável agrava o problema. A taxa de instabilidade caiu de 32% para menos de 3% antes de o trabalho de cobertura começar. Cobertura onde está o risco. A ampliação da cobertura foi priorizada pelo histórico de incidentes em produção e pela rotatividade de código em vez de por módulo, concentrando o esforço onde os defeitos que escapavam de fato haviam se originado.

Infraestrutura de entrega progressiva. A infraestrutura de feature flagging e release canário desacoplou os releases das implantações e permitiu rollback sem um ciclo completo de release, o que permitiu que a frequência subisse sem uma alta correspondente na gravidade dos incidentes.

Transferência de conhecimento documentada. Quatro marcos definidos de transferência, com documentação e aceite do cliente, asseguram que a própria equipe do cliente possa operar o pipeline.

Frequência de release

Os releases de produção subiram de 3,4 por mês para 24,6 até o mês 12, superando a meta de releases semanais por equipe. O ciclo manual de regressão caiu de cinco a sete dias para menos de quatro horas. Os defeitos que escapavam caíram em todas as faixas de gravidade apesar do aumento de volume, com os críticos caindo de seis por trimestre para um e os de alta gravidade de dezoito para quatro.

A cobertura de testes subiu de 35% para 87% com a taxa de instabilidade mantida abaixo de 3%, e os próprios engenheiros do cliente agora ampliam a suíte de forma independente, o objetivo declarado de transferência de capacidade.

A suíte de testes, o pipeline de release e a infraestrutura de entrega progressiva são de propriedade do cliente e operados em conjunto. Todos os quatro marcos de transferência de conhecimento foram concluídos. O cliente estendeu o projeto para a engenharia de confiabilidade de plataforma, que seu VP descreve como uma escolha e não uma dependência.