Qualidade nas squads: modelo executivo para CTOs
Como colocar qualidade nas squads, usar QA como enabler e manter o risco sob controle — com um piloto de 90 dias.
Resposta curta: sim, 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 só nas mudanças que pedem isso.
O objetivo não é “zero QA”. É uma squad que não depende de QA para cada entrega — e que 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: só 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 somente 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 só 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 só muda o 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 só 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 — só não testa tudo. Preserve tempo para exploração, pairing e problemas difíceis, ou a especialidade se perde.
Plataforma e IA: dê capacidade antes de cobrar autonomia
A squad só assume qualidade se testar, liberar e observar sem abrir tickets para outro time. A plataforma existe para tornar 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.
A squad — com ou sem agente de código — investiga apenas 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 — 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.