Pruebas basadas en riesgos: enfoque, matriz, proceso y ejemplos

⚡ Resumen inteligente

Las pruebas basadas en riesgos clasifican cada característica según la probabilidad de que falle y el daño que causaría dicho fallo, y luego dedican el esfuerzo de prueba disponible primero a los elementos con mayor puntuación, en orden de prioridad.

  • 🔘 Fórmula básica: La calificación de riesgo es igual a la probabilidad multiplicada por la gravedad, lo que convierte una preocupación subjetiva en un número comparable.
  • ☑️ Registro de riesgos: Una única hoja de cálculo contiene todos los riesgos identificados, su responsable, su nivel de exposición, el objetivo de la prueba y la fase en la que se aborda.
  • ✅ Número de prioridad de la prueba: La probabilidad, las consecuencias y la eficacia de la prueba se multiplican para obtener una puntuación entre 1 y 125 que determina el orden de ejecución.
  • 🧪 Proceso de cinco fases: Identificación de riesgos, análisis de riesgos, respuesta a riesgos, prueba scoping y la definición del proceso de prueba se ejecuta en secuencia.
  • 🛠️ Cada nivel de prueba: Este enfoque se aplica a las pruebas de componentes, integración, sistema y aceptación, no solo a las pruebas de sistema.
  • 📊 Riesgo residual: Medir lo que queda sin probar después de la ejecución es lo que convierte los resultados de las pruebas en una decisión de lanzamiento informada.

Mapa de la matriz de pruebas basadas en riesgosping probabilidad frente a gravedad para priorizar el esfuerzo de prueba

Pruebas basadas en riesgos

Pruebas basadas en riesgos (RBT) es un tipo de prueba de software que se basa en la probabilidad de riesgo. Implica evaluar el riesgo en función de la complejidad del software, la criticidad del negocio, la frecuencia de uso y las áreas con mayor probabilidad de contener un precisaLas pruebas basadas en riesgos priorizan la prueba de las características y funciones de la aplicación de software que tienen mayor impacto y son más propensas a presentar defectos.

El riesgo es la ocurrencia de un evento incierto con un efecto positivo o negativo en los criterios de éxito medibles de un proyecto. Puede tratarse de un evento pasado, actual o futuro. Estos eventos inciertos pueden afectar los objetivos de costo, negocio, técnicos y de calidad del proyecto.

Los riesgos pueden ser positivos o negativos.

  • Riesgos positivos Se las denomina oportunidades y ayudan a la sostenibilidad empresarial. Algunos ejemplos incluyen invertir en un nuevo proyecto, cambiar los procesos empresariales y desarrollar...ping nuevos productos.
  • Riesgos negativos Se las denomina amenazas, y para el éxito del proyecto deben implementarse recomendaciones para minimizarlas o eliminarlas.

Debido a que la técnica asigna esfuerzo en lugar de agregar un nuevo nivel de prueba, se superpone a la otra. tipos de pruebas de software en lugar de reemplazar alguno de ellos.

¿Cuándo implementar las pruebas basadas en riesgos?

Las pruebas basadas en riesgos se pueden implementar en

  • Proyectos con limitaciones de tiempo, recursos o presupuesto.
  • Proyectos donde el análisis basado en riesgos se puede utilizar para detectar vulnerabilidades a Ataques de inyección SQL.
  • Pruebas de seguridad en entornos de computación en la nube.
  • Nuevos proyectos con factores de alto riesgo, como la falta de experiencia con las tecnologías utilizadas o la falta de conocimiento del sector empresarial.
  • Modelos de entrega incrementales e iterativos.

Proceso de gestión de riesgos

Analicemos ahora los pasos que intervienen en el proceso de gestión de riesgos.

Identificación de riesgo

La identificación de riesgos puede realizarse mediante talleres de riesgos, listas de verificación, sesiones de lluvia de ideas, entrevistas, la técnica Delphi, diagramas de causa y efecto, lecciones aprendidas de proyectos anteriores, análisis de la causa raíz y contactando a expertos en el dominio y expertos en la materia.

Un registro de riesgos es una hoja de cálculo que contiene la lista de riesgos identificados, respuestas potenciales y causas raíz. Se utiliza para monitorear y tracSe deben considerar los riesgos (tanto amenazas como oportunidades) a lo largo de la vida del proyecto. Las estrategias de respuesta a los riesgos pueden utilizarse para gestionar los riesgos positivos y negativos.

La Estructura de Desglose de Riesgos (ERR) desempeña un papel fundamental en la planificación de riesgos. Ayuda a identificar las áreas propensas a riesgos y facilita una evaluación y un seguimiento eficaces de los mismos a lo largo del proyecto. Asimismo, permite asignar el tiempo y los recursos necesarios para las actividades de gestión de riesgos y categorizar las diversas fuentes de las que pueden surgir riesgos en el proyecto.

