Skip to main content

Registro de Evidências de Teste

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:

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

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

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

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

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

Back to top