Menú

Análisis de modos y efectos de falla (FMEA): cómo analizar los riesgos para obtener una mejor calidad de software y clientes satisfechos.

failure mode effects analysis how analyze risks

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Análisis de modos y efectos de falla (FMEA) es una técnica de gestión de riesgos.

Si se implementa correctamente, esto puede ser una gran adición a la mejor Procesos de aseguramiento de la calidad para ser seguido. En este artículo, nuestro objetivo es presentarle esta técnica de Análisis de Riesgos que, al final, es muy útil para mejorar la calidad del software.

Análisis de modos y efectos de falla (FMEA)

Lo que vas a aprender:

Modo de Fallos y Análisis de Efectos

FMEA es utilizado principalmente por la alta dirección o las partes interesadas. En la práctica, los evaluadores obtienen poca información sobre esta técnica. Pero ahora la tendencia está cambiando y creo que si los evaluadores entienden este concepto correctamente, pueden impulsar su proceso de pensamiento de escribir casos de prueba subir un nivel utilizando esta técnica para:

  • Comprenda los objetivos de las partes interesadas de probar la aplicación.
  • Comprenda el negocio.
  • Derive los escenarios de prueba de alto nivel en función del interés comercial y de la administración.
  • Obtenga casos de prueba efectivos que brinden una mejor cobertura a las áreas propensas a riesgos.
  • Priorice los casos de prueba.
  • Decide que probar y qué aplazar en cualquier fase.

Fondo

EL ANÁLISIS DE RIESGOS es un aspecto crucial de Gestión de pruebas . Entonces surge la pregunta: ¿Qué es el análisis de riesgos? ¿Y porque es importante? Para comprender esto, es vital comprender: ¿Qué es RIESGO?

análisis de riesgo

Ver también => Tipos de riesgos en proyectos de software.

RIESGO como su significado literal es una posibilidad de un resultado o evento negativo o indeseable. Los riesgos, si no se manejan o gestionan adecuadamente, pueden conducir a clientes insatisfechos y de mala calidad y, a veces, a la pérdida de negocios.

java pasar matriz al método por referencia

El riesgo tiene 2 atributos:

  • Probabilidad
  • Impacto

Probabilidad significa las posibilidades de que ocurra un riesgo particular e impacto significa el alcance del efecto del riesgo.

¿Qué es el análisis de riesgos?

El análisis de riesgos es un mecanismo mediante el cual los riesgos potenciales identificados se analizan y estudian a fondo para encontrar la probabilidad y el impacto. Es recomendable medir los dos atributos y en base al resultado identificamos:

  • ¿Qué probar primero?
  • ¿Qué probar más?
  • ¿Qué no probar (esta vez)?

Existen muchos métodos para realizar el análisis de riesgos y, en general, se clasifican en dos tipos:

  • Técnicas informales : Estos se basan en la experiencia, el juicio y la intuición.
  • Técnicas formales : Identificación y ponderación de los atributos de riesgo.

F aflicción METRO oda y ES efectos A nalysis (FMEA): este es un método formal para realizar un análisis de riesgos. En las siguientes secciones, discutiré más sobre FMEA e intentar elaborarlo con el ejemplo.

FMEA es una técnica formal de análisis de riesgos. Es una herramienta sistemática y cuantitativa en forma de hoja de cálculo que ayuda a los miembros a analizar qué podría salir mal. Para hacer el FMEA necesitamos las personas adecuadas sobre la mesa. Requiere un representante de todos los ámbitos de la industria, incluidos los clientes.

Descripción

FMEA comienza y continúa con sesiones de lluvia de ideas. Los participantes deben identificar todos los componentes, módulos, dependencias, limitaciones que podrían fallar en un entorno de producción y eventualmente conducir a una mala calidad, confiabilidad y pueden resultar en la pérdida de negocios.

