guide root cause analysis steps
Este tutorial explica o que é análise de causa raiz e diferentes técnicas de análise de causa raiz, como análise de espinha de peixe e técnica dos 5 porquês:
RCA (análise de causa raiz) é um processo estruturado e eficaz para encontrar a causa raiz dos problemas em uma equipe de projeto de software. Se realizado de forma sistemática, pode melhorar o desempenho e a qualidade das entregas e dos processos, não apenas no nível da equipe, mas também em toda a organização.
Este tutorial o ajudará a definir e agilizar o processo de Análise de Causa Raiz em sua equipe ou organização.
Este tutorial é destinado a gerentes de entrega, Scrum Masters, gerentes de projeto, gerentes de qualidade, equipe de desenvolvimento, equipe de teste, equipe de gerenciamento de informações, equipe de qualidade, equipe de suporte, etc. para compreender os fundamentos da análise de causa raiz e fornece modelos e exemplos dela .
O que você aprenderá:
- O que é análise de causa raiz?
- Processo de análise de causa raiz
- Técnicas de análise de causa raiz
- Fatores que causam defeitos
- Conclusão
O que é análise de causa raiz?
RCA (análise de causa raiz) é um mecanismo de análise de Defeitos, para identificar sua causa. Nós fazemos um brainstorming, lemos e analisamos o defeito para identificar se o defeito foi devido a “ falha de teste ',' falta de desenvolvimento ”Ou era um“ requisito ou falta de projetos ”.
Quando o RCA é feito com precisão, ajuda a evitar defeitos nas versões ou fases posteriores. Se descobrirmos, que um defeito foi devido a falta de design , podemos revisar os documentos de design e tomar as medidas adequadas. Da mesma forma, se descobrirmos que um defeito foi devido a falha de teste , podemos revisar nossos casos de teste ou métricas e atualizá-los de acordo.
O RCA não deve se limitar apenas a testar os defeitos. Podemos fazer RCA em defeitos de produção também. Com base na decisão da RCA, podemos aprimorar nosso Bancada de teste e incluir esses tíquetes de produção como casos de teste de regressão. Isso garantirá que o defeito ou tipos semelhantes de defeitos não se repitam.
Processo de análise de causa raiz
O RCA não é usado apenas para defeitos relatados de um local do cliente, mas também para defeitos UAT, defeitos de Teste de Unidade, Negócios e problemas de nível de processo operacional, problemas do dia-a-dia, etc. Portanto, é usado em vários setores, como Setor de software, manufatura, saúde, setor bancário, etc.
Conduzir a análise da causa raiz é semelhante ao trabalho do médico que trata um paciente. O médico primeiro entenderá os sintomas. Em seguida, ele fará exames laboratoriais para analisar a causa raiz da doença.
Se a causa raiz da doença ainda for desconhecida, o médico irá encaminhá-lo para testes de varredura para entender melhor. Ele continuará o diagnóstico e o estudo até que ele se limite à causa raiz da doença do paciente. A mesma lógica se aplica à análise de causa raiz realizada em qualquer setor.
Assim, o RCA visa encontrar a causa raiz e não tratar o sintoma, seguindo um conjunto específico de etapas e ferramentas associadas. É diferente da análise de defeitos, solução de problemas e outros métodos de solução de problemas, pois esses métodos tentam encontrar a solução para o problema específico, mas o RCA tenta encontrar a causa subjacente.
Origem do nome Análise de causa raiz:
(imagem fonte )
Folhas, tronco e raízes são as partes mais importantes de uma árvore. Folhas (sintoma) e tronco (problema) que estão acima do solo são visíveis, mas raízes (causa) que estão sob o solo não são visíveis e as raízes crescem mais fundo e podem se espalhar mais do que esperamos. Conseqüentemente, o processo de ir até o fundo do problema é chamado de Análise da Causa Raiz.
Vantagens da análise de causa raiz
A seguir estão alguns dos benefícios que você obterá:
- Evite a recorrência do mesmo problema no futuro.
- Eventualmente, reduza o número de defeitos relatados ao longo do tempo.
- Reduz os custos de desenvolvimento e economiza tempo.
- Melhore o processo de desenvolvimento de software e, assim, auxilie na entrega rápida ao mercado.
- Melhora a satisfação do cliente.
- Aumentar a produtividade.
- Encontre problemas ocultos no sistema.
- Auxilia na melhoria contínua.
Tipos de causas básicas
# 1) Causa humana: Erro de fabricação humana.
Exemplos:
- Menos qualificado.
- Instruções não seguidas devidamente.
- Executou uma operação desnecessária.
# 2) Causa organizacional: Um processo que as pessoas usam para tomar decisões inadequadas.
Exemplos:
- Instruções vagas foram dadas do líder da equipe aos membros da equipe.
- Escolher a pessoa errada para uma tarefa.
- Não existem ferramentas de monitoramento para avaliar a qualidade.
# 3) Causa física: Qualquer item físico falhou de alguma forma.
Exemplos:
- O computador continua reiniciando.
- O servidor não está inicializando.
- Ruídos estranhos ou altos no sistema.
Etapas para fazer a análise da causa raiz
Uma abordagem estruturada e lógica é necessária para uma análise de causa raiz eficaz. Portanto, é necessário seguir uma série de etapas.
# 1) Formar Equipe RCA
Cada equipe deve ter um dedicado Gerente de Análise de Causa Raiz (Gerente RCA) que coletará os detalhes da equipe de suporte e iniciará o processo inicial para RCA. Ele coordenará e alocará recursos que precisam comparecer às reuniões da RCA, dependendo do problema declarado.
As equipes que participam da reunião devem ter pessoal de cada equipe (Requisito, Projeto, Teste, Documentação, Qualidade, Suporte e Manutenção) que esteja mais familiarizado com o problema. A equipe também deve ter pessoas que estejam diretamente ligadas ao defeito. Por exemplo, o engenheiro de suporte que deu uma solução imediata para o cliente.
Compartilhe os detalhes do problema com a equipe antes de participar da reunião para que eles possam fazer uma análise inicial e vir preparados. Os membros da equipe também coletam informações relacionadas ao defeito. Dependendo do relatório de incidente, cada equipe rastreará o que deu errado com este cenário em suas respectivas fases. Estar preparado aumentará a eficiência da próxima discussão.
# 2) Defina o problema
Colete os detalhes do problema, como relatórios de incidentes, evidências do problema (captura de tela, registros, relatórios, etc.) e, em seguida, estude / analise o problema fazendo as perguntas abaixo:
- Qual é o problema?
- Qual é a sequência de eventos que levou ao problema?
- Quais sistemas estavam envolvidos?
- Há quanto tempo o problema existe?
- Qual é o impacto do problema?
- Quem está envolvido e determina quem deve ser entrevistado?
Use regras ‘SMART’ para definir o seu problema:
- S PECÍFICO
- M FACILMENTE
- PARA ORIENTADO POR CÇÃO
- R ELEVANTE
- T NAME-BOUND
# 3) Identificar a causa raiz
Conduza o DEBATE sessão dentro da equipe RCA formada para identificar as causas. Use o Diagrama espinha de peixe ou 5 Por que analisar método ou ambos para chegar à (s) causa (s).
O gerente da RCA deve moderar a reunião e definir as regras para a sessão de Brainstorming. Por exemplo, as regras podem ser:
- Criticar / culpar os outros não deve ser permitido.
- Não julgue as idéias dos outros. Nenhuma ideia é ruim, eles encorajam ideias selvagens.
- Baseie-se nas ideias dos outros. Pense em como você pode desenvolver as ideias dos outros e torná-las melhores.
- Dê a cada participante o tempo devido para compartilhar suas opiniões.
- Incentive o pensamento fora da caixa.
- Mantenha o foco.
Todas as idéias devem ser registradas. O gerente de RCA deve designar um membro para registrar as atas da reunião e atualizar os modelos de RCA.
# 4) Implementar ação corretiva de causa raiz (RCCA)
A ação de correção envolve corrigir a solução, identificando a causa raiz real. Para facilitar isso, um gerente de entrega deve estar presente, que pode decidir em quais versões a correção deve ser implementada e qual deve ser a data de entrega.
O RCCA deve ser implementado de forma que essa causa raiz não ocorra novamente no futuro. A correção fornecida pela equipe de suporte será temporária para o site do cliente onde o problema foi relatado. Quando essa correção é incorporada a uma versão contínua, faça uma análise de impacto adequada para garantir que nenhum recurso existente seja quebrado.
Dê as etapas para validar a correção e monitorar a solução implementada para verificar se a solução é eficaz.
# 5) Implementar ação preventiva de causa raiz (RCPA)
A equipe precisa apresentar um plano de como um problema semelhante pode ser evitado no futuro. Por exemplo, Atualizar o Manual de Instruções, melhorar o conjunto de habilidades, atualizar a lista de verificação de avaliação da equipe, etc. Siga os documentos adequados de ações preventivas e monitore se a equipe está aderindo às ações preventivas tomadas.
Por favor se refira a isto papel de pesquisa em 'Análise e prevenção de defeitos para melhoria da qualidade do processo de software' publicado no Jornal Internacional de Engenharia de Software e Aplicações para ter uma ideia dos tipos de defeitos reportados em cada fase do software e sugestões de ações preventivas para os mesmos.
As informações obtidas com a RCA podem servir de entrada para Modo de falha e análise de efeito (FMEA ) para identificar pontos onde a solução pode falhar.
Implemento Análise de Pareto com as causas identificadas durante o RCA ao longo de um período, digamos semestral ou trimestral, o que ajudará a identificar as principais causas que estão contribuindo para os defeitos e focar em ações preventivas para eles.
Técnicas de análise de causa raiz
# 1) Análise de espinha de peixe
O diagrama em espinha de peixe é uma ferramenta de análise de causa raiz visual para identificar as possíveis causas dos problemas identificados e, portanto, também é chamado de diagrama de causa e efeito. Ele permite que você descubra a verdadeira causa raiz do problema, em vez de solucionar seu sintoma.
Também é chamado de Diagrama de Ishikawa, pois foi criado por Dr. Kaoru Ishikawa (um estatístico de controle de qualidade japonês). Também é conhecido como diagrama de espinha de peixe ou Fishikawa.
A análise de espinha de peixe é usada na fase de análise de DMAIC de seis sigma abordagem para resolução de problemas. É um dos 7 ferramentas básicas de controle de qualidade .
Etapas para criar um diagrama espinha de peixe:
O diagrama de espinha de peixe se assemelha ao esqueleto de um peixe com o problema de formar a cabeça do peixe e causar a formação da espinha e dos ossos do peixe.
Siga as etapas abaixo para criar um diagrama de espinha de peixe:
- Escreva o problema no cabeça do peixe .
- Identifique o categoria de causas e escrever em fim de cada osso (causa categoria 1, causa categoria 2 ... causa categoria N)
- Identifique o causas primárias sob cada categoria e marcá-la como causa primária 1, causa primária 2, causa primária N.
- Estenda as causas para secundário, terciário e mais níveis conforme aplicável.
Um exemplo de como um diagrama de espinha de peixe é aplicado a um defeito de software (veja abaixo).
Existem várias ferramentas gratuitas e pagas disponíveis para criar um diagrama em espinha de peixe. O diagrama Fishbone neste tutorial foi criado usando ‘ Creately ’ ferramenta online . Mais detalhes sobre os modelos e ferramentas de espinha de peixe serão explicados em nosso próximo tutorial.
# 2) A técnica dos 5 porquês
5 Por que a técnica foi desenvolvida por Sakichi Toyoda e foi usado na Toyota em sua indústria de manufatura. Essa técnica se refere a uma série de perguntas em que cada resposta é respondida com uma pergunta Por quê. Pode estar relacionado a como uma criança fará perguntas aos adultos. Com base nas respostas que os adultos dão, eles farão perguntas do tipo 'Por que' repetidas vezes até ficarem satisfeitos.
5 Por que a técnica é usada isoladamente ou como parte da análise de espinha de peixe para detalhar a causa raiz do problema. O número de etapas não está limitado a 5. Pode ser inferior ou superior a 5 até que o diagnóstico do problema seja alcançado. 5 Porquês são uma técnica relativamente mais simples e uma maneira mais rápida de chegar às causas básicas. Ele facilita o diagnóstico rápido para descartar os sintomas e chegar à causa raiz.
O sucesso da técnica depende do conhecimento da pessoa. Pode haver respostas diferentes para a mesma pergunta por quê. Portanto, é importante selecionar a direção e o foco corretos na reunião.
Etapas para criar o diagrama de 5 porquês
Comece a discussão de brainstorming definindo o problema. Em seguida, siga com o subsequente Por que e suas respostas.
Um exemplo de como o diagrama de 5 porquês é aplicado a um defeito de software:
5 Por que o modelo e as imagens são desenhados usando o software online Creately.
Fatores que causam defeitos
Existem muitos fatores que fazem com que os Defeitos ocorram:
- Requisitos pouco claros / ausentes / incorretos
- Design Incorreto
- Codificação Incorreta
- Teste Insuficiente
- Problemas de ambiente (hardware, software ou configurações)
Esses fatores devem ser sempre mantidos em mente ao executar o processo de RCA.
O RCA começa e prossegue com o brainstorming sobre o defeito. A única pergunta que nos perguntamos ao fazer RCA é 'POR QUÊ?' e o que?' Podemos nos aprofundar em cada fase do ciclo de vida para rastrear onde o defeito persiste.
Vamos começar com o “POR QUÊ?” perguntas, (a lista não é limitada). Você pode começar da fase externa e passar para a fase interna do SDLC.
Perguntas e respostas da entrevista do sql server com 5 anos de experiência
- “POR QUE” o Defeito não foi detectado durante o Teste de sanidade em produção?
- “POR QUE” o defeito não foi detectado durante o teste?
- “POR QUE” o Defeito não foi detectado durante a revisão do caso de teste?
- “POR QUE” o defeito não foi detectado Teste de Unidade ?
- “POR QUE” o Defeito não foi detectado durante a “Revisão do Projeto”?
- “POR QUE” o Defeito não foi detectado durante a fase de Requisito?
A resposta a esta pergunta fornecerá a fase exata em que o defeito existe. Agora, depois de identificar a fase e o motivo, vem a parte “O QUE”.
“O QUE você vai fazer para evitar isso no futuro?
A resposta a esta pergunta “O QUE”, se implementada e tratada, evitará que o mesmo defeito ou tipo de defeito apareça novamente. Tomar as medidas adequadas para melhorar o processo identificado de forma que o defeito ou a razão do defeito não se repita
Com base nos resultados do RCA, você pode determinar qual fase possui áreas problemáticas.
Por exemplo, se você determinar que a maior parte do RCA dos defeitos é devido a requisito falta , então você pode melhorar a fase de coleta / compreensão de requisitos introduzindo mais revisões ou sessões de orientação.
Da mesma forma, se você achar que a maioria dos defeitos são devidos a falha de teste , você precisa melhorar o processo de teste. Você pode introduzir métricas como Métricas de rastreabilidade de requisitos , Testar Métricas de Cobertura ou pode manter uma verificação do processo de revisão ou qualquer outra etapa que você sinta que pode melhorar a eficiência do teste.
Conclusão
É responsabilidade de toda a equipe sentar e analisar os defeitos e contribuir para a melhoria do produto e do processo.
Neste tutorial, você tem um conhecimento básico de RCA, etapas a serem seguidas para fazer uma RCA eficiente e diferentes ferramentas a serem usadas, como análise de espinha de peixe e 5 Why Technique. Nos próximos tutoriais, haverá cobertura sobre diferentes modelos de RCA, exemplos e casos de uso sobre como implementá-lo.
Leitura recomendada
- Análise e relatórios de resultados de teste - Teste de carga com LoadRunner
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Teste suas capacidades de análise e poder de pensamento - Exercícios de teste de software (parte 2)
- O que é técnica de teste baseada em defeitos?
- O que é análise de valor limite e particionamento de equivalência?
- Download do e-book do Testing Primer
- O que é ciclo de vida de defeito / bug em teste de software? Tutorial de ciclo de vida de defeitos
- Teste de carga com tutoriais HP LoadRunner