"O usuário pode fazer login" não é um critério de aceitação testável. "O usuário com credenciais válidas é redirecionado para /dashboard em até 3 segundos; o usuário com credenciais inválidas vê 'Email ou senha inválidos'" é. Identificar essa lacuna na fase de requisitos custa uma conversa; identificá-la após o desenvolvimento custa uma sprint.
As fases
1. Planejamento
O projeto está sendo escopo. Os requisitos estão sendo escritos. Orçamentos e cronogramas estão sendo definidos.
O que o QA faz aqui: na maioria dos times, quase nada. Isso é um problema. A maior contribuição do QA no planejamento é identificar requisitos de testabilidade cedo: a feature precisa de logging? Acesso ao ambiente de teste? Capacidade de resetar estado? Levantar isso no planejamento custa horas. Levantar no desenvolvimento custa dias. O que o QA deveria fazer: participar das reuniões de planejamento. Perguntar "como vamos saber que isso funciona?" para cada feature proposta. Sinalizar requisitos que são vagos ou não testáveis.2. Análise de requisitos
Os requisitos estão sendo refinados e especificados. As user stories são escritas. Os critérios de aceitação são definidos.
O que o QA faz aqui: revisar critérios de aceitação quanto à completude. "O usuário pode fazer login" não é testável. "O usuário com credenciais válidas é redirecionado para /dashboard em até 3 segundos; o usuário com credenciais inválidas vê o erro 'Email ou senha inválidos'" é testável. O que o QA deveria fazer: escrever casos de teste enquanto os requisitos ainda estão sendo finalizados, não depois. Levantar casos de borda faltando. Questionar linguagem vaga. É aqui que acontece o trabalho de QA mais valioso.3. Design
A arquitetura técnica está sendo projetada. Schema do banco de dados. Contratos de API. Estrutura de componentes. Topologia de deploy.
O que o QA faz aqui: revisar o design quanto à testabilidade. O sistema pode ser testado em isolamento? As APIs são testáveis ou tudo passa pela UI? O sistema tem hooks de logging e observabilidade? Tem como injetar dados de teste? O que o QA deveria fazer: levantar preocupações de testabilidade durante a revisão de design. "Essa feature não tem API: só pode ser testada pela UI, o que significa que todos os testes serão lentos e frágeis. Podemos adicionar um endpoint de API ou pelo menos uma forma de seed do estado de teste?"4. Implementação (desenvolvimento)
Os devs estão escrevendo código. As features estão sendo construídas.
O que o QA faz aqui: escrever casos de teste em paralelo. Configurar ambientes de teste. Escrever testes automatizados para features conforme ficam prontas. Reportar bugs conforme são encontrados. O que o QA deveria fazer: testar features incrementalmente, não tudo de uma vez no final. Trabalhar com os devs para definir o que significa "pronto para QA". Considerar pair testing para features complexas.5. Testes
As features estão completas e prontas para verificação sistemática.
O que o QA faz aqui: executar casos de teste, rodar automação, fazer testes exploratórios, verificar correções de bugs, fazer testes de regressão em áreas não alteradas. O que o QA deveria fazer: manter um registro claro de defeitos. Comunicar riscos com clareza ("5 bugs de alta severidade abertos, recomendamos não fazer release até pelo menos 3 serem corrigidos"). Não apenas encontrar bugs: ajudar a priorizar e comunicar o impacto deles.6. Deploy
O produto é enviado para os usuários.
O que o QA faz aqui: smoke testing em produção ou staging após o deploy. Monitoramento de erros em produção. Validação rápida do caminho crítico. O que o QA deveria fazer: ter um checklist de validação de deploy. Saber quais 5 a 10 testes rodam imediatamente após cada deploy para confirmar que o sistema está saudável. Monitorar ferramentas de rastreamento de erros nas horas seguintes ao release.7. Manutenção
O produto está no ar e sendo mantido. Correções de bugs, pequenas melhorias, trabalho de performance.
O que o QA faz aqui: testes de regressão para cada mudança, por menor que seja. Manter a suite de testes conforme o produto evolui. O que o QA deveria fazer: atualizar testes quando features mudam. Aposentar testes de features removidas. Não deixar a suite de testes virar um museu de features que ninguém usa mais.Modelos de SDLC
Waterfall
Todas as fases rodam sequencialmente. Os requisitos são travados antes de o design começar. O design é travado antes de o desenvolvimento começar. Os testes acontecem apenas após o desenvolvimento estar completo.
QA no Waterfall: o QA é uma fase no final. Isso produz os defeitos mais caros: bugs encontrados tarde são caros de corrigir. Quase nenhum time de software moderno usa Waterfall puro.Agile (Scrum, Kanban)
O trabalho é feito em iterações curtas (sprints). Cada sprint inclui planejamento, desenvolvimento e testes. As features são entregues incrementalmente.
QA no Agile: os testes acontecem dentro da sprint, não depois dela. Engenheiros de QA fazem parte do time cross-funcional. É o modelo dominante em 2026 para times de produto.DevOps/Entrega Contínua
Integração contínua e deploy contínuo. Mudanças de código disparam testes automatizados e podem ir para produção várias vezes por dia.
QA no DevOps: automação é essencial: você não consegue verificar manualmente cada deploy. Engenheiros de QA constroem e mantêm o pipeline de automação. O foco muda de execução manual de testes para estratégia de testes e qualidade da automação.Por que engenheiros de QA precisam saber isso
Saber onde você está no SDLC diz que tipo de trabalho de QA é mais valioso agora.
No planejamento: revisão de requisitos. No desenvolvimento: escrita antecipada de casos de teste. Após o deploy: smoke testing. Um engenheiro de QA que só sabe executar casos de teste na fase de testes é útil em apenas uma das sete fases. Um que entende o SDLC completo consegue agregar valor em cada etapa.
É também por isso que o "shift-left" se tornou a filosofia dominante de QA: mover os testes para mais cedo no SDLC, onde é mais barato e tem mais impacto.
→ Veja também: Testes Shift-Left: O que Significa e Como Praticar | Testes Ágeis em 2026: Sprints, Cerimônias e o Papel do QA | O que é Teste Manual? O Guia Completo para 2026