El ejemplo que se muestra a continuación ilustra cómo una Estructura de Desglose de Riesgos agrupa los riesgos del proyecto en categorías para que no se pase por alto ninguna fuente de riesgo.

Grupo de estructura de desglose de riesgos de muestraping Los riesgos del proyecto se clasifican en categorías para la planificación de riesgos.

Análisis de Riesgos (Incluye Análisis Cuantitativo y Cualitativo)

Una vez identificada la lista de riesgos potenciales, el siguiente paso es analizarlos y clasificarlos según su importancia. Una de las técnicas cualitativas de análisis de riesgos es la Matriz de Riesgos (que se abordará en una sección posterior). Esta técnica se utiliza para determinar la probabilidad y el impacto del riesgo.

Planificación de la respuesta al riesgo

En función del análisis, podemos decidir si los riesgos requieren una respuesta. Por ejemplo, algunos riesgos requerirán una respuesta en el plan del proyecto, otros en el seguimiento del proyecto y otros no requerirán ninguna respuesta.

El propietario del riesgo es responsable de identificar opciones para reducir la probabilidad y el impacto de los riesgos asignados.

La mitigación de riesgos es un método de respuesta que se utiliza para reducir los impactos adversos de posibles amenazas. Esto se puede lograr eliminando los riesgos o reduciéndolos a un nivel aceptable. El diagrama a continuación sitúa la planificación de la respuesta a los riesgos dentro del ciclo general de gestión de riesgos.

Paso de planificación de respuesta al riesgo ubicado dentro del proceso de gestión de riesgos

Contingencia de Riesgo

La contingencia se define como la posibilidad de un evento incierto cuyo impacto es desconocido o impredecible. Un plan de contingencia también se conoce como plan de acción o plan de respaldo para los peores escenarios. En otras palabras, determina qué medidas se podrían tomar cuando se materializa un evento imprevisible.

Seguimiento y Control de Riesgos

El proceso de control y monitoreo de riesgos se utiliza para tracSe identifican los riesgos, se monitorean los riesgos residuales, se identifican nuevos riesgos, se actualiza el registro de riesgos, se analizan las razones de cualquier cambio, se ejecuta el plan de respuesta ante riesgos y se monitorean los factores desencadenantes de riesgos. Posteriormente, se evalúa su eficacia para reducir el riesgo.

Esto se puede lograr mediante reevaluaciones de riesgos, auditorías de riesgos, análisis de variaciones y tendencias, medición del desempeño técnico, reuniones de actualización de estado y reuniones retrospectivas.

La tabla que aparece a continuación proporciona información sobre los insumos, las herramientas y los resultados del monitoreo y control de riesgos.

Aportes al Monitoreo y Control de Riesgos Herramientas y técnicas para el monitoreo y control de riesgos. Resultados del seguimiento y control de riesgos
Plan de gestión de Riesgos Auditorías de respuesta a los riesgos del proyecto Planes de solución
Plan de respuesta a riesgos Revisiones periódicas de riesgos del proyecto Acción correctiva
Plan de comunicación del proyecto Análisis del valor ganado Solicitudes de cambio de proyecto
Identificación y análisis de riesgos adicionales Medición del desempeño técnico Actualizaciones del plan de respuesta ante riesgos y de la lista de verificación de identificación de riesgos.
Cambios de alcance Planificación adicional de respuesta a riesgos Base de datos de riesgos

Debemos recordar que el riesgo aumenta con los cambios tecnológicos, el tamaño del proyecto, la duración del proyecto (un plazo de ejecución más largo), el número de organismos patrocinadores, las estimaciones del proyecto, el esfuerzo y la escasez de personal cualificado.

Enfoque de pruebas basado en riesgos

