Análise de Causa Raiz

1. Objetivo desta página

Esta página tem como objetivo ensinar, de forma profunda, prática e estruturada, como o QA deve realizar uma Análise de Causa Raiz (Root Cause Analysis – RCA) a partir dos resultados de teste, bugs encontrados e dificuldades enfrentadas durante a execução de uma tarefa.

A Análise de Causa Raiz não busca apontar culpados. Ela busca entender por que o problema aconteceu, quais fatores contribuíram para isso e como evitar que o mesmo tipo de problema volte a ocorrer em futuras tarefas.

Aqui o QA atua como analista de processo, conectando falhas técnicas, falhas de entendimento, falhas de fluxo e falhas de comunicação.

2. O que é Análise de Causa Raiz

Análise de Causa Raiz é o processo de investigação sistemática que visa identificar:

A origem real de um problema

Os fatores que contribuíram para sua ocorrência

As condições que permitiram que ele passasse despercebido

Diferente da análise superficial, que responde o que deu errado, a RCA responde:

Por que deu errado?

Por que não foi detectado antes?

O que no processo permitiu esse erro?

Sem RCA, os mesmos problemas tendem a se repetir.

3. Quando aplicar a Análise de Causa Raiz

A Análise de Causa Raiz deve ser aplicada sempre que:

Bugs relevantes forem encontrados

Um padrão de falhas for identificado

Um bug crítico escapar para fases avançadas

A execução de testes apresentar baixa eficiência

Uma entrega gerar retrabalho excessivo

Ela pode ser aplicada:

Ao final de uma task

Ao final de um ciclo de testes

Após um incidente relevante

4. Diferença entre sintoma, causa e causa raiz

Um erro comum é confundir sintoma com causa.

Conceito	Definição	Exemplo
Sintoma	O que foi observado	Relatório gerado incorretamente
Causa	O que provocou o sintoma	Regra não implementada
Causa raiz	Por que a causa existiu	Requisito incompleto

A RCA só termina quando se chega à causa raiz.

5. Visão geral do processo de Análise de Causa Raiz

Fluxo macro:

[Problema Identificado]
        |
        v
[Coleta de Informações]
        |
        v
[Identificação das Causas]
        |
        v
[Chegada à Causa Raiz]
        |
        v
[Definição de Ações Preventivas]

Cada etapa é essencial e não deve ser pulada.

6. Passo 1 – Identificação clara do problema

O primeiro passo é descrever o problema de forma objetiva.

O QA deve responder:

O que aconteceu?

Onde aconteceu?

Quando aconteceu?

Qual foi o impacto?

Exemplo:

Durante a execução dos testes da task, foram encontrados vários bugs relacionados à exibição incorreta de dados em relatórios.

Evite descrições genéricas ou emocionais.

7. Passo 2 – Coleta de informações

Nesta etapa, o QA reúne todos os dados relevantes:

Bugs registrados

Evidências

Cenários afetados

Histórico da task

Ajustes realizados

Tabela de apoio:

Fonte	Informação coletada
Bugs	Tipos e severidades
Evidências	Prints e vídeos
Cenários	Onde falhou
Histórico	Mudanças e correções

Sem dados, não existe análise confiável.

8. Passo 3 – Identificação das causas

Aqui o QA começa a responder por que o problema ocorreu.

As causas podem estar em diferentes dimensões:

Dimensão	Exemplos
Requisitos	Regra incompleta ou ambígua
Técnica	Implementação incorreta
Processo	Falta de validação prévia
Comunicação	Expectativa não alinhada
Teste	Cobertura insuficiente

Um mesmo problema pode ter mais de uma causa.

9. Técnica dos 5 Porquês

Uma técnica simples e eficaz é a dos 5 Porquês, que consiste em perguntar “por quê?” sucessivamente até chegar à causa raiz.

Exemplo prático:

Por que o relatório exibiu cursos inativos?
→ Porque a regra não foi aplicada no relatório.

Por que a regra não foi aplicada?
→ Porque o desenvolvimento considerou apenas a tela.

Por que considerou apenas a tela?
→ Porque o requisito não explicitava o comportamento no relatório.

Por que o requisito não explicitava?
→ Porque não houve validação completa do documento.

Por que não houve validação completa?
→ Porque o fluxo de revisão não envolveu QA.

Causa raiz identificada: falha no processo de revisão de requisito.

10. Passo 4 – Confirmação da causa raiz

Antes de concluir, o QA deve validar se a causa raiz realmente explica o problema.

Perguntas de validação:

Se essa causa fosse eliminada, o problema não ocorreria?

Essa causa explica problemas semelhantes?

Se a resposta for não, a análise deve continuar.

11. Passo 5 – Definição de ações preventivas

A RCA só gera valor quando resulta em ações concretas.

As ações devem ser:

Práticas

Executáveis

Preventivas

Tabela exemplo:

Causa raiz	Ação preventiva
Requisito incompleto	Revisão técnica com QA
Falha de cobertura	Ampliar cenários
Regressão recorrente	Criar teste regressivo

12. Exemplo completo de Análise de Causa Raiz

Problema identificado

Múltiplos bugs relacionados à exibição de dados em relatórios.

Causas identificadas

Requisitos pouco detalhados

Falta de validação exploratória inicial

Causa raiz

Ausência de revisão estruturada do requisito com foco em comportamento e exceções.

Ações definidas

Criar checklist de revisão de requisitos

Incluir QA na validação inicial

Ampliar testes exploratórios para relatórios

13. Uso da RCA como aprendizado contínuo

A Análise de Causa Raiz deve gerar aprendizado organizacional:

Ajustar processos

Melhorar planejamento

Reduzir reincidência de erros

Ela deve ser documentada e consultada em tarefas futuras.

14. Integração com a Análise de Resultados

A RCA complementa a Análise de Resultados de Teste:

Resultados mostram o que aconteceu

RCA explica por que aconteceu

Juntas, elas permitem decisões mais maduras.

15. Conclusão

A Análise de Causa Raiz é uma das práticas mais importantes para a maturidade do QA.

Ela transforma falhas em aprendizado, erros em melhoria e testes em evolução de processo.

Na DBSeller, realizar RCA é sinal de qualidade, responsabilidade e visão de longo prazo.