Introduction
Qualidade = o produto/serviço entregue funciona, atende requisitos e satisfaz cliente.
Sem QA:
- Bugs chegam ao cliente (imagem ruim)
- Requisitos não foram entendidos
- Retrabalho pós-entrega
Com QA:
- Problemas identificados antes (economia)
- Requisitos validados
- Cliente satisfeito na entrega
4 Tipos de Testes
| Tipo | Quando | Quem | O que testa |
|---|---|---|---|
| Unit Testing | Durante dev | Dev | Código individual funciona |
| Integration Testing | Após componentes | Dev/QA | Componentes trabalham juntos |
| UAT | Antes de go-live | Cliente | Requisitos foram atendidos |
| Smoke Testing | Pós-go-live | QA | Sistema está vivo (básico) |
QA Plan Template
# QA PLAN - Projeto X
## Objetivo
Garantir 95%+ de requisitos funcionando sem bugs críticos.
## Escopo de Testes
- Unit tests (dev coverage maior que 80%)
- Integration tests (conecta componentes)
- UAT (cliente valida)
- Smoke test (pós-go-live)
## Ambientes
- Dev (developer)
- Test (QA)
- Staging (como produção, antes de go-live)
- Prod (real, após aprovação)Critérios de Aceitação
Exemplo para feature “Login com Google”:
Given: Usuário está na página de login
When: Clica em "Login com Google"
Then: Abre janela de autenticação Google
Given: Autenticação bem-sucedida
When: Usuário autoriza acesso
Then: Redireciona para dashboard, usuário está logado
And: Email do Google é salvo no perfil
And: Performance menor que 1 segundoDefect Severity
| Severity | Descrição | Action |
|---|---|---|
| Crítico | Sistema inteiro quebrado, sem workaround | Bloqueia release |
| Alto | Feature principal não funciona | Deve ser fixado antes de release |
| Médio | Feature funciona mas com problema menor | Pode ir para release, fix em v2 |
| Baixo | Cosmético (typo, layout) | Aceitar (não é funcional) |
Processo de QA Completo
Fase 1: Planejamento (Início do projeto)
- Definir critérios de aceitação para cada feature
- Criar QA Plan
- Definir ambientes (dev, test, staging, prod)
- Alocar QA/testers
Fase 2: Execução (Durante desenvolvimento)
- Devs fazem unit tests
- QA faz integration tests
- Bugs são logados em sistema (Jira, etc.)
- Bugs críticos/altos bloqueiam progresso
Fase 3: UAT (Antes do go-live)
- Cliente testa sistema em staging
- Valida requisitos (atende ou não?)
- Sign-off formal (aceito)
Fase 4: Go-Live (Pós-entrega)
- Smoke test (sistema está vivo?)
- Monitoramento inicial (erros, performance)
- Suporte pós-go-live (bugs encontrados)
Defect Tracker Template
| ID | Título | Severity | Status | Owner | ETA |
|---|---|---|---|---|---|
| D001 | Login não redireciona | Crítico | In Progress | Dev A | 2 dias |
| D002 | Botão não alinha mobile | Baixo | Backlog | Dev B | v2 |
| D003 | Performance lenta em busca | Alto | In Review | Dev C | 1 dia |
Erros Comuns
- QA no final (encontra muitos bugs, não dá tempo corrigir) – Solução: QA contínuo (durante todo desenvolvimento)
- Critérios de aceitação vagos (funciona bem) – Solução: Critérios específicos (Given/When/Then)
- Sem UAT (cliente surpreendido no go-live) – Solução: UAT formal (cliente valida antes)
Checklist de Qualidade
- QA Plan criado
- Critérios de aceitação definidos para cada feature
- Ambientes configurados (dev, test, staging, prod)
- Unit tests coverage maior que 80%
- Integration tests passando
- UAT agendado e executado
- Sign-off do cliente
- Smoke test pós-go-live
- Defect tracker atualizado
Final CTA
Qualidade é investimento, não custo. Agende uma sessão para estruturar QA na sua organização ou baixe o template de QA Plan.
Próximas leituras:
Guia Definitivo de Gestão de Projetos | Gestão de Riscos
Leia Também
