Glossário · Fundamentos de testes
Teste baseado em risco
Em inglês: Risk-based testing
Também chamado de: testes baseados em risco, estratégia de testes baseada em risco, RBT
Definição
Abordagem que prioriza o esforço de teste pelo risco (probabilidade de falha vezes impacto), para que as áreas mais arriscadas sejam testadas primeiro e mais a fundo.
O teste baseado em risco (risk-based testing) aceita que nunca é possível testar tudo e decide onde investir tempo com base no risco. Cada funcionalidade ou área recebe uma nota de probabilidade de falha (complexidade, volume de mudanças, defeitos anteriores, tecnologia nova) e de impacto caso falhe (dinheiro, segurança física, dados, exposição jurídica, número de usuários). Áreas de alto risco recebem testes mais cedo, mais profundos e mais variados; áreas de baixo risco recebem verificações mais leves.
Exemplo
Um release mexe em quatro áreas. Dê uma nota de 1 a 5 para cada uma:
| Área | Probabilidade | Impacto | Risco (P x I) | Profundidade do teste |
|---|---|---|---|---|
| Migração do provedor de pagamentos | 5 | 5 | 25 | Funcional completo, negativo, integração, performance, exploratório |
| Novas regras fiscais para uma região | 4 | 4 | 16 | Testes de valor-limite e tabela de decisão, regressão dos totais |
| Página de perfil redesenhada | 3 | 2 | 6 | Fluxos principais mais uma verificação visual |
| Atualização de link no rodapé | 1 | 1 | 1 | Verificação rápida |
Se o prazo for reduzido em dois dias, você já sabe o que cortar: profundidade nas linhas de baixo risco, e não na migração de pagamentos.
Por que isso importa
Todo plano de testes faz escolhas. O teste baseado em risco as torna explícitas e acordadas. Ele também dá uma forma clara de reportar o status: “todas as áreas de alto risco testadas, dois riscos médios parcialmente testados, estas lacunas conhecidas permanecem” é muito mais útil para uma decisão de release do que “83% dos casos de teste executados”.
Erros comuns
- Pontuar sozinho. Product owners conhecem o impacto, desenvolvedores conhecem a probabilidade. Avaliem os riscos juntos.
- Pontuar uma única vez. Os riscos mudam conforme o código entra e os bugs aparecem. Um módulo que continua gerando defeitos deve subir na lista.
- Ignorar completamente as áreas de baixo risco. Risco menor significa teste mais leve, não teste nenhum. A regressão automatizada normalmente cobre essa base.
- Confundir com a severidade do bug. A severidade classifica um defeito já encontrado. O risco é uma estimativa feita antes de testar, usada para decidir onde olhar.