El proceso de gestión descrito anteriormente sirve de base para el método de prueba que se describe a continuación. Cada paso numerado produce una entrada que el siguiente paso utiliza.

  1. Analizar los requisitos.
    • Se revisan los documentos (SRS, FRS, casos de uso). Esta actividad se realiza para detectar y eliminar errores y ambigüedades.
    • La aprobación de requisitos es una de las técnicas de reducción de riesgos para evitar la introducción de cambios tardíos en el proyecto. Cualquier modificación de un requisito después de que el documento se haya definido como línea base implica un proceso de control de cambios y las aprobaciones correspondientes.
  2. Evaluar los riesgos calculando la probabilidad y el impacto que cada requisito podría tener en el proyecto, teniendo en cuenta los criterios definidos, como el coste, el cronograma, los recursos, el alcance, el rendimiento técnico, la seguridad, la fiabilidad y la complejidad.
    • Identificar la probabilidad de fallo y las áreas de alto riesgo. Esto se puede hacer utilizando una matriz de evaluación de riesgos.
    • Utilice un registro de riesgos para enumerar el conjunto de riesgos identificados. Actualice, supervise y track los riesgos periódicamente a intervalos regulares.
    • Es necesario realizar un perfil de riesgo en esta etapa para comprender la capacidad de riesgo y los niveles de tolerancia al riesgo.
  3. Priorizar los requisitos en función de la calificación.
    • Se define el proceso de prueba basado en riesgos.
    • Los riesgos altamente críticos y medios pueden considerarse para la planificación, implementación y seguimiento de las medidas de mitigación. Los riesgos bajos pueden mantenerse en una lista de vigilancia.
    • La evaluación de la calidad de los datos de riesgo se realiza para analizar la calidad de los datos.
  4. Planificar y definir las pruebas según la calificación.
    • Aplique un enfoque de prueba y técnicas de diseño de pruebas apropiadas para que los elementos de mayor riesgo se prueben primero. Los elementos de alto riesgo pueden ser probados por un recurso con buenos conocimientos y experiencia en el área.
    • Se pueden utilizar diferentes técnicas de diseño de pruebas, por ejemplo, la tabla de decisiones técnica en ítems de prueba de alto riesgo, y solo partición de equivalencia para ítems de prueba de bajo riesgo.
    • Casos de prueba También están diseñados para cubrir múltiples funcionalidades y escenarios comerciales integrales.
    • Prepare los datos de prueba, las condiciones de prueba y el banco de pruebas.
  5. RevConsulte la documentación de la prueba. — los planes de prueba, la estrategia de prueba, los casos de prueba, los informes de prueba y cualquier otro documento creado por el equipo de pruebas.
    • La revisión por pares es un paso importante en la identificación de defectos y la reducción de riesgos.
  6. Realizar ensayos y controles de calidad de los resultados.
    • Los casos de prueba se ejecutan según la prioridad del elemento de riesgo.
    • Mantenimiento tracCoherencia entre los elementos de riesgo, las pruebas que los cubren, los resultados de dichas pruebas y los defectos detectados durante las mismas. Todas las estrategias de prueba ejecutadas correctamente reducirán los riesgos de calidad.
    • Las pruebas basadas en riesgos se pueden utilizar en todos los niveles de prueba. componente, de contacto, te y pruebas de aceptación.
    • A nivel de sistema, debemos centrarnos en lo más importante de la aplicación. Esto se puede determinar analizando la visibilidad de las funciones, la frecuencia de uso y el posible coste de un fallo.
    • Evaluación de los criterios de salida: todas las áreas de alto riesgo han sido evaluadas exhaustivamente, quedando pendientes únicamente riesgos residuales menores.
  7. Informe los resultados de las pruebas basadas en el riesgo. y analizar las métricas.
    • Reevaluar los eventos de riesgo existentes y los nuevos eventos de riesgo en función de los indicadores clave de riesgo.
    • Actualizar el registro de riesgos.
    • Los planes de contingencia funcionan como un plan de respaldo o de emergencia para los riesgos de alta exposición.
    • El análisis y la prevención de defectos se utilizan para eliminar los defectos.
    • Repetición de pruebas y Pruebas de regresión Validar las correcciones de defectos basándose en el análisis de riesgos precalculado, y las áreas de alto riesgo deben ser las que reciban la atención más intensiva.
    • Pruebas de automatización basadas en riesgos, si es factible.
    • Cálculo del riesgo residual.
  8. Supervisar y controlar los riesgos.
    • Los criterios de salida o de finalización pueden definirse por separado para los distintos niveles de riesgo. Se han abordado todos los riesgos clave con las medidas o planes de contingencia adecuados, y la exposición al riesgo se sitúa en el nivel aceptable para el proyecto o por debajo de él.
    • Reevaluación de perfiles de riesgo y comentarios de los clientes.

Enfoque de prueba basado en riesgos para la prueba del sistema

  1. Prueba técnica del sistema — Esto se conoce como prueba de entorno y prueba de integración. La prueba de entorno incluye pruebas en los entornos de desarrollo, pruebas y producción.
  2. Prueba del sistema funcional — Pruebas de todas las funcionalidades, características, programas y módulos. El objetivo de esta prueba es evaluar si el sistema cumple con los requisitos especificados.
  3. Prueba del sistema no funcional — Prueba de los requisitos no funcionales: rendimiento, pruebas de carga, pruebas de estrés, pruebas de configuración, pruebas de seguridad, copias de seguridad y recuperación procedimientos y documentación (documentación del sistema, operación e instalación).

El siguiente diagrama ofrece una visión general clara del proceso mencionado anteriormente.

Enfoque de pruebas basado en riesgos para la prueba del sistema dividido en pruebas técnicas, funcionales y no funcionales del sistema.

Las pruebas del sistema incluyen tanto pruebas funcionales como pruebas no funcionales.

Prueba funcional garantiza que el producto o la aplicación cumpla con los requisitos del cliente y del negocio. Por otro lado, pruebas no funcionales Se realiza para verificar si el producto cumple con las expectativas del cliente en términos de calidad, fiabilidad, facilidad de uso, rendimiento y compatibilidad.

Cómo realizar pruebas basadas en riesgos: Proceso completo