Durante FMEA no solo identificamos el alcance de la pérdida, sino que también intentamos identificar la causa de esas fallas. Para medir AMFE, necesitamos 3 atributos:

  • Gravedad de la falla (S)
  • Prioridad del fracaso (P)
  • Probabilidad del fracaso (L)

Ponemos cada uno de estos atributos en una escala que se muestra a continuación:

Escala de gravedad:

Descripción Clase Escala
Pérdida de datos, hardware o problemas de seguridad. Urgente 1
Pérdida de funcionalidad sin solución alternativa Alto 2
Pérdida de funcionalidad con una solución alternativa Medio 3
Pérdida parcial de funcionalidad Bajo 4
Cosmético o trivial Ninguno 5

Escala de prioridad:

Descripción Clase Escala
Pérdida total del valor del sistema Urgente 1
Pérdida inaceptable del valor del sistema Alto 2
Posiblemente reducción del valor del sistema Medio 3
Reducción aceptable del valor del sistema Bajo 4
Una reducción insignificante en el valor del sistema Ninguno 5

Escala de probabilidad:

Descripción Clase Escala
Seguro que afectará a todos los usuarios Urgente 1
Es probable que afecte a algunos usuarios Muy alto 2
Posible impacto en algunos usuarios Alto 3
Impacto limitado para algunos usuarios Bajo 4
Inimaginable en uso real Ninguno 5

Todos estos tres atributos (gravedad, prioridad y probabilidad) se miden individualmente en escala y luego se multiplican para obtener una Número de prioridad de riesgo (RPN).

es decir. Número de Prioridad de Riesgo ( RPN) = S * P * L

Con base en este valor de RPN, determinamos el alcance de las pruebas. Menor es el RPN, mayor es el Riesgo.

Intentemos entenderlo con un ejemplo:

Ejemplo de análisis del efecto del modo de falla

(Este es un ejemplo hipotético solo para fines de comprensión. La implementación real y las características pueden variar)

Consideremos un ejemplo simple de una aplicación bancaria que tiene 4 funciones.

  • Característica 1: Retirar
  • Característica 2: Depositar
  • Característica 3: Préstamo hipotecario
  • Característica 4: Depósitos fijos.

Se conforma un equipo de Análisis de Riesgos integrado por el gerente del Banco, UAT Test Manager (que representa al usuario final), Arquitecto técnico, Arquitecto de pruebas, Administrador de red, DBA y Project Manager.

Después de una serie de sesiones de lluvia de ideas, el equipo propuso el siguientes riesgos:

  • Lógica empresarial compleja en caso de calcular el tipo de interés del préstamo hipotecario.
  • El sistema falla en 200 usuarios concurrentes.
  • El sistema no puede manejar documentos de más de 6 MB.

Ahora intentemos calcular la gravedad, la prioridad y la probabilidad de estos riesgos identificados.

Gravedad:

Característica Clase Escala
Lógica empresarial compleja en caso de calcular la tasa de interés de un préstamo hipotecario Muy alto 2
El sistema falla en 200 usuarios concurrentes Alto 3
El sistema no puede manejar documentos de más de 6 MB Muy alto 2

Prioridad:

Característica Clase Escala
Lógica empresarial compleja en caso de calcular la tasa de interés de un préstamo hipotecario Muy alto 2
El sistema falla en 200 usuarios concurrentes Alto 3
El sistema no puede manejar documentos de más de 6 MB Alto 3

Probabilidad:

Característica Clase Escala
Lógica empresarial compleja en caso de calcular la tasa de interés de un préstamo hipotecario Alto 3
El sistema falla en 200 usuarios concurrentes Alto 3
El sistema no puede manejar documentos de más de 6 MB Bajo 4

Ahora, juntemos todos estos atributos:

Característica

Gravedad

Prioridad

Probabilidad

Lógica empresarial compleja en caso de calcular la tasa de interés de un préstamo hipotecario 2 2 3
El sistema falla en 200 usuarios concurrentes 3 3 3
El sistema no puede manejar documentos de más de 6 MB 2 3 4

