O sintoma mais reconhecível do problema é conhecido por qualquer equipa ágil: o desenvolvimento entrega o build no final do sprint, o QA inicia os testes, surgem defeitos que ninguém previu, e a equipa entra em modo de negociação sobre o que entra no release e o que é adiado. A conversa costuma derivar numa pergunta implícita — porque é que o QA não encontrou isto antes? — que ninguém responde porque todos conhecem a resposta real: o QA não esteve na conversa onde o problema nasceu.
A fricção entre QA e desenvolvimento na maioria das equipas não tem origem técnica. Tem origem estrutural: o modelo de trabalho está concebido para que o QA receba o software no final e o valide, não para que o QA participe na definição do que se constrói e de como se valida desde o início. Mudar esse resultado exige mudar a estrutura, não o talento nem as ferramentas.
O modelo que gera fricção: o handoff sequencial
O padrão mais comum em equipas que reportam fricção entre QA e desenvolvimento é aquele que a indústria descreve como “throw it over the wall”: o negócio escreve os requisitos, o desenvolvimento constrói o que interpreta, o QA testa o que recebe, e cada função tem uma definição distinta do que “pronto” significa.
Nesse modelo, os defeitos que surgem na fase de testes não são falhas de QA nem de desenvolvimento: são a consequência inevitável de três grupos terem trabalhado com três interpretações distintas do mesmo requisito sem as terem alinhado antes. 67% dos erros em software são introduzidos na fase de design ou de requisitos (Capers Jones), não na implementação. Um modelo de trabalho que não envolve o QA até depois da implementação não consegue detetar esses erros antes de se tornarem defeitos dispendiosos.
As equipas de elite, segundo o DORA State of DevOps 2024, fazem deployments 127 vezes mais rápido e recuperam de falhas 8 vezes mais rápido do que as equipas de baixo desempenho. Essa diferença de desempenho não vem de melhores ferramentas: vem de um modelo de colaboração em que a qualidade é uma responsabilidade partilhada desde o início do ciclo, não uma etapa de verificação no final.
As cinco mudanças que eliminam a fricção
1. Three Amigos antes de o desenvolvimento começar
O método dos Três Amigos é uma sessão estruturada em que o Product Owner, o programador e o engenheiro de QA revêm juntos cada história de utilizador antes de a equipa começar a codificá-la. O objetivo não é dividir tarefas: é chegar a uma interpretação partilhada do que o sistema deve fazer, que casos de fronteira existem e que critério define que a história está concluída.
Cada perfil contribui com uma perspetiva que os outros não têm: o Product Owner clarifica o valor de negócio e os casos de uso reais; o programador identifica restrições técnicas e dependências que afetam o âmbito; o engenheiro de QE deteta ambiguidades, cenários não cobertos e condições de falha que a equipa não tinha considerado. O resultado de 30 a 45 minutos de conversa antes do desenvolvimento evita horas de retrabalho após a entrega.
A sessão de Três Amigos é a primeira linha de defesa contra o defeito que ninguém previu porque ninguém fez a pergunta certa no momento certo.
2. Critérios de aceitação em formato BDD
O critério de aceitação escrito em linguagem natural — “o sistema deve processar o pagamento corretamente” — deixa espaço para três interpretações distintas consoante quem o lê. O mesmo critério em formato BDD elimina essa ambiguidade:
Dado que o utilizador tem saldo suficiente,
quando executa uma transferência por um montante inferior ao seu saldo disponível,
então o sistema debita o montante, gera o comprovativo e atualiza o saldo em tempo real.
Esse formato — Given/When/Then — produz três benefícios simultâneos: o desenvolvimento sabe exatamente que comportamento deve implementar, o QE sabe exatamente que cenário deve testar e que resultado esperar, e o critério pode converter-se diretamente num caso de teste automatizado sem reinterpretação adicional.
A eficácia do formato BDD não está na ferramenta que o implementa, mas sim na conversa que obriga a ter: nenhum critério pode ser escrito em Given/When/Then se os três perfis não tiverem chegado a uma interpretação comum do comportamento esperado.
3. Definition of Done com critérios de qualidade integrados
A Definition of Done (DoD) é o acordo da equipa sobre que condições uma história deve cumprir para ser considerada concluída. Em equipas com o padrão de handoff sequencial, a DoD costuma estar definida a partir da perspetiva do desenvolvimento: o código compila, os testes unitários passam, o PR está aprovado. O QA surge depois como uma etapa adicional, não como parte da definição de pronto.
Uma DoD que integra a qualidade desde o início inclui critérios de QE como parte integral: testes unitários escritos pelo programador, critérios de aceitação BDD automatizados, cobertura mínima definida pela equipa para esse módulo, e revisão de QE sobre os cenários de fronteira identificados na sessão de Três Amigos. Quando o QA faz parte da definição de pronto e não é uma etapa posterior, o “já terminei” do programador e o “ainda não está pronto” do testador deixam de ser duas posições opostas.
4. Quality gates no pipeline partilhados pela equipa
Um quality gate no pipeline de CI/CD que bloqueia o merge quando os testes falham não é uma restrição do QA sobre o desenvolvimento: é um acordo da equipa sobre que nível de qualidade é aceitável para avançar. A diferença entre essas duas interpretações determina se o quality gate gera fricção ou gera confiança.
As equipas que têm quality gates bem concebidos definem os limiares em conjunto — taxa de cobertura mínima, taxa de erro máxima, tempo de resposta aceitável — e revêem-nos em cada retrospetiva. O gate não é um julgamento: é um sinal objetivo de que o código não cumpre o critério que a equipa acordou. Quando todos participaram na definição desse critério, ninguém pode argumentar que é arbitrário.
76% das equipas DevOps de alto desempenho já usam IA para otimizar e priorizar testes (State of Testing in DevOps Report 2024). Essa capacidade é melhor aproveitada quando os quality gates do pipeline são responsabilidade de toda a equipa, não apenas da área de QA.
5. Retrospetivas de qualidade com dados partilhados
A retrospetiva de sprint é o momento em que a equipa pode rever que defeitos escaparam para produção, quais foram encontrados nos testes de QE, e quais foram detetados em code review pelo próprio programador. Essa distribuição diz mais sobre a saúde do processo de colaboração do que qualquer métrica de cobertura.
As retrospetivas de qualidade mais úteis não procuram um responsável: procuram um padrão. Se os defeitos que escapam para produção se concentram num tipo de módulo, num tipo de história ou numa etapa específica do pipeline, essa informação é acionável. A equipa pode ajustar onde adiciona cobertura, em que tipo de histórias vale a pena fazer sessões de Três Amigos mais longas, e que cenários necessitam de automatização prioritária.
As organizações com cultura de qualidade partilhada resolvem interrupções mais rapidamente e reduzem a taxa de erros de forma sustentada (Gartner, G00813269). Essa diferença é a consequência de os defeitos se transformarem em aprendizagens de processo, não em discussões entre departamentos.
As métricas que unem as duas equipas
O principal indicador de que a colaboração entre QA e desenvolvimento está a melhorar não é o número de bugs reportados nem a cobertura de testes: é a taxa de defeitos escapados para produção por sprint, medida com tendência ao longo do tempo.
Essa métrica é neutra: não acusa o QA de não ter encontrado o defeito nem o programador de o ter introduzido. Descreve o resultado do processo completo e gera uma conversa sobre onde melhorar o processo, não sobre quem falhou. As métricas complementares que completam o quadro são o tempo médio de deteção desde a introdução do defeito, o rácio de trabalho planeado versus não planeado por sprint, e a proporção de defeitos detetados em cada etapa do ciclo — requisitos, desenvolvimento, testes, produção.
Quando essas métricas são publicadas num dashboard partilhado por toda a equipa — não apenas pelo QA — a conversa sobre qualidade transforma-se numa conversa de equipa.
A perspetiva da MTP
Na MTP, concebemos o modelo de colaboração entre QA e desenvolvimento como parte da estratégia de QE, não como uma oficina de comunicação. As mudanças estruturais — sessões de Três Amigos, critérios BDD, Definition of Done com qualidade integrada, quality gates partilhados — são implementadas como parte do roadmap que produzimos com a Omniatest®, a metodologia proprietária da MTP. A MTP é a primeira empresa certificada TMMi Nível 5 no mundo, o que respalda a reprodutibilidade e a rastreabilidade do processo em cada equipa com a qual trabalhamos.
Perguntas frequentes
- Quanto tempo demora a ver resultados concretos ao melhorar a colaboração entre QA e desenvolvimento? Os primeiros indicadores mensuráveis surgem em dois a quatro sprints: redução do número de defeitos encontrados pelo QE que o programador não tinha previsto, e diminuição do tempo gasto a negociar o que entra no release. As mudanças estruturais que produzem resultados sustentados — critérios BDD em todas as histórias, quality gates ativos no pipeline, retrospetivas de qualidade regulares — consolidam o seu impacto entre três e seis meses. As organizações que implementam shift-left e colaboração estruturada reportam reduções significativas nos custos de correção de defeitos e no tempo de comercialização.
- O método dos Três Amigos aplica-se a todos os tipos de histórias? Nem todas as histórias requerem a mesma profundidade de sessão. As histórias de alta complexidade técnica, as que envolvem fluxos críticos de negócio ou as que têm impacto regulatório justificam uma sessão completa de Três Amigos. As histórias de menor complexidade podem resolver-se com uma revisão rápida de critérios de aceitação no planeamento do sprint. O sinal para saber quando é necessária uma sessão completa é a presença de ambiguidade no requisito: se o Product Owner, o programador e o testador tiverem interpretações distintas após ler a história, a sessão é necessária.
- Como medir se a colaboração entre QA e desenvolvimento está a melhorar? A métrica principal é a distribuição de defeitos por etapa de deteção: quantos são detetados nos requisitos, quantos no desenvolvimento, quantos nos testes de QE e quantos em produção. Uma colaboração que melhora desloca a distribuição para a esquerda: mais defeitos detetados em etapas iniciais, menos escapados para produção. As métricas complementares são o tempo de ciclo de deteção até à correção, o rácio de trabalho não planeado no sprint, e a taxa de histórias que passam no QE à primeira sem retrabalho significativo.
A sua equipa de QA continua a receber builds no final do sprint para validar o que já está construído?
A MTP concebe o modelo de colaboração entre QA e desenvolvimento como parte do roadmap de maturidade. O Quick Assessment identifica em cinco dias úteis os pontos de maior fricção e as ações de maior impacto.