A maioria dos QA engineers aparece para testar no dia 9 de um sprint de duas semanas. A essa altura, o custo de cada requisito perdido é mais dois dias para corrigir e retestar. O ponto de maior alavancagem do QA é o backlog refinement. Fazer perguntas sobre casos extremos antes do desenvolvimento começar define o que o desenvolvedor vai construir, quais requisitos serão documentados, e o que não vai virar um bug em produção.
QA não é uma fase. É uma presença.
O sinal mais claro de que um time entende Agile é como eles respondem a esta pergunta: "Onde o QA se encaixa no nosso sprint?" A resposta errada é "nos últimos três dias." A resposta certa é "em todo lugar."
Pense em um sprint de duas semanas trabalhando em um fluxo de checkout para um app de e-commerce. O time está adicionando um campo de código de desconto. Em um time fazendo errado, o QA fica sabendo disso no dia 9, quando o desenvolvedor marca o ticket como "pronto para testes". Três dias para testar e corrigir antes do sprint acabar.
Em um time fazendo certo, o QA é envolvido quando o ticket é criado. Antes de uma linha de código ser escrita, o QA engineer revisou os critérios de aceitação e perguntou: O que acontece se o código estiver expirado? E se o usuário aplicar dois códigos? E se o desconto deixar o total negativo? Essas perguntas são respondidas antes do desenvolvimento começar, o que significa que o desenvolvedor sabe o que construir da primeira vez. Quando o ticket chega para testes no dia 7, o QA já escreveu os casos de teste. Testar leva horas, não dias. Há buffer para correções de bugs.
Isso não é uma melhoria de processo. É o design pretendido do Agile. O modelo de time cross-functional existe precisamente para que a expertise do QA seja aplicada antes do código ser escrito, não depois.
Cerimônias do Sprint: onde o trabalho do QA realmente acontece
Cada cerimônia do Scrum é uma oportunidade. A maioria dos QA engineers usa apenas algumas delas.
Backlog refinement é onde o QA tem maior alavancagem. É a reunião em que os tickets futuros são detalhados antes do sprint começar: critérios de aceitação escritos, casos extremos discutidos, designs revisados. O papel do QA aqui é ser a pessoa que faz as perguntas que vão virar bugs se ninguém as fizer agora.Imagine uma sessão de refinement para uma nova página de perfil do usuário. Os critérios de aceitação dizem: "Usuário pode atualizar seu nome, e-mail e foto de perfil." Um desenvolvedor lê isso e sabe o que construir. Um QA engineer lê isso e pergunta: Quais são as regras de validação para o campo de nome? Tem limite de caracteres? Quais formatos de arquivo são aceitos para fotos? Qual é o tamanho máximo do arquivo? O que acontece se o usuário atualizar o e-mail para um que já existe no sistema? E se ele tentar fazer upload de um vírus?
Nenhum desses são casos extremos que o QA engineer inventou. São requisitos que ainda não foram documentados. Traga-os à tona no refinement e eles viram critérios de aceitação. Pule o refinement e eles viram bugs em produção.
Sprint planning é onde o QA estima. Não apenas estimativas de desenvolvimento, mas estimativas de teste. Uma story que leva dois dias para construir pode levar um dia para testar completamente, ou pode levar quatro. Trabalho de automação é separado do trabalho de teste manual. Se o QA não fala no planning, o sprint fica carregado com trabalho de desenvolvimento que fisicamente não pode ser testado no tempo restante. Daily standups são onde o QA comunica bloqueadores cedo. O pior padrão: um QA engineer silenciosamente bloqueado por dois dias porque um ambiente de staging está quebrado, então levantando isso no dia nove. O standup existe para trazer isso à tona no dia um. "Estou bloqueado. O staging está retornando erros 500 no serviço de pagamento, preciso que isso seja corrigido para continuar." O Scrum Master então assume a responsabilidade de remover esse bloqueador. Se você não está comunicando bloqueadores no standup, não está usando a cerimônia corretamente. Sprint retrospectives são onde o QA melhora o processo. Não reclama dele, mas o melhora. Há uma diferença. "As stories sempre chegam em testes sem detalhes suficientes" é uma reclamação. "As stories sempre chegam em testes sem detalhes suficientes; gostaria de propor que exijamos uma seção de notas de teste em cada ticket antes de entrar no sprint." Isso é uma contribuição de retrospective. QA engineers que usam bem as retros gradualmente moldam como o time inteiro opera.O que "pronto" significa do ponto de vista do QA
A Definition of Done é um acordo do time sobre quais condições um ticket deve atender antes de ser fechado. A maioria dos times tem uma. Muitos times deixam o QA definir sua parte mal.
Uma Definition of Done comum do QA parece: "Testes concluídos." Isso não é uma definição. É um gesto vago.
Uma Definition of Done melhor do QA para um ticket de feature inclui os critérios abaixo. Testes dos critérios de aceitação escritos e passando na suite de testes, testes exploratórios concluídos com notas de sessão registradas. Nenhum bug crítico ou de alta severidade aberto. Cenários de regressão verificados para features adjacentes afetadas, e o ticket testado nos ambientes especificados no acordo do sprint (staging, no mínimo).
A disciplina que isso cria é significativa. Quando um desenvolvedor marca algo como "pronto para QA", você tem um checklist. Quando fecha um ticket, pode apontar exatamente o que foi feito. Quando algo quebra em produção, pode rastrear qual parte do DoD não foi atendida. É assim que o trabalho do QA se torna auditável em vez de apenas confiado.
Para tickets de teste especificamente (onde o QA está escrevendo automação, não testando uma feature), a Definition of Done deve incluir três itens. Testes rodando no pipeline de CI sem flakiness em três execuções consecutivas. Testes cobrindo os cenários documentados no ticket. PR revisado por outro QA ou desenvolvedor familiarizado com o framework de testes.
Um cenário prático: um time tinha discussões recorrentes sobre se um teste automatizado conta como "pronto" se foi escrito mas rodando em um pipeline opcional que não bloqueava merges. Definir o DoD explicitamente resolveu isso. O teste não estava pronto até estar no pipeline bloqueador. O time concordou. As discussões pararam.
O anti-padrão "testar por último" e o Shift Left
Shift-left testing significa mover as atividades de teste para mais cedo no processo de desenvolvimento. A frase foi usada o suficiente para se tornar sem sentido em alguns times: um slogan sem prática. Aqui está o que realmente significa no contexto de um sprint.
Um time seguindo shift-left testing faz três coisas diferente. Primeiro, o QA escreve cenários de teste a partir dos critérios de aceitação antes do desenvolvimento começar. Não para rodá-los imediatamente, mas para que o desenvolvedor possa ver exatamente o que será validado. O desenvolvedor escreve código para passar esses cenários. Isso elimina toda uma classe de bugs: os em que o desenvolvedor entendeu mal como era o "pronto."
Segundo, os testes acontecem em paralelo com o desenvolvimento. Quando um desenvolvedor conclui uma sub-tarefa de uma story, essa parte vai para o QA enquanto o desenvolvimento continua na próxima sub-tarefa. Uma feature de login pode ter: renderização do formulário, lógica de validação, chamada de API, redirecionamento de sucesso, estados de erro. Teste a renderização do formulário enquanto a lógica de validação está sendo construída. Quando o desenvolvimento estiver completo, você já testou 60% da feature.
Terceiro, o QA participa da revisão de código para decisões de cobertura de testes. Não revisão linha a linha (esse é o domínio do desenvolvedor), mas uma revisão de: esse PR inclui testes? Os testes cobrem os critérios de aceitação? Há caminhos que não estão testados?
A preocupação que QA engineers frequentemente levantam: "Se eu fizer shift left e testar mais cedo, vou acabar testando features incompletas e retestando tudo." Isso é legítimo se você fizer shift left sem coordenar com os desenvolvedores. A correção são acordos explícitos de handoff. "Me avise quando o fluxo principal estiver funcionando. Vou testar isso. Depois me avise quando o tratamento de erros estiver pronto. Vou testar isso separadamente." Handoffs pequenos superam um grande handoff no final.
Kanban vs Scrum: o que a diferença significa para o QA
A diferença prática entre Scrum e Kanban do ponto de vista do QA resume-se a cadência e limites de WIP.
No Scrum, o trabalho chega em lotes definidos pelo sprint planning. Você tem duas semanas e um conjunto definido de tickets. Há cerimônias e momentos definidos onde o papel do QA é explícito.
No Kanban, o trabalho flui continuamente. Não há limite de sprint. Um desenvolvedor conclui algo e empurra para a coluna "Pronto para QA." O QA pega, testa, e empurra para Pronto. Outro chega. Repete.
Para times de produto com muitas features, o Scrum dá ao QA melhor aviso antecipado. Você pode ver o que está chegando no sprint e planejar a cobertura de testes antes dos tickets chegarem. Para times de suporte e manutenção (que fazem correções de bugs, trabalho de infraestrutura e melhorias pequenas), o Kanban frequentemente funciona melhor. Os sprints criam urgência artificial que não corresponde ao tipo de trabalho.
O risco no Kanban para o QA é a carga invisível. No Scrum, se o sprint está sobrecarregado, fica visível no planning. No Kanban, o QA pode silenciosamente se tornar o gargalo. Uma pilha de tickets acumula em "Pronto para QA" e ninguém nota até o desenvolvedor começar a perguntar por que sua feature ainda não foi lançada. Limites de WIP existem para prevenir isso. Se o seu board Kanban não tem limite em quantos tickets podem estar em Testes simultaneamente, você vai eventualmente se tornar o gargalo.
Uma regra prática: defina seu limite de WIP do QA em dois tickets de teste ativos. Três se você estiver rodando automação e testes manuais simultaneamente. Além disso, você está trocando de contexto constantemente e desacelerando em vez de acelerar.
QA em CI/CD: quando não há limites de sprint de forma alguma
Alguns times, especialmente os que rodam pipelines de CI/CD maduros, efetivamente dissolveram o sprint como limite de testes. O código é mergeado diariamente. Os pipelines fazem deploy para staging automaticamente. Os releases vão para produção em um cronograma ou continuamente.
Nesses ambientes, o trabalho do QA acontece em vários pontos simultaneamente.
No nível do pull request, testes automatizados rodam antes do código ser mergeado. Os QA engineers são donos dessas suites. Definem o que é testado no pipeline e lidam com falhas de testes que bloqueiam merges. Fazem triagem de se um teste falhando é uma regressão real ou um teste quebrado. Isso é trabalho em tempo integral em escala.
No nível do deploy para staging, uma suite de regressão mais ampla roda após cada deploy. O QA monitora essas execuções e investiga falhas. A disciplina necessária aqui é velocidade de triagem: um pipeline de staging falhando precisa de uma decisão humana em minutos, não horas, ou a fila de deploy acumula.
No nível de feature, novas features ainda exigem testes exploratórios e validação de aceitação. Em um time de CI/CD, o QA coordena diretamente com os desenvolvedores sobre o timing do deploy. "Faça deploy da feature X para staging até terça e eu vou validar antes da janela de release de quarta."
A mudança nesse modelo: o QA não é mais primariamente um tester manual que escreve alguma automação. O QA é primariamente um engenheiro de automação que faz validação manual para novas features. Se você está buscando posições em empresas de produto modernas, essa é a direção que a indústria vem seguindo desde 2022 e é o modelo operacional padrão em 2026.
Métricas que realmente dizem algo
A maioria das métricas de QA são reportadas porque são fáceis de coletar, não porque são significativas. Taxa de aprovação de testes em isolamento não diz nada. Se você escreveu 50 testes que só testam o fluxo principal, uma taxa de aprovação de 100% diz que o fluxo principal funciona. Não diz se a feature é realmente confiável.
Métricas que vale rastrear no contexto de Agile QA:
Taxa de escape de defeitos é o percentual de bugs encontrados em produção versus bugs encontrados antes da produção. Esse é o sinal central do QA. Se está aumentando sprint a sprint, algo no seu processo de teste está degradando. Se está diminuindo, algo está melhorando. Calcule por sprint e acompanhe a tendência por trimestres. Tempo de ciclo de teste é quanto tempo desde "pronto para QA" até o ticket fechado. Isso diz se o teste é o gargalo do sprint. Se o tempo médio de ciclo é três dias e seu sprint é dez dias, você tem um problema estrutural. Se o tempo de ciclo é seis horas em média, seu processo de teste é eficiente. Timing de descoberta de bugs é quando no sprint os bugs estão sendo encontrados. Se a maioria dos bugs aparece nos dias 9-10, o teste está sendo comprimido para o final. Se os bugs estão distribuídos ao longo do sprint, o teste paralelo está funcionando. Essa métrica exige que você registre a data de criação do bug, que a maioria dos times faz automaticamente pelo rastreador de issues. Taxa de testes flaky é o percentual das suas execuções de CI com pelo menos um teste que falha intermitentemente sem uma mudança de código causando a falha. Qualquer coisa acima de 5% é um sinal de que sua suite automatizada está se tornando não confiável. Suites não confiáveis são ignoradas. Suites ignoradas são inúteis.O que não sobreponderar: contagem bruta de casos de teste, percentual de cobertura de testes sem contexto, e contagem de bugs por sprint. Um QA engineer que escreve 200 casos de teste superficiais parece mais ativo do que um que escreve 50 profundos. O percentual de cobertura depende inteiramente do que está sendo contado. A contagem de bugs por sprint flutua com a complexidade da feature, não com a eficácia do QA.
Como aplicar isso já na segunda-feira
A lacuna entre ler sobre Agile QA e praticá-lo tende a ser hábitos específicos. Aqui estão cinco com maior impacto imediato.
Antes do seu próximo sprint começar, leia cada ticket no backlog para o próximo sprint e escreva três perguntas sobre cada um. Traga essas perguntas para o refinement ou jogue diretamente no ticket. Você vai encontrar critérios de aceitação faltando toda vez.
No seu próximo standup, se você estiver bloqueado ou parcialmente bloqueado, diga explicitamente. Não "estou trabalhando nos testes de login." Diga "estou trabalhando nos testes de login. Estou esperando o ambiente de dev ser redeploy com a nova config, esperado hoje à tarde." A especificidade permite que o Scrum Master aja.
Na sua próxima retro de sprint, venha com uma mudança de processo proposta. Formate como: "Notei X acontecendo três vezes neste sprint. Gostaria de tentar Y por um sprint e ver se melhora." Propostas pequenas e com prazo definido são adotadas. Reclamações vagas, não.
Adicione um campo de nota de teste ao seu próximo ticket antes de um desenvolvedor começar. Escreva duas frases: "Ponto de entrada de teste" e "Casos extremos conhecidos para verificar." Isso leva três minutos e elimina a maior parte das idas e vindas quando o ticket chega em testes.
Se seu time tem um pipeline de CI, olhe as últimas 10 execuções de testes e identifique qualquer teste que falhou intermitentemente. Registre como um ticket de teste flaky. Testes flaky são dívida técnica que corrói a confiança do time em automação mais rápido do que quase qualquer outra coisa.
O Agile feito corretamente torna o QA mais eficaz, não mais pressionado. As cerimônias existem para que os problemas apareçam cedo, quando são baratos de corrigir. A Definition of Done existe para que "pronto" signifique a mesma coisa para todos. As retrospectives existem para que o processo continue melhorando. Use tudo isso, e o ciclo do sprint se torna uma máquina que produz software confiável em vez de uma máquina de deadline que produz estresse.
→ Veja também: Roadmap de Automação QA 2026: Habilidades Essenciais para Conseguir Emprego | CI/CD para QA: GitHub Actions, Jenkins e GitLab Comparados | Agile e Scrum para QA Engineers: O que Você Realmente Precisa Saber