Ahora calculemos el número de prioridad de riesgo (RPN = gravedad * prioridad * probabilidad)

Característica

Gravedad

Prioridad

Probabilidad

RPN

Lógica empresarial compleja en caso de calcular la tasa de interés de un préstamo hipotecario 2 2 3 12
El sistema falla en 200 usuarios concurrentes 3 3 3 27
El sistema no puede manejar documentos de más de 6 MB 2 3 4 24

Ahora la clave es: Menor es el RPN - Mayor es el riesgo.

Entonces, aquí para este ejemplo en particular, la característica 1 (lógica comercial compleja en caso de calcular la tasa de interés del préstamo hipotecario) tiene el mayor riesgo y la característica 2 (el sistema falla en 200 usuarios concurrentes) tiene el riesgo más bajo.

¿Cómo usar esto para derivar casos de prueba?

Ya que Característica 1 es el característica más arriesgada , los casos de prueba deben ser rigurosos y más detallados. Escriba los casos de prueba para cubrir la funcionalidad completa y los módulos que afectan a la función. Utilice todo tipo de técnicas de escritura de casos de prueba ( Partición de equivalencia y BVA , Gráfico de causa y efecto , Diagrama de transición de estado ) para derivar los casos de prueba.

Los casos de prueba no solo deben ser funcionales sino también no funcionales ( Prueba de carga , Estrés y prueba de volumen, etc.). Básicamente, necesitamos hacer pruebas exhaustivas de esta característica en particular, así que base tus casos de prueba en consecuencia. Además, considere todos los módulos dependientes de esta importante característica.

Característica 2 es el Característica MENOS RIESGO , así que base tus casos de prueba en la funcionalidad principal. Solo casos de prueba de alto nivel para validar que la función funciona como se espera deberían ser suficientes.

Característica 3 es un Característica de RIESGO MODERADO , así que base tus casos de prueba para cubrir todas las funciones principales y dependientes. Escribe algunos casos de prueba de BVA para validar también algunos escenarios negativos. La extensión de los casos de prueba debe estar entre el factor de riesgo alto y el factor de riesgo bajo. Si es necesario, incluya también algunos casos de prueba no funcionales.

FMEA y grado de prueba

Con base en el valor de RPN, determinamos la extensión o el grado de prueba que se debe realizar.

Normalmente si:

  • RPN está entre 1 y 10, hacemos pruebas exhaustivas (cubriendo dentro y fuera de la función / módulo)
  • RPN está entre 11-30, hacemos pruebas equilibradas (que cubren todas las funciones principales de la función / módulo)
  • RPN está entre 31-70, hacemos pruebas de oportunidad (que cubren la funcionalidad básica de la función / módulo)
  • RPN es más de 70: sin pruebas o cuando el tiempo lo permite, solo informes de anomalías.

Estos rangos o números no se limitan a los que mencioné anteriormente. Pueden variar según la naturaleza del proyecto.

Recursos: Descargar Software FMEA y Plantilla FMEA .

Conclusión

El análisis de riesgos utilizando FMEA requiere tiempo y experiencia. Los resultados deseados solo se pueden lograr mediante la participación equitativa de todos los miembros responsables del equipo. Aunque esta técnica es formal, requiere una serie de sesiones de lluvia de ideas y es igualmente importante documentar todos los riesgos identificados.

Dado que la mayoría de las aplicaciones son exclusivas, la escala para medir los parámetros de AMEF (es decir, prioridad, gravedad y probabilidad) también depende de la aplicación. Si se hace adecuadamente, la técnica FMEA tiene muchas ventajas. Se puede utilizar para identificar riesgos potenciales y, en base a este equipo, se puede planificar una estrategia de mitigación eficaz.

Sobre el Autor: Este es un artículo invitado de Shilpa Chatterjee Roy. Trabaja en el campo de las pruebas de software durante los últimos 8,5 años en varios dominios.

Si ha utilizado esta técnica, no dude en comentar su experiencia a continuación.

Lectura recomendada

^