Qualidade nas squads: modelo executivo para CTOs
Como colocar qualidade nas squads, usar QA como enabler e manter o risco sob controle em um piloto de 90 dias.
Resposta curta: o modelo funciona com três condições
A squad precisa ser dona de construir, testar, liberar e operar. QA deixa de ser a etapa final e passa a ensinar, explorar riscos e melhorar as ferramentas. A liderança define onde a autonomia basta e onde ainda é necessária uma revisão independente.
Da decisão à escala, em quatro movimentos
Escreve os testes, libera, observa produção e corrige quando algo falha.
Ensina, pareia, explora riscos difíceis e melhora o sistema de qualidade.
Financia a plataforma e decide, com evidência, quais exceções são aceitáveis.
Esse modelo já tem nome e casos reais
A Atlassian chama de Quality Assistance: QA ensina, influencia e previne. A Team Topologies traz a regra mais importante: o enabler aumenta a capacidade e depois se afasta. O caso do Monzo mostra isso em prática.
Escolha o modelo pelo risco e pela maturidade
Não comece pelo ratio QA:dev. Pergunte duas coisas: quão perigosa é a mudança e quanto a squad consegue entregar sem ajuda?
Observe o contexto; aplique o modelo correspondente
Base frágil
Mantenha QA próximo por um período, com uma saída combinada.
Squad madura
Use Quality Assistance sob demanda, sem aprovação por ticket.
Problema repetido
Transforme ferramentas e práticas em uma plataforma sem filas.
Risco crítico
Adicione revisão independente nas mudanças que exigem esse cuidado.
O objetivo é uma squad que entrega sem depender de QA em cada mudança e sabe quando pedir ajuda.
Quem faz o quê
A regra é simples: a squad é dona da mudança; QA aumenta a capacidade; a plataforma remove trabalho repetitivo; a liderança assume as decisões de risco.
Quem age, qual artefato produz e onde QA entra
Squad
Define riscos, escreve testes, libera, observa produção e corrige.
QA / QE
Ensina, pareia, explora mudanças difíceis e espalha boas práticas.
Plataforma
Entrega testes, dados, ambientes e sinais sem depender de tickets.
Produto e liderança
Definem impacto, protegem capacidade e aceitam exceções de risco.
O mínimo para considerar uma mudança pronta
Prontidão: transfira o que a squad consegue sustentar
Mudar o organograma não cria autonomia. Transfira responsabilidade por squad e por serviço. Se faltar testabilidade, feedback, observabilidade ou recuperação, construa isso antes de remover a proteção atual.
Seis provas antes de transferir, não seis opiniões
6/6 comprovados: transfira mudanças normais e acompanhe o scorecard por 90 dias.
Qualquer "não": mantenha a proteção ligada à lacuna, dê um dono e teste de novo.
A squad está pronta para o novo modelo quando
Teste simples: se QA sair de férias por duas semanas, a squad consegue liberar, observar e recuperar uma mudança normal? Se não, ainda há uma dependência a remover.
Piloto de 90 dias: comece pequeno, aprenda rápido
Escolha uma squad, registre a linha de base e transfira uma capacidade por vez. Cada fase avança quando a evidência mostrar que o novo modelo está funcionando.
Quatro passos, uma squad
Linha de base e acordo
Transferência assistida
Proteções e autonomia
Autonomia e escala
Três conversas bastam
Squad e QA removem bloqueios e escolhem o próximo experimento.
Liderança olha sinais, risco e investimento necessário.
CTO decide: graduar, corrigir, estender ou parar.
A squad pode seguir sem o enabler quando
Métricas: acompanhe confiança, não volume
O painel precisa responder uma pergunta: estamos entregando mais rápido sem perder controle? Quantidade de testes, bugs encontrados e cobertura de código não respondem isso sozinhos.
Quatro sinais, suas fontes e a decisão que destravam
Um scorecard enxuto
| Dimensão | Acompanhe | Pergunta |
|---|---|---|
| Fluxo | Change lead time e deployment frequency | Estamos entregando em lotes menores? |
| Estabilidade | Change fail rate, rework e tempo de recuperação | Falhamos menos e recuperamos mais rápido? |
| Risco | Escapes graves e jornadas críticas protegidas | O cliente está menos exposto? |
| Capacidade | Tempo de feedback, saúde do pipeline e autonomia | A squad depende menos de QA? |
Use as métricas da DORA por serviço e compare cada time com sua própria linha de base. Cobertura e número de testes ajudam no diagnóstico, mas não devem virar meta executiva.
Riscos: o modelo falha quando a mudança fica no processo
Quality Assistance reduz filas e antecipa feedback. Mas pode apenas esconder o trabalho antigo, sobrecarregar a squad ou remover uma revisão que ainda era necessária. Observe comportamento, não organograma.
Quatro falhas previsíveis; oito controles verificáveis
| Falha | Você percebe quando | Corrija assim |
|---|---|---|
| Ninguém é dono | Teste sempre fica para depois | Defina um responsável por mudança e por cada proteção |
| QA continua sendo o aprovador escondido | A validação migra para mensagens privadas | Publique o que QA deixou de fazer e transfira aos poucos |
| A squad testa apenas o caminho feliz | Escapes de integração e regra de negócio crescem | Discuta riscos, teste em pares e explore em grupo |
| A automação perde confiança | Testes instáveis e exceções aumentam | Dê dono às suites e remova testes que não geram sinal |
| Os incentivos não mudam | Dev ganha por feature e QA por bugs | Compartilhe metas de fluxo, estabilidade e risco |
| A independência some cedo demais | O autor aprova sozinho uma mudança crítica | Mantenha revisão independente nos riscos definidos |
O que melhora
- Feedback chega enquanto o contexto ainda está fresco.
- Quem muda o sistema assume o resultado.
- QA trabalha nos riscos mais difíceis.
- Boas práticas se espalham pelas squads.
O que custa
- A velocidade pode cair no começo.
- Testabilidade e plataforma exigem investimento.
- A squad assume mais responsabilidades.
- A visão independente precisa ser preservada.
QA continua testando, mas concentra tempo em exploração, pairing e problemas difíceis. Sem esse espaço, a especialidade se perde.
Plataforma e IA: dê capacidade antes de cobrar autonomia
Para assumir qualidade, a squad precisa testar, liberar e observar sem abrir tickets para outro time. A plataforma torna o caminho seguro também o caminho mais fácil.
Uma mudança, um registro, três decisões
O mínimo viável
Feche o ciclo entre a falha e a correção
Quando QA deixa de executar toda regressão, o gargalo pode apenas mudar de lugar: uma pessoa encontra o problema, mas a squad recebe um vídeo solto, um ticket vago e logs sem contexto. A saída é tratar cada tentativa como uma unidade de evidência, com o que aconteceu, por que importa e onde investigar.
Da descoberta à correção comprovada
Uma pessoa reproduz o risco, marca o ponto importante e registra o que esperava.
Com ou sem agente de código, a squad investiga o necessário e corrige com permissão explícita.
A mesma jornada é repetida; a evidência anterior permanece intacta.
Comportamento, telas e sinais técnicos são comparados no mesmo contexto.
Validar a correção, manter aberto ou aceitar o risco com evidência.
QA preserva a intenção
Explora o risco, marca o momento importante e explica o resultado esperado sem montar um dossiê manual.
A evidência viaja junta
Replay, ações, rede, console, telas e notas ficam alinhados no tempo. Toda hipótese aponta para o fato que a sustenta.
A squad comprova a correção
Recebe contexto enxuto, corrige e repete a jornada. O antes/depois substitui o "funcionou aqui".
Investigação e diagnóstico podem ser acelerados por IA. Alterar código, aceitar risco e encerrar o problema continuam sendo decisões humanas.
Use IA para ampliar o sistema, não para esconder suas falhas
A DORA mostra que IA amplifica forças e problemas existentes. O World Quality Report 2025–26 reforça o limite. Use IA para gerar hipóteses, dados e triagem. Deixe com pessoas o contexto, o que é correto e a decisão de risco.
Oito perguntas para o CTO
Se a liderança não consegue responder a essas perguntas em uma frase cada, o modelo ainda não está pronto para escalar.
Oito decisões com uma prova para cada resposta
Escreva as oito respostas antes de mexer no organograma. Resposta vaga significa decisão pendente, não alinhamento.
Fontes e limites
Pesquisa atualizada em 6 de agosto de 2026. Casos mostram que o modelo é possível; estudos orientam as métricas; relatos de profissionais ajudam a encontrar riscos. Reddit e LinkedIn são sinais de campo, não prova estatística.
Use cada fonte para o que ela consegue provar
Atlassian: Quality Assistance
QA ensina, influencia e previne em vez de aprovar a entrega.
Monzo: Quality Coaching
Mostra a troca da aprovação formal por coaching, testes em grupo e pequenos experimentos.
Team Topologies: Enabling Teams
O enabler aumenta uma capacidade e sai sem criar nova dependência.
Microsoft: Shift-left com testes unitários
Código e testes ficam juntos e são responsabilidade de quem constrói.
Google: o que revisar em um code review
Testes úteis fazem parte da mesma mudança e recebem o mesmo cuidado do código.
DORA: métricas de entrega de software
Conecta fluxo e estabilidade sem usar volume de testes como qualidade.
DORA: Platform Engineering
Plataforma precisa ser medida por qualidade, adoção e sucesso da squad.
World Quality Report 2025–26
Mostra que IA ainda esbarra em dados, ferramentas e maturidade.
State of Testing 2026
Mostra a distância entre falar em valor e medir QA por atividade.
Holistic Testing, de Janet Gregory e Lisa Crispin
Qualidade é do time; especialistas aconselham e ensinam.
Reddit: times com e sem QA dedicado
Relatos mostram ganhos de autonomia e o risco de perder exploração e visão externa.
LinkedIn: "If quality is someone else's job..."
Responsabilidade dos devs não elimina a perspectiva especializada de QA.