Agile e Scrum para QA Engineers: O que Você Realmente Precisa Saber

No Waterfall, o QA revisava o trabalho finalizado no final de um ciclo de meses. No Scrum, o QA faz parte do time que constrói o produto, o que muda quando você se envolve e do que você é responsável. Os critérios de aceitação escritos pelo Product Owner viram seus casos de teste. O sprint planning é onde você identifica requisitos pouco claros antes do desenvolvimento começar. E "pronto" significa testes passando no CI, não apenas código mergeado.

Waterfall vs Agile: por que isso importa

A forma antiga de construir software era Waterfall: primeiro os requisitos, depois o design, depois o desenvolvimento, depois o QA, depois o release. Cada fase concluída antes da próxima começar. O QA acontecia no final, depois de tudo estar construído.

O problema: quando o QA encontrava um bug, ele estava lá há meses. Corrigi-lo significava voltar a decisões de arquitetura que ninguém lembrava direito. Os releases eram arriscados porque grandes lotes de mudanças não testadas saíam de uma vez.

O Agile é a resposta a isso. Em vez de um grande release depois de meses de trabalho, você constrói e entrega em pequenos incrementos, tipicamente ciclos de duas semanas. O QA faz parte de cada ciclo, não é uma fase depois dele.

Isso muda como é o trabalho de um QA engineer:

• Você testa features conforme são construídas, não depois que tudo está pronto
• Você está nas reuniões de planning, não apenas nas reuniões de testes
• Seu feedback influencia decisões de design antes do código ser escrito

O framework Scrum

Agile é um conjunto de valores e princípios. Scrum é o framework específico que a maioria dos times usa para implementá-lo. Quando alguém diz "trabalhamos com Agile", quase sempre significa Scrum.

Papéis

Product Owner (PO)
Dono do product backlog: a lista priorizada de tudo que o time vai construir. O PO decide o que é construído e em qual ordem, com base no valor para o negócio. Não é um papel técnico, mas precisa entender o que os usuários precisam e explicar isso claramente o suficiente para os desenvolvedores construírem.

Relação com o QA: O PO escreve os critérios de aceitação para cada item. Seu trabalho é transformar esses critérios em cenários de teste. Se os critérios forem vagos, peça esclarecimento antes do desenvolvimento começar, não depois.

Scrum Master
Facilita o processo. Conduz as cerimônias, remove bloqueadores, protege o time de interrupções externas. Não é um gestor; não atribui trabalho. É mais um coach de processo.

Relação com o QA: Se algo está bloqueando seus testes (o ambiente está fora, você não tem acesso a algo, mudanças de outro time estão quebrando seus testes), o Scrum Master ajuda a remover esse bloqueador.

Development Team
Geralmente 5 a 9 pessoas: desenvolvedores, QA engineers, às vezes UX. Cross-functional: o time coletivamente é responsável pela entrega de software funcionando.

No Scrum, o QA faz parte do development team, não é separado dele. Você não é "o departamento de QA revisando o trabalho dos desenvolvedores." Você é um membro do time com um conjunto de habilidades específico contribuindo para um objetivo compartilhado.

Artefatos

Product Backlog
A lista completa de features, correções de bugs e trabalho técnico que o time pode fazer. O PO é o dono e o prioriza. Os itens no topo são os mais importantes e os mais detalhados. Os itens no final são vagos e serão refinados quando se aproximarem do topo.

Sprint Backlog
O subconjunto do product backlog que o time se compromete a concluir em um sprint. Criado durante o Sprint Planning.

User Story
O formato padrão para itens do backlog:

Como [tipo de usuário],
quero [algum objetivo],
para que [algum motivo].

Exemplo:

Como usuário registrado,
quero filtrar itens por status,
para que eu possa ver rapidamente apenas os itens em andamento.

User stories descrevem a intenção, não a implementação. Como você constrói é decisão do time.

Critérios de Aceitação
As condições específicas que uma story deve atender para ser considerada pronta. Escritas pelo PO, validadas pelo QA.

Exemplo:

Dado que estou na página de itens
Quando seleciono "Em Andamento" no filtro de status
Então apenas itens com status "Em Andamento" são exibidos
E itens com outros status não estão visíveis
E a seleção do filtro persiste se eu atualizar a página

Esses se tornam seus casos de teste. Quando todos os critérios de aceitação passam, a story está pronta.

Definition of Done (DoD)
Um acordo do time sobre o que "pronto" significa. Tipicamente inclui: código escrito, código revisado, testes escritos, testes passando, deploy feito em staging, documentação atualizada.

A contribuição do QA para o DoD geralmente é: testes automatizados escritos e passando no CI, testes exploratórios manuais concluídos, nenhum bug crítico/alto aberto.

O ciclo do Sprint

Um sprint é um período de tempo fixo, geralmente duas semanas, em que o time constrói um conjunto de features. O ciclo se repete.

Sprint Planning (início do sprint)

O time seleciona itens do product backlog para o sprint. Os itens são divididos em tarefas, estimados e atribuídos.

Papel do QA no Sprint Planning:

• Fazer perguntas de esclarecimento sobre os critérios de aceitação
• Identificar cenários de teste que o PO não pensou
• Sinalizar itens que não têm detalhes suficientes para testar (devolver para refinamento)
• Estimar o esforço de teste. Se uma story leva 3 dias para desenvolver, quanto tempo levará para testar?

Daily Standup (todo dia, ~15 minutos)

Três perguntas por pessoa:

1. O que fiz ontem?
2. O que farei hoje?
3. Tenho algum bloqueador?

Curto, focado, sem resolver problemas. Se algo precisa de discussão mais profunda, acontece depois do standup com as pessoas relevantes.

Atualizações típicas do QA no standup:

• "Ontem terminei de testar a feature de filtro, encontrei um bug e registrei. Hoje estou testando o formulário do modal. Sem bloqueadores."
• "Ontem fui bloqueado porque o ambiente de staging estava fora. Hoje está de volta, continuando com os testes de upload. Sem bloqueadores agora."

Sprint Review (final do sprint)

O time demonstra o trabalho concluído para os stakeholders: o PO, gestores, às vezes clientes. Apenas o trabalho que atende à Definition of Done é demonstrado.

Papel do QA no Sprint Review:

• Confirmar o que está pronto e o que não está (parcialmente pronto não conta)
• Às vezes fazer demo dos cenários de teste, não apenas das features
• Sinalizar qualquer coisa que foi concluída mas tem limitações conhecidas

Sprint Retrospective (final do sprint)

O time reflete sobre o processo, não sobre o produto. O que funcionou bem? O que não funcionou? O que mudamos no próximo sprint?

Três categorias:

• Manter: coisas que funcionam bem
• Parar: coisas que não estão funcionando
• Começar: coisas que devemos tentar

É aqui que o QA frequentemente levanta problemas de processo. Os testes estão rodando muito devagar no CI, os desenvolvedores estão quebrando o ambiente de testes sem aviso, stories chegam ao sprint sem critérios de aceitação.

Entre o Planning e o Review: o sprint em si

Um fluxo típico do QA durante um sprint:

Dias 1-2: Escrever casos de teste com base nos critérios de aceitação para as stories que estão entrando em desenvolvimento. Revisar com o desenvolvedor para que ambos concordem sobre o que "pronto" significa.

Dias 3-8: Testar stories conforme são concluídas pelos desenvolvedores. Teste contínuo, não em lote no final. Quando uma story está pronta, é testada. Os bugs são corrigidos. É retestada.

Dia 9: Verificação de regressão. Garante que nada novo quebrou as features existentes.

Dia 10: Buffer para correções, testes exploratórios, preparação para o sprint review.

Testar em paralelo com o desenvolvimento, não depois, é a diferença central em relação ao Waterfall.

Ciclo de vida do bug no Scrum

Quando você encontra um bug:

1. Registre com passos de reprodução claros, comportamento esperado vs. real, severidade
2. Vincule à story em que foi encontrado
3. Discuta com o desenvolvedor. É um bug ou um mal-entendido dos requisitos?
4. Priorize com o PO. Bugs críticos bloqueiam o sprint; bugs menores podem ir para o backlog

Níveis de severidade de bug (escala comum):

• Crítico: bloqueia funcionalidade principal, perda de dados, problema de segurança. Corrigir agora.
• Alto: feature principal quebrada, sem alternativa. Corrigir neste sprint.
• Médio: feature parcialmente quebrada ou alternativa existe. Corrigir no próximo sprint.
• Baixo: problema cosmético, inconveniência menor. Vai para o backlog.

Termos que você vai ouvir em um time Scrum

Kanban: quando você vai encontrá-lo no lugar do Scrum

Alguns times usam Kanban em vez de Scrum. A diferença: sem sprints. O trabalho flui continuamente. Um board com colunas (A Fazer, Em Andamento, Em Teste, Pronto) rastreia o estado.

Papel do QA no Kanban: pegar stories de "Em Andamento" quando os desenvolvedores as marcam como prontas, mover para "Em Teste", e mover para "Pronto" quando passam. Sem cerimônias, sem ciclos fixos. Mais adequado para trabalho de manutenção e correções de bugs do que para desenvolvimento de features.

O que os entrevistadores realmente perguntam

"Fale sobre sua experiência com Agile."
Fale sobre quais cerimônias você participou, qual era seu papel em cada uma, e dê um exemplo específico. "Fazia parte de um time com sprints de 2 semanas. Participava dos daily standups, testava as stories conforme saíam do desenvolvimento e participava das retrospectives. Em um sprint levantei o problema de que as stories estavam chegando sem critérios de aceitação, e introduzimos uma etapa de refinamento que resolveu isso."

"Como você lida com os testes em um sprint curto?"
"Começo a escrever casos de teste durante o Sprint Planning, antes do desenvolvimento começar. Assim, quando uma story é marcada como pronta para teste, não estou começando do zero. Também testo as stories individualmente conforme são concluídas, não em lote no final."

"Qual é a diferença entre um bug e um requisito faltando?"
"Um bug é um comportamento que diverge dos critérios de aceitação documentados. Um requisito faltando é um comportamento não coberto por nenhum critério de aceitação. O app está funcionando conforme especificado, mas a especificação estava incompleta. Requisitos faltando voltam para o PO; bugs voltam para o desenvolvedor."

→ Veja também: CI/CD para QA: GitHub Actions, Jenkins e GitLab Comparados | Roadmap de Automação QA 2026: Habilidades Essenciais para Conseguir Emprego