guide root cause analysis steps
Este tutorial explica qué es el análisis de causa raíz y las diferentes técnicas de análisis de causa raíz, como el análisis de espina de pescado y la técnica de los 5 por qué:
RCA (análisis de causa raíz) es un proceso estructurado y eficaz para encontrar la causa raíz de los problemas en un equipo de proyecto de software. Si se realiza de forma sistemática, puede mejorar el rendimiento y la calidad de los entregables y los procesos, no solo a nivel de equipo sino también en toda la organización.
Este tutorial le ayudará a definir y optimizar el proceso de análisis de causa raíz en su equipo u organización.
Este tutorial está dirigido a Delivery Managers, Scrum Masters, Project Managers, Quality Managers, Equipo de desarrollo, Equipo de pruebas, Equipo de administración de información, Equipo de calidad, Equipo de soporte, etc. para comprender los conceptos básicos del Análisis de causa raíz y proporciona plantillas y ejemplos del mismo. .
Lo que vas a aprender:
- ¿Qué es el análisis de causa raíz?
- Proceso de análisis de causa raíz
- Técnicas de análisis de causa raíz
- Factores que causan defectos
- Conclusión
¿Qué es el análisis de causa raíz?
RCA (análisis de causa raíz) es un mecanismo de análisis de los defectos, para identificar su causa. Hacemos una lluvia de ideas, leemos y excavamos el defecto para identificar si el defecto se debió a ' prueba señorita ”, “ señorita de desarrollo 'O era un' requisito o diseños faltan ”.
Cuando el RCA se realiza con precisión, ayuda a prevenir defectos en las versiones o fases posteriores. Si encontramos que un defecto se debió a diseño señorita , podemos revisar los documentos de diseño y tomar las medidas adecuadas. Del mismo modo, si encontramos que un defecto se debió a prueba señorita , podemos revisar nuestros casos de prueba o métricas y actualizarlos en consecuencia.
RCA no debe limitarse solo a probar los defectos. También podemos hacer RCA en defectos de producción. Basándonos en la decisión de RCA, podemos mejorar nuestra Banco de pruebas e incluir esos tickets de producción como casos de prueba de regresión. Esto asegurará que el defecto o defectos similares no se repitan.
Proceso de análisis de causa raíz
RCA no solo se utiliza para defectos informados desde el sitio de un cliente, sino también para defectos de UAT, defectos de pruebas unitarias, problemas a nivel de procesos comerciales y operativos, problemas de la vida diaria, etc.Por lo tanto, se utiliza en múltiples industrias como Sector de Software, Manufactura, Salud, Sector Bancario, etc.
Llevar a cabo un análisis de causa raíz es similar al trabajo del médico que trata a un paciente. El médico primero comprenderá los síntomas. Luego se referirá a las pruebas de laboratorio para analizar la causa raíz de la enfermedad.
Si aún se desconoce la causa raíz de la enfermedad, el médico derivará a exámenes de exploración para comprender mejor. Continuará con el diagnóstico y el estudio hasta que se limite a la causa raíz de la enfermedad del paciente. La misma lógica se aplica al análisis de causa raíz realizado en cualquier industria.
Por lo tanto, la RCA tiene como objetivo encontrar la causa raíz y no tratar el síntoma, siguiendo un conjunto específico de pasos y herramientas asociadas. Es diferente del análisis de defectos, solución de problemas y otros métodos de resolución de problemas, ya que estos métodos intentan encontrar la solución para el problema específico, pero RCA intenta encontrar la causa subyacente.
Origen del nombre Análisis de causa raíz:
(imagen fuente )
Las hojas, el tronco y las raíces son las partes más importantes de un árbol. Las hojas (Síntoma) y el (Problema) del tronco que están por encima del suelo son visibles, pero las raíces (Causa) que están debajo del suelo no son visibles y las raíces crecen más profundamente y pueden extenderse más de lo esperado. Por lo tanto, el proceso de profundizar en el problema se llama Análisis de causa raíz.
Ventajas del análisis de causa raíz
A continuación se enumeran algunos de los beneficios que obtendrá:
- Evitar la reaparición del mismo problema en el futuro.
- Eventualmente, reduzca la cantidad de defectos reportados a lo largo del tiempo.
- Reduce los costos de desarrollo y ahorra tiempo.
- Mejorar el proceso de desarrollo de software y, por lo tanto, ayudar a la entrega rápida al mercado.
- Mejora la satisfacción del cliente.
- Aumente la productividad.
- Encuentra problemas ocultos en el sistema.
- Ayuda a la mejora continua.
Tipos de causas fundamentales
# 1) Causa humana: Error provocado por humanos.
Ejemplos:
- Poco calificado.
- Instrucciones no seguidas debidamente.
- Realizó una operación innecesaria.
# 2) Causa organizacional: Un proceso que la gente usa para tomar decisiones que no fueron las adecuadas.
Ejemplos:
- El líder del equipo dio instrucciones vagas a los miembros del equipo.
- Elegir a la persona equivocada para una tarea.
- No existen herramientas de seguimiento para evaluar la calidad.
# 3) Causa física: Cualquier elemento físico falló de alguna manera.
Ejemplos:
- La computadora sigue reiniciándose.
- El servidor no se inicia.
- Ruidos extraños o fuertes en el sistema.
Pasos para realizar un análisis de causa raíz
Se requiere un enfoque estructurado y lógico para un análisis de causa raíz eficaz. Por tanto, es necesario seguir una serie de pasos.
# 1) Formar equipo RCA
Cada equipo debe tener un Administrador de análisis de causa raíz (Administrador de RCA) quien recopilará los detalles del equipo de soporte e iniciará el proceso de inicio de RCA. Coordinará y asignará los recursos que necesiten asistir a las reuniones de RCA según el problema planteado.
Los equipos que asistan a la reunión deben tener personal de cada equipo (Requisitos, Diseño, Pruebas, Documentación, Calidad, Soporte y Mantenimiento) que estén más familiarizados con el problema. El equipo también debe tener personas que estén directamente relacionadas con el defecto. Por ejemplo, el ingeniero de soporte que le dio una solución inmediata al cliente.
Comparta los detalles del problema con el equipo antes de asistir a la reunión para que puedan hacer un análisis inicial y estar preparados. Los miembros del equipo también recopilan información relacionada con el defecto. Dependiendo del informe del incidente, cada equipo rastreará lo que salió mal con este escenario en sus respectivas fases. Estar preparado aumentará la eficiencia de la próxima discusión.
# 2) Defina el problema
Recopile los detalles del problema, como informes de incidentes, evidencia del problema (captura de pantalla, registros, informes, etc.), luego estudie / analice el problema haciendo las siguientes preguntas:
- ¿Cuál es el problema?
- ¿Cuál es la secuencia de eventos que llevaron al problema?
- ¿Qué sistemas estuvieron involucrados?
- ¿Cuánto tiempo existió el problema?
- ¿Cuál es el impacto del problema?
- ¿Quién estuvo involucrado y determinar quién debe ser entrevistado?
Utilice reglas 'INTELIGENTES' para definir su problema:
- S ESPECÍFICO
- METRO FÁCIL
- A ORIENTADO A CTION
- R ELEVANTE
- T SUJETO AL NOMBRE
# 3) Identifique la causa raíz
Realizar el LLUVIA DE IDEAS sesión dentro del equipo de RCA formado para identificar las causas. Utilizar el diagrama de espina de pescado o 5 Por qué el análisis método o ambos para llegar a la causa raíz.
El gerente de RCA debe moderar la reunión y establecer las reglas para la sesión de lluvia de ideas. Por ejemplo, las reglas pueden ser:
- No se debe permitir criticar / culpar a otros.
- No juzgues las ideas de los demás. Ninguna idea es mala, fomentan las ideas locas.
- Aproveche las ideas de otros. Piense en cómo puede aprovechar las ideas de otros y mejorarlas.
- Dé a cada participante el tiempo necesario para compartir sus puntos de vista.
- Fomente el pensamiento innovador.
- Mantente concentrado.
Todas las ideas deben registrarse. El gerente de RCA debe asignar un miembro para que registre las actas de la reunión y actualice las plantillas de RCA.
# 4) Implementar acción correctiva de causa raíz (RCCA)
La acción de corrección implica corregir la solución mediante la identificación de la causa raíz real. Para facilitar esto, debe estar presente un administrador de entregas que pueda decidir en qué versiones se debe implementar la corrección y cuál debe ser la fecha de entrega.
La RCCA debe implementarse de tal manera que esta causa raíz no vuelva a ocurrir en el futuro. La solución proporcionada por el equipo de soporte será temporal para el sitio del cliente donde se informa el problema. Cuando esta solución se fusiona en una versión en curso, realice un análisis de impacto adecuado para asegurarse de que ninguna característica existente se rompa.
Dé los pasos para validar la corrección y supervise la solución implementada para verificar si la solución es efectiva.
# 5) Implementar la acción preventiva de causa raíz (RCPA)
El equipo debe elaborar un plan sobre cómo se puede prevenir un problema similar en el futuro. Por ejemplo, Actualice el manual de instrucciones, mejore el conjunto de habilidades, actualice la lista de verificación de evaluación del equipo, etc. Siga los documentos adecuados de las acciones preventivas y controle si el equipo se está adhiriendo a las acciones preventivas tomadas.
Por favor refiérase a esto trabajo de investigación sobre 'Análisis y prevención de defectos para la mejora de la calidad de los procesos de software' publicado en el Revista internacional de ingeniería y aplicaciones de software para tener una idea de los tipos de defectos reportados en cada fase del software y sugerencias de acciones preventivas para ellos.
La información obtenida de RCA puede utilizarse como entrada en Análisis de modos y efectos de falla (FMEA ) para identificar puntos donde la solución puede fallar.
Implementar Análisis de Pareto con las causas identificadas durante la RCA durante un período, digamos semestral o trimestralmente, lo que ayudará a identificar las principales causas que contribuyen a los defectos y centrarse en la acción preventiva para ellos.
Técnicas de análisis de causa raíz
# 1) Análisis de espina de pescado
El diagrama de espina de pescado es una herramienta de análisis de causa raíz visual para identificar las posibles causas de los problemas identificados y, por lo tanto, también se denomina diagrama de causa y efecto. Le permite llegar a la verdadera causa raíz del problema en lugar de resolver su síntoma.
También se llama Diagrama de Ishikawa, ya que fue creado por Dr. Kaoru Ishikawa (un estadístico de control de calidad japonés). También se conoce como diagrama de espina de pescado o Fishikawa.
El análisis de espina de pescado se utiliza en la fase de análisis de DMAIC de six sigma enfoque para la resolución de problemas. Es uno de los 7 herramientas básicas de control de calidad .
Pasos para crear un diagrama de espina de pescado:
El diagrama de espina de pescado se asemeja al esqueleto de un pez con el problema de formar la cabeza del pez y hace que se forme la columna vertebral y las espinas del pez.
Siga los pasos a continuación para crear un diagrama de espina de pescado:
- Escribe el problema en el cabeza de pez .
- Identifica el categoría de causas y escribir a final de cada hueso (categoría de causa 1, categoría de causa 2 …… categoría de causa N)
- Identifica el causas primarias en cada categoría y márquelo como causa principal 1, causa principal 2, causa principal N.
- Extienda las causas a niveles secundarios, terciarios y más según corresponda.
Un ejemplo de cómo se aplica un diagrama de espina de pescado a un defecto de software (ver más abajo).
Hay muchas herramientas gratuitas y de pago disponibles para crear un diagrama de espina de pescado. El diagrama de espina de pescado de este tutorial se creó con ' Creately ' herramienta en línea . En nuestro próximo tutorial se explicarán más detalles sobre las plantillas y herramientas de espina de pescado.
# 2) La técnica de los 5 porqués
5 Por qué Technique fue desarrollada por Sakichi Toyoda y se utilizó en Toyota en su industria manufacturera. Esta técnica se refiere a una serie de preguntas donde cada respuesta se responde con una pregunta por qué. Puede estar relacionado con la forma en que un niño hará preguntas a los adultos. Basado en la respuesta que da un adulto, ellos harán preguntas de “Por qué” una y otra vez hasta que estén satisfechos.
5 Por qué la técnica se utiliza de forma independiente o como parte del análisis de espina de pescado para profundizar en la causa raíz del problema. El número de pasos no se limita a 5. Puede ser menor o mayor a 5 hasta que llegue el diagnóstico del problema. 5 Los porqués son una técnica relativamente más simple y una forma más rápida de llegar a las causas fundamentales. Facilita un diagnóstico rápido para descartar los síntomas y llegar a la causa raíz.
El éxito de la técnica depende del conocimiento de la persona. Puede haber diferentes respuestas a la misma pregunta por qué. Por lo tanto, es importante seleccionar la dirección y el enfoque correctos en la reunión.
Pasos para crear el diagrama de los 5 porqués
Inicie la discusión de lluvia de ideas definiendo el problema. Luego siga con el siguiente Por qué y sus respuestas.
Un ejemplo de cómo se aplica el diagrama de los 5 porqués a un defecto de software:
5 Por qué se dibujan plantillas e imágenes con el software en línea Creately.
Factores que causan defectos
Son muchos los factores que provocan la aparición de los defectos:
- Requisitos poco claros / faltantes / incorrectos
- Diseño incorrecto
- Codificación incorrecta
- Prueba insuficiente
- Problemas ambientales (hardware, software o configuraciones)
Estos factores siempre deben tenerse en cuenta al realizar el proceso de RCA.
RCA comienza y procede con una lluvia de ideas sobre el defecto. La única pregunta que nos hacemos mientras hacemos RCA es '¿POR QUÉ?' ¿y qué?' Podemos profundizar en cada fase del ciclo de vida para rastrear dónde persiste el defecto.
Comencemos con el '¿POR QUÉ?' preguntas, (la lista no es limitada). Puede comenzar desde la fase externa y avanzar hacia la fase interna de SDLC.
mejor editor de texto para ventanas de Python
- 'POR QUÉ' no se detectó el defecto durante el Test de sanidad ¿en producción?
- “¿POR QUÉ” no se detectó el defecto durante la prueba?
- “¿POR QUÉ” no se detectó el defecto durante la revisión del caso de prueba?
- 'POR QUÉ' no se detectó el defecto Examen de la unidad ?
- “¿POR QUÉ” no se detectó el defecto durante la “Revisión del diseño”?
- “¿POR QUÉ” no se detectó el defecto durante la fase de requisitos?
La respuesta a esta pregunta le dará la fase exacta en la que existe el defecto. Ahora, una vez que identifica la fase y la razón, entonces viene la parte 'QUÉ'.
“¿QUÉ vas a hacer para evitar esto en el futuro?
La respuesta a esta pregunta “QUÉ”, si se implementa y se soluciona, evitará que el mismo defecto o el tipo de defecto vuelva a surgir. Tomar las medidas adecuadas para mejorar el proceso identificado para que no se repita el defecto o el motivo del defecto.
Según los resultados de RCA, puede determinar cuál de las fases tiene áreas problemáticas.
Por ejemplo, si determina que la mayor parte del RCA de los defectos se debe a requisito falta , luego puede mejorar la fase de recopilación / comprensión de requisitos introduciendo más revisiones o sesiones de recorrido.
Del mismo modo, si encuentra que la mayoría de los defectos se deben a prueba señorita , necesita mejorar el proceso de prueba. Puede introducir métricas como Métricas de trazabilidad de requisitos , Test Coverage Metrics, o puede controlar el proceso de revisión o cualquier otro paso que crea que mejoraría la eficiencia de la prueba.
Conclusión
Es responsabilidad de todo el equipo sentarse y analizar los defectos y contribuir a la mejora del producto y del proceso.
En este tutorial, tiene una comprensión básica de RCA, los pasos a seguir para hacer un RCA eficiente y diferentes herramientas para usar, como el análisis de espina de pescado y la técnica de los 5 por qué. En los próximos tutoriales, se cubrirán diferentes plantillas de RCA, ejemplos y casos de uso sobre cómo implementarlo.
Lectura recomendada
- Análisis e informes de resultados de pruebas: pruebas de carga con LoadRunner
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Pruebe sus capacidades de análisis y su capacidad de pensamiento: ejercicios de prueba de software (parte 2)
- ¿Qué es la técnica de prueba basada en defectos?
- ¿Qué es el análisis de valor límite y la división de equivalencia?
- Descarga del libro electrónico Testing Primer
- ¿Qué es el ciclo de vida de defectos / errores en las pruebas de software? Tutorial del ciclo de vida de los defectos
- Pruebas de carga con tutoriales de HP LoadRunner