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

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.

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.

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

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.

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

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.

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.

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.

• 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.

• "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.

• 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:

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

• 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

| Termo | Significado |

|-------|-------------|

| Backlog refinement | Reunião regular para revisar e detalhar itens futuros do backlog |

| Velocity | Quantos story points um time conclui por sprint em média |

| Story points | Medida relativa de esforço (não horas). 1, 2, 3, 5, 8, 13. |

| Epic | Uma feature grande dividida em várias stories |

| Spike | Uma tarefa de investigação com tempo limitado (pesquisa, prova de conceito) |

| Dívida técnica | Trabalho adiado para manter a velocity, que eventualmente precisa ser pago |

| Bloqueador | Algo que impede o progresso, precisa de atenção imediata |

| Limite de WIP | Número máximo de coisas em andamento de uma vez (previne troca de contexto) |

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 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."

"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."

"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."