Esta sección abarca el proceso de pruebas basado en riesgos, que se desarrolla en cinco fases.

  1. Identificación de riesgo
  2. Análisis de riesgo
  3. Respuesta a los riesgos
  4. Prueba Scoping
  5. Definición del proceso de prueba

Las cinco fases se retroalimentan entre sí como se muestra a continuación.

Las cinco fases del proceso de prueba basado en riesgos, desde la identificación de riesgos hasta la definición del proceso de prueba.

  1. En este proceso, se identifican y categorizan los riesgos, se prepara un borrador del registro de riesgos y se realiza una clasificación de los riesgos para identificar los riesgos significativos.
  2. La respuesta a los riesgos implica formular los objetivos de la prueba a partir de los riesgos y seleccionar las técnicas adecuadas para que la actividad o técnica de prueba cumpla con esos objetivos.
  3. Para calcular la puntuación de eficacia de las pruebas, se tienen en cuenta las dependencias documentadas, los requisitos, el coste y el tiempo necesario para las pruebas de software.
  4. Prueba scoping Se trata de una actividad de revisión que requiere la participación de todas las partes interesadas y del personal técnico. Es importante respetar el alcance de riesgos acordado. Estos riesgos deben abordarse mediante pruebas, y todos los miembros deben estar de acuerdo con las responsabilidades que se les asignan y el presupuesto destinado a estas actividades.
  5. Una vez definido el alcance de las pruebas, los objetivos, supuestos y dependencias de cada etapa de la prueba deben recopilarse en el formato estándar.

El ejemplo práctico que se muestra a continuación relaciona cada requisito con su riesgo asociado y con el objetivo de prueba que lo aborda.

Requisitos funcionales F1 a F3 y requisitos no funcionales N1 y N2, asociados a sus riesgos y objetivos de prueba.

Consideremos los requisitos funcionales F1, F2 y F3, y los requisitos no funcionales N1 y N2.

F1 — Requisito funcional, R1 — Riesgo asociado con F1

  • Objetivo de la prueba 1: Demostrar, mediante una prueba, que las características y funcionalidades esperadas del sistema funcionan correctamente y que el riesgo R1 puede abordarse mediante pruebas funcionales.
  • Prueba: Las pruebas de página del navegador se realizan para ejecutar tareas importantes del usuario y verificar que R1 (el riesgo asociado con F1) se pueda abordar en una variedad de escenarios.

F2 — Requisito funcional, R2 — Riesgo asociado con F2

  • Objetivo de la prueba 2: Demostrar, mediante una prueba, que las características y funcionalidades esperadas del sistema funcionan correctamente y que el riesgo R2 puede abordarse mediante pruebas funcionales.
  • Prueba: Las pruebas de página del navegador se realizan para ejecutar tareas importantes del usuario y verificar que R2 pueda abordarse en una variedad de escenarios.

F3 — Requisito funcional, R3 — Riesgo asociado con F3

  • Objetivo de la prueba 3: Demostrar, mediante una prueba, que las características y funcionalidades esperadas del sistema funcionan correctamente y que el riesgo R3 puede abordarse mediante pruebas funcionales.
  • Prueba: Las pruebas de página del navegador se realizan para ejecutar tareas importantes del usuario y verificar que R3 pueda abordarse en una variedad de escenarios.

N1 — Requisito no funcional, NR1 — Riesgo asociado con N1

  • Objetivo de la prueba N1: Demostrar mediante una prueba que las características operativas del sistema funcionan correctamente y que el riesgo NR1 puede abordarse mediante pruebas no funcionales.
  • Prueba: Las pruebas de usabilidad son una técnica que se utiliza para evaluar la facilidad de uso de las interfaces de usuario y para verificar que el problema NR1 podría resolverse mediante pruebas de usabilidad.

N2 — Requisito no funcional, NR2 — Riesgo asociado con N2

  • Objetivo de la prueba N2: Demostrar mediante una prueba que las características operativas del sistema funcionan correctamente y que el riesgo NR2 puede abordarse mediante pruebas no funcionales.
  • Prueba - Prueba de seguridad Es una técnica que se utiliza para comprobar si la aplicación es segura o vulnerable a ataques, si existe alguna fuga de información y para verificar que el problema NR2 podría abordarse mediante pruebas de seguridad.

Objetivos específicos de la prueba: Los riesgos y objetivos de las pruebas que se enumeran son específicos de cada tipo de prueba, tal como se resume a continuación.

Objetivos de prueba específicos asignados al tipo de prueba que aborda cada riesgo individual

Procedimiento para diseñar el proceso de prueba basado en riesgos

  • Prepare un registro de riesgos. Este registro documenta los riesgos derivados de una lista de riesgos genérica, una lista de verificación existente y sesiones de lluvia de ideas.
  • Incluya los riesgos asociados con los requisitos funcionales y no funcionales del sistema (usabilidad, seguridad, rendimiento).
  • A cada riesgo se le asigna un identificador único.

Las columnas 1 y 2 de ese registro contienen el identificador y la descripción del riesgo. Las columnas restantes se describen a continuación.

Col No. Encabezado de columna Mareas Ideales para Lecciones
3 Probabilidad Probabilidad de que el sistema sea propenso a este modo de fallo.
4 Consecuencias Impacto de este modo de fallo
5 Exposición Producto de probabilidad y consecuencias (columnas 3 y 4)
6 Efectividad de la prueba ¿Qué confianza tienen los evaluadores en que pueden abordar este riesgo?
7 Número de prioridad de prueba Producto de la probabilidad, las consecuencias y la efectividad de la prueba (columnas 3, 4 y 6)
8 Objetivo(s) de la prueba ¿Qué objetivo de prueba se utilizará para abordar este riesgo?
9 Técnicas de prueba ¿Qué método o técnica se utiliza para abordar este riesgo?
10 Dependencias Lo que los evaluadores asumen y de lo que dependen
11 Esfuerzo ¿Cuánto esfuerzo se requiere para esta prueba?
12 Escala de tiempo ¿Cuánto tiempo se requiere para realizar esta prueba?
13 Etapa de prueba A: Pruebas unitarias, Etapa de prueba B: Prueba de integración, Etapa de prueba C: Prueba del sistema Nombre de la persona o grupo que realiza esta actividad

Se evalúa la probabilidad (1 baja, 5 alta) y las consecuencias (1 baja, 5 alta) de cada riesgo, ya que los dos registros extracts a continuación se muestra.

Las columnas de probabilidad y consecuencias del registro de riesgos se puntúan de 1 (bajo) a 5 (alto).

Columna de exposición al riesgo calculada como el producto de la probabilidad y las consecuencias.

  • Se calcula la exposición a la prueba.
  • El evaluador analiza cada riesgo y determina si es posible comprobarlo o no.
  • Los objetivos de la prueba se definen para los riesgos que se pueden probar.
  • El evaluador especifica la actividad de prueba que debe llevarse a cabo de forma planificada para cumplir el objetivo de la prueba (revisiones estáticas, inspecciones, pruebas de sistema, pruebas de integración, pruebas de aceptación, validación HTML, pruebas de localización, etc.).
  • Estas actividades de prueba se pueden clasificar en etapas (pruebas de componentes o examen de la unidad, pruebas de integración, pruebas de sistema, pruebas de aceptación).
  • En ocasiones, un riesgo puede abordarse mediante más de una fase de prueba.
  • Identificar las dependencias y suposiciones (disponibilidad de habilidades, herramientas, entornos de prueba y recursos).
  • Se calcula la efectividad de la prueba. Esta efectividad se relaciona con el nivel de confianza del evaluador en que el riesgo se abordará de manera definitiva mediante la prueba. La puntuación de efectividad de la prueba es un número entre uno y cinco (5 = alta confianza, 1 = baja confianza).
  • Calcula el esfuerzo, el tiempo necesario y el coste para preparar y ejecutar estas pruebas.

Los dos siguientes extracts muestran las columnas restantes del registro y la puntuación de efectividad de la prueba en su lugar.

Columnas del registro de riesgos para objetivos de prueba, técnicas de prueba, dependencias, esfuerzo y plazo.

Se registró una puntuación de eficacia de la prueba de 1 (baja confianza) a 5 (alta confianza) para cada riesgo.

  • Se calcula el número de prioridad de la prueba. Este es el producto de las puntuaciones de probabilidad, consecuencias y efectividad de la prueba.
  • 125 (máximo): un riesgo muy grave que podría detectarse mediante pruebas.
  • 1 (mínimo): un riesgo muy bajo que no se detectaría con las pruebas.
  • Según el número de prioridad de la prueba, su importancia se clasifica como Alta (rojo), Media (amarillo) y Baja (verde). Los elementos de mayor riesgo se prueban primero.
  • Asigne las actividades de prueba a las etapas de prueba. Designe el grupo que realizará las pruebas para cada objetivo en las diferentes etapas de prueba (pruebas unitarias, pruebas de integración, pruebas de sistema, pruebas de aceptación).

La distribución entre las distintas fases de prueba se muestra a continuación.

Número de prioridad de prueba y asignación de actividades de prueba en las etapas de prueba unitaria, de integración, de sistema y de aceptación.

Lo que está dentro y fuera del alcance de las pruebas se decide en el alcance de las pruebas.ping fase.

  • Para cada etapa, se definen los objetivos de la prueba, el componente que se está probando, la responsabilidad, el entorno, los criterios de entrada, los criterios de salida, las herramientas, las técnicas y los entregables.

Objetivos genéricos de la prueba — Estos objetivos genéricos son aplicables a múltiples proyectos y aplicaciones.

  • El componente cumple con los requisitos y está listo para su uso en subsistemas más grandes.
  • Se abordan los riesgos asociados con los tipos de prueba específicos y se logran los objetivos de la prueba.
  • Los componentes integrados están correctamente ensamblados y se garantiza la compatibilidad de la interfaz entre los componentes.
  • El sistema cumple con los requisitos funcionales y no funcionales especificados.
  • Los componentes del producto satisfacen las necesidades del usuario final en su entorno operativo previsto.
  • Una estrategia de gestión de riesgos se utiliza para identificar, analizar y mitigar los riesgos.
  • El sistema cumple con los requisitos normativos del sector.
  • El sistema cumple contracobligaciones duales.
  • Institucionalización y el logro de otros objetivos específicos, como los de costo, plazo y calidad.
  • Los sistemas, los procesos y las personas satisfacen las necesidades del negocio.

Objetivos de prueba genéricos aplicables a múltiples proyectos y a las cuatro etapas de prueba.

Se pueden definir objetivos de prueba genéricos para las diferentes etapas de la prueba.

  • Prueba de componentes
  • Pruebas de integración
  • Pruebas del sistema
  • Test de aceptación

Consideremos ahora la fase de prueba del sistema.

  1. G4 y G5 demuestran que el sistema cumple con los requisitos funcionales (F1, F2, F3) y los requisitos no funcionales (N1, N2).
  2. Demostrar mediante pruebas que las características y funcionalidades esperadas del sistema funcionan correctamente y que los riesgos asociados con F1, F2 y F3 pueden abordarse mediante pruebas funcionales.
  3. Demostrar mediante pruebas que las características operativas del sistema funcionan correctamente y que los riesgos asociados con N1 y N2 pueden abordarse mediante pruebas no funcionales.
  4. En función del número de prioridad de la prueba, la importancia de la misma se puede clasificar como Alta (rojo), Media (amarillo) y Baja (verde).

Matriz de Priorización y Evaluación de Riesgos

La matriz de evaluación de riesgos es la matriz de probabilidad-impacto. Proporciona al equipo del proyecto una visión general rápida de los riesgos y la prioridad con la que debe abordarse cada uno de ellos.

Risk rating = Probability x Severity

La probabilidad es la medida de la posibilidad de que ocurra un evento incierto, basándose en la exposición en términos de tiempo, proximidad y repetición. Se expresa como un porcentaje.

Esto se puede clasificar como Frecuente (A), Probable (B), Ocasional (C), Remoto (D), Improbable (E) y Eliminado (F).

  • Frecuente — Se espera que ocurra varias veces en la mayoría de los casos (91-100%).
  • Probable — Es probable que ocurra varias veces en la mayoría de los casos (61-90%).
  • Ocasional — Podría ocurrir en algún momento (41 – 60%).
  • Remoto — Es poco probable que ocurra, aunque podría ocurrir en algún momento (11 – 40%).
  • Improbable — Puede ocurrir en circunstancias raras y excepcionales (0 – 10%).
  • eliminado — Imposible que ocurra (0%).

La gravedad es el grado de impacto del daño o la pérdida causados ​​por el evento incierto. Se puntúa del 1 al 4 y se clasifica como Catastrófico = 1, Crítico = 2, Marginal = 3 y Despreciable = 4.

  • Catastrófico — Consecuencias graves que hacen que el proyecto sea completamente improductivo e incluso podrían provocar su cierre. Esto debe ser una prioridad absoluta durante la gestión de riesgos.
  • Critical — Consecuencias graves que pueden ocasionar grandes pérdidas. El proyecto se encuentra seriamente amenazado.
  • Marginal — Daños a corto plazo que aún pueden revertirse mediante actividades de restauración.
  • despreciable — Daños o pérdidas leves o mínimos. Esto puede controlarse y gestionarse mediante procedimientos rutinarios.

La prioridad se clasifica en cuatro categorías, que se corresponden con la gravedad y la probabilidad del riesgo, tal como se muestra en la imagen a continuación.

  • Grave
  • Alto
  • Media
  • Bajo

Mapa de la matriz de evaluación de riesgosping Probabilidad frente a gravedad en bandas de prioridad grave, alta, media y baja

Grave: Los riesgos que se incluyen en esta categoría están marcados en ámbar. La actividad debe detenerse y deben tomarse medidas inmediatas para aislar el riesgo. Deben identificarse e implementarse controles eficaces. Además, la actividad no debe continuar a menos que el riesgo se reduzca a un nivel bajo o medio.

Alta: Los riesgos que se incluyen en esta categoría están marcados en rojo y requieren una acción inmediata o una estrategia de gestión de riesgos. Es necesario actuar de inmediato para aislar, eliminar o sustituir el riesgo e implementar controles de riesgo eficaces. Si estos problemas no pueden resolverse de inmediato, se deben definir plazos estrictos para su solución.

Media: Los riesgos que entran en esta categoría están marcados en amarillo. Deben adoptarse medidas razonables y prácticas para minimizarlos.

Bajo: Los riesgos que entran en esta categoría están marcados en verde y, por lo general, pueden aceptarse, ya que no representan un problema significativo. Sin embargo, es imprescindible realizar una revisión periódica para garantizar que los controles sigan siendo eficaces.

Lista de verificación genérica para pruebas basadas en riesgos

La matriz determina cómo se clasifica un riesgo. La lista de verificación que aparece a continuación determina qué candidatos se incluyen en la matriz.

  • Funcionalidades importantes en el proyecto.
  • Funcionalidad visible para el usuario en el proyecto.
  • La funcionalidad que tiene el mayor impacto en la seguridad.
  • Funcionalidades que tienen el mayor impacto financiero en los usuarios.
  • Áreas de código fuente muy complejas y código propenso a errores.
  • Características o funciones que se pueden probar al principio del ciclo de desarrollo.
  • Características o funcionalidades que se añadieron al diseño del producto en el último momento.
  • Factores críticos de proyectos anteriores similares o relacionados que causaron problemas.
  • Factores o problemas primordiales de proyectos similares o relacionados que tuvieron un gran impacto en los gastos de operación y mantenimiento.
  • Requisitos deficientes que dan lugar a diseños y pruebas deficientes, lo que podría tener un impacto en los objetivos y entregables del proyecto.
  • En el peor de los casos, un producto podría ser tan defectuoso que no se pueda reparar y deba desecharse por completo, lo que dañaría gravemente la reputación de la empresa. Identifique qué tipo de problemas son cruciales para los objetivos del producto.
  • Situaciones o problemas que provocarían quejas persistentes de servicio al cliente.
  • Pruebas integrales que podrían centrarse fácilmente en múltiples funcionalidades del sistema.
  • El conjunto óptimo de pruebas que permite maximizar la cobertura de riesgos.
  • ¿Qué pruebas ofrecerán la mejor relación entre la cobertura de alto riesgo y el tiempo requerido?

Informes y métricas de resultados de pruebas basadas en riesgos

  1. Preparación del informe de la prueba. Informar sobre el estado de las pruebas consiste en comunicar eficazmente los resultados a las partes interesadas del proyecto, proporcionando una comprensión clara y mostrando la comparación de los resultados con los objetivos de las pruebas.
    • Número de casos de prueba planificados frente a los ejecutados.
    • Número de casos de prueba superados o fallidos.
    • Número de defectos identificados, su estado y su gravedad.
    • Número de defectos críticos aún sin resolver.
    • Tiempos de inactividad del sistema, si los hubiera.
    • Si los hay, son eventos que ponen los pelos de punta.
    • Informe resumido de la prueba y prueba de cobertura .
  2. Preparación de métricas. Una métrica es una combinación de dos o más medidas que se utilizan para comparar procesos, proyectos y productos de software.
    • Variaciones en el esfuerzo y el cronograma.
    • Productividad en la preparación de casos de prueba.
    • Cobertura del diseño de pruebas.
    • Productividad en la ejecución de casos de prueba.
    • Eficiencia en la identificación de riesgos %.
    • Eficiencia en la mitigación de riesgos %.
    • Eficacia de la prueba %.
    • Cobertura de ejecución de pruebas.
    • Productividad en la ejecución de pruebas.
    • Porcentaje de fugas defectuosas.
    • Eficiencia en la detección de defectos y densidad de defectos.
    • Índice de estabilidad de los requisitos.
    • Costo de la calidad.

Esas medidas se comparan luego con los riesgos:

  • Analizar los riesgos en categorías no funcionales (rendimiento, fiabilidad y usabilidad) en función del estado de los defectos y del número de resultados de pruebas superadas o fallidas, en relación con los riesgos.
  • Analizar los riesgos en categorías funcionales utilizando métricas de prueba, estado de defectos y estado de aprobación o rechazo de las pruebas, en relación con los riesgos.
  • Identificar los indicadores clave de anticipación y de retraso, y crear indicadores de alerta temprana.
  • Supervisar e informar sobre los indicadores de riesgo adelantados y rezagados (Indicadores Clave de Riesgo) mediante el análisis de los patrones de datos, las tendencias y las interdependencias.

Evaluación de riesgo inherente versus evaluación de riesgo residual

La identificación y el análisis de riesgos también deben incluir los riesgos inherentes, los riesgos residuales, los riesgos secundarios y los riesgos recurrentes.

  • Riesgo inherente: Los riesgos que se identificaron o que ya estaban presentes en el sistema antes de la implementación de los controles y las respuestas. Los riesgos inherentes también se conocen como riesgos brutos.
  • Riesgo residual: Los riesgos que quedan después de que se hayan implementado los controles y las respuestas. Los riesgos residuales se conocen como riesgos netos.
  • Riesgo secundario: El nuevo riesgo derivado de la implementación del plan de respuesta ante riesgos.
  • Riesgo recurrente: La probabilidad de que los riesgos iniciales se repitan.

La medición de los resultados de las pruebas en función del riesgo ayuda a la organización a conocer el nivel residual de riesgo de calidad durante la ejecución de las pruebas y a tomar decisiones informadas sobre el lanzamiento de los productos.

Perfiles de riesgo y comentarios de los clientes

La elaboración de perfiles de riesgo es un proceso para encontrar el nivel óptimo de riesgo de inversión para el cliente, considerando el riesgo requerido, la capacidad de riesgo y la tolerancia al riesgo.

  1. Riesgo requerido es el nivel de riesgo que el cliente necesita asumir para obtener una rentabilidad satisfactoria.
  2. Capacidad de riesgo es el nivel de riesgo financiero que el cliente puede permitirse asumir.
  3. Tolerancia al riesgo es el nivel de riesgo que el cliente estaría dispuesto a asumir.

Comentarios de los clientes: Recopilar comentarios y reseñas de los clientes para mejorar el negocio, el producto, el servicio y la experiencia.

Beneficios de las pruebas basadas en riesgos

A continuación se detallan los beneficios de las pruebas basadas en riesgos.

  • Mayor productividad y reducción de costes.
  • Mayor oportunidad de mercado (menor tiempo de comercialización) y entrega puntual.
  • Mejora del rendimiento del servicio.
  • Mejora de la calidad, ya que se prueban todas las funciones críticas de la aplicación.
  • Información clara sobre la cobertura de las pruebas. Con este método, el equipo sabe qué se ha probado y qué no.
  • La asignación del esfuerzo de prueba basada en la evaluación de riesgos es la forma más eficiente y eficaz de minimizar el riesgo residual tras la liberación.
  • La medición de los resultados de las pruebas, basada en el análisis de riesgos, permite a la organización identificar el nivel residual de riesgo de calidad durante la ejecución de las pruebas y tomar decisiones informadas sobre el lanzamiento de los productos.
  • Pruebas optimizadas con métodos de evaluación de riesgos claramente definidos.
  • Mayor satisfacción del cliente, gracias a la participación del cliente y a una buena comunicación y seguimiento del progreso. tracRey.
  • Detección temprana de posibles áreas problemáticas, para poder tomar medidas preventivas eficaces.
  • La supervisión y evaluación continua de los riesgos a lo largo de todo el ciclo de vida del proyecto ayuda a identificar y resolver los riesgos, así como a abordar los problemas que podrían poner en peligro el logro de los objetivos generales del proyecto.

Preguntas Frecuentes

Un riesgo de producto es un defecto que podría afectar al usuario, como un problema con el proceso de pago. Un riesgo de proyecto amenaza la entrega en sí: una habilidad faltante, un entorno defectuoso, un requisito inestable. Las pruebas abordan los riesgos de producto directamente y los riesgos de proyecto solo indirectamente.

La evaluación se convierte en una actividad breve y recurrente en lugar de un documento único. En cada sprint, el equipo vuelve a calificar las historias que está a punto de construir, por lo que el registro de riesgos se actualiza. tracks el backlog en lugar de un plan de lanzamiento escrito meses antes.

Las puntuaciones son estimaciones, por lo que un riesgo que nadie había previsto queda totalmente excluido. Las zonas con baja calificación también pueden deteriorarse gradualmente a lo largo de varias actualizaciones. Las sesiones exploratorias periódicas fuera del registro son la medida de seguridad habitual para evitar ambos puntos ciegos.

La evaluación realizada únicamente por los evaluadores tiende a centrarse en el riesgo técnico. Una sesión útil combina la participación de un analista de negocio o propietario del producto para evaluar el impacto, un desarrollador para analizar la complejidad y el historial de cambios, y un evaluador para determinar la probabilidad, con apoyo para resolver desacuerdos.

Los modelos de aprendizaje automático clasifican los módulos utilizando datos históricos de defectos, cambios en el código, métricas de complejidad y frecuencia de cambios extraídos del control de versiones y los problemas. tracrey. El resultado es una clasificación inicial que un humano aún revisa, porque el impacto comercial no es visible en el repositorio.

Copiloto de GitHub Puede elaborar registros, fórmulas de exposición y objetivos de prueba candidatos a partir de la descripción de los requisitos, y generar casos de prueba para los elementos con mayor puntuación. Las decisiones sobre la probabilidad y la gravedad siguen siendo decisiones humanas.

Los sectores regulados mantienen el mismo modelo de puntuación, pero añaden un registro documental: cada riesgo, su justificación, las pruebas que lo evalúan y la aprobación se conservan para su auditoría. Solo se permite reducir la prioridad de un riesgo cuando la justificación está documentada.

Se vuelve a puntuar cada vez que cambie algún factor que haya influido en la puntuación: un nuevo requisito, una refactorización importante, un incidente en producción o un grupo de defectos en un área con una puntuación baja. En la práctica, los equipos revisan la puntuación al final de cada sprint y de nuevo antes de tomar una decisión sobre el lanzamiento.

Resumir este post con: