Liderazgo en pruebas: Pruebas basadas en riesgos
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor de pruebas de software Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente aquellos en equipos ágiles—a sobresalir en sus roles de liderazgo y gestión de pruebas.
En el artículo anterior analizamos la importancia de los modelos de prueba. Aquí, profundizaremos en el concepto de riesgo y ofreceremos un manifiesto de pruebas basadas en riesgos que puedes aplicar a tu propio método de pruebas basadas en riesgos.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando nuevas partes de la serie estén disponibles. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul que recomendamos mucho para profundizar en este y otros temas. Si decides hacerlo, usa nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio completo del curso.
Los riesgos, si se materializan, tienen un efecto adverso en nuestros proyectos. La gestión de riesgos consiste en pensar en qué riesgos existen y tomar acciones para reducir su probabilidad, eliminarlos o disminuir su impacto en las metas de nuestros interesados.
En algunos negocios, la gestión de riesgos se practica con precisión matemática e ingeniería. En software, no es posible ser tan preciso. La mayoría de las organizaciones aún no practican las pruebas basadas en riesgos de forma sistemática. Pero hay una buena razón para esto: una vez identificados, los riesgos de producto de software suelen ser tremendamente difíciles de evaluar.
Desde la perspectiva de pruebas y aseguramiento, un riesgo es un ‘modo de fallo al que hay que prestar atención’. Las pruebas basadas en riesgos son la práctica de modelar posibles modos de fallo del sistema como riesgos de producto para apoyar el alcance, escalado y priorización de las pruebas.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
En este artículo ofreceré un manifiesto de pruebas basadas en riesgos. Veremos la gestión de riesgos clásica y cómo podemos ajustarla para que sea útil a los testers. Finalmente, veremos algunas consideraciones y aspectos prácticos que te ayudarán a aplicar tu propio método de pruebas basadas en riesgos.
- Riesgo de Proyecto, Proceso y Producto
- Manifiesto de Pruebas Basadas en Riesgos
- El Enfoque Clásico del Riesgo
- Riesgo de Producto y Pruebas
- Aspectos Prácticos
- El Rol de la Gestión del Riesgo en Pruebas
Utilizaremos esta definición de riesgo: Un riesgo es una amenaza para una o más de las metas de los interesados en un proyecto y tiene una probabilidad incierta.
Riesgo de Proyecto, Proceso y Producto
Existen cientos de libros sobre riesgo y gestión de riesgos que describen numerosos enfoques para gestionar el riesgo a nivel de proyecto. Normalmente, estos enfoques se centran en lo que llamamos riesgos de proyecto y de proceso, con quizás un único riesgo rotulado como ‘fallo para cumplir los requisitos’. Tener un único riesgo de requisito no es muy útil, ya que no es como si pudieras priorizar un riesgo para las pruebas.
Existen tres tipos de riesgo en el software.
Riesgo de proyecto: Estos riesgos están relacionados con el proyecto en su propio contexto. Por lo general, los proyectos tienen dependencias externas como la disponibilidad de habilidades, dependencia de proveedores, plazos fijos o restricciones como un contrato a precio fijo. Las dependencias externas son responsabilidad de la gestión del proyecto.
Riesgo de proceso: Estos riesgos se relacionan principalmente con el funcionamiento interno del proyecto y la planificación, el seguimiento y el control del proyecto están bajo escrutinio. Los riesgos típicos aquí son la subestimación de la complejidad del proyecto, el esfuerzo o las habilidades requeridas. La gestión interna de un proyecto, como una buena planificación, el monitoreo del progreso y el control, son todas responsabilidades de la gestión del proyecto.
Riesgo de producto: El riesgo de producto es el principal área de preocupación para los testers. Estos riesgos están relacionados con la definición del producto, la estabilidad (o falta de ella) de los requisitos, la complejidad del producto y la propensión a fallos de la tecnología.
De ahora en adelante, nos concentraremos en los riesgos de producto. Usaremos el término riesgo de producto del siguiente modo:
Un riesgo de producto representa un modo o patrón de fallo que sería inaceptable en un entorno de producción.
Manifiesto de Pruebas Basadas en Riesgos
En los proyectos donde se asumirán riesgos (que creemos que son todos), los testers deben aportar visibilidad de los riesgos a la gestión y proponer métodos de prueba fiables para abordar estos riesgos a lo largo de un proyecto.
Esta es la tarea de gestión: realizar y/o supervisar las siguientes tareas de pruebas basadas en riesgos:
El enfoque clásico del riesgo
Existen muchas variaciones, pero el enfoque clásico del riesgo intenta ser cuantitativo.
Probabilidad, consecuencia y exposición
Para evaluar un riesgo de producto, necesitamos comprender cuál es la consecuencia de ese modo de falla. Si ocurre una falla, decimos que el riesgo se materializa. Entonces preguntamos “¿qué tan grave es el riesgo?”, también conocido como exposición.
Para calcular la exposición, evaluamos el riesgo en dos dimensiones:
- La probabilidad (o posibilidad) de que un riesgo se materialice. Este valor normalmente se expresa como un porcentaje entre (pero sin incluir) cero y cien por ciento.
- La consecuencia (o impacto o pérdida) de que se materialice un riesgo. Este es el coste potencial del daño si ocurre este modo de falla.
La exposición de un riesgo —qué tan grave es un riesgo— se calcula como el producto de la probabilidad y la consecuencia.
Exposición = Probabilidad del riesgo X Consecuencia del riesgo.
El enfoque clásico del riesgo a menudo carece del soporte tecnológico necesario para una gestión eficiente. Las modernas soluciones de gestión de pruebas llenan este vacío al ofrecer funciones diseñadas para pruebas basadas en riesgos.
Puntuación cuantitativa o cualitativa
Ahora bien, a menudo es difícil predecir el coste potencial de una falla. Sin más información, también es casi imposible predecir con mucha certeza la probabilidad de una falla. Por ello, la mayoría de los profesionales adopta escalas semi-cuantitativas o cualitativas para la probabilidad y la consecuencia.
Es común usar rangos numéricos del uno al cinco para ambas escalas, lo que nos da valores posibles de exposición del uno al veinticinco. Pero pocos testers, desarrolladores o interesados asignan estos números con confianza, por lo que es habitual calificar directamente la exposición al riesgo usando una escala de 1 a 5, o —aún más simple— una valoración roja, ámbar, verde. Algunos llegan a decir simplemente que los riesgos están dentro o fuera de alcance, pero sugerimos que eso es una simplificación excesiva.
Ya sea que cuantifiques o codifiques por colores los riesgos sobre la mesa, el aspecto crítico de las evaluaciones de riesgos no es la puntuación, sino las conversaciones y debates que se generan al asignar y discutir las puntuaciones.
Parafraseando a Eisenhower, el plan de riesgo no es nada, la planificación de riesgos lo es todo.
Si se te pide que puntúes los riesgos con más precisión que escalas del uno al tres (o de cinco, forzando), deberías considerar seriamente si los números que asignas tienen algún valor real.
Una puntuación numérica puede dar la impresión de rigor científico, pero si los números son una suposición, solo te estarás engañando. Si los números exponen diferencias de opinión, por ejemplo, un usuario dice “cinco” y el desarrollador dice ‘¡uno!’, entonces es momento de tener esa conversación, porque claramente las expectativas o percepciones son diferentes.
Cuidado con usar un esquema simple de dentro de alcance/fuera de alcance para los riesgos. Puede quedar claro qué riesgos de interés serán abordados por las pruebas. Sin embargo, los proyectos aprenden y a menudo se retrasan, así que hay que hacer concesiones. Si los riesgos no se priorizan de alguna manera, tendrás que revisar todos los riesgos de interés para decidir cuáles necesitan ser eliminados o añadidos al alcance.
En próximos artículos trataremos en más detalle el alcance, la priorización y la escala, así que mantente atento.
Riesgo de producto y pruebas
La discusión de los riesgos (de producto) dejará en evidencia los temores de los interesados sobre la probabilidad de fallos en áreas críticas del proyecto o sistema. Dada una lista de riesgos del producto, ¿cómo se traduce eso en acciones y planes específicos de prueba? Antes de poder responder a esa pregunta, necesitamos entender un poco mejor cómo las pruebas afectan o influyen en nuestras valoraciones de riesgos.
Las pruebas no reducen el riesgo: informan las valoraciones de riesgos
A menudo escucharás a la gente sugerir que "las pruebas reducen el riesgo". Eso no es verdad — las pruebas a veces pueden aumentar el riesgo. El mantra de que las pruebas reducen el riesgo nace de la falta de comprensión tanto de los riesgos como de las pruebas.
Supongamos que hemos identificado un riesgo de que una función o característica falle. Formulamos una prueba y la ejecutamos. La prueba puede pasar o puede fallar. ¿Cómo afectaría que la prueba pase o falle a nuestra valoración del riesgo?
Primero, las pruebas no afectan nuestra comprensión de la consecuencia de una falla. La consecuencia de una falla es la que es y la prueba no la cambia.
Hay cuatro resultados relevantes de una prueba y su impacto en la probabilidad de riesgo. Estos se resumen en la siguiente tabla:
| Aumenta la probabilidad de riesgo | Disminuye la probabilidad de riesgo | |
| Prueba pasa | No. Una prueba superada solo puede hacernos sentir más seguros de que un modo de fallo no ocurrirá. (Esto supone que nuestras pruebas sean significativas). | Sí, eventualmente. A medida que ejecutamos más y más pruebas que pasan y exploramos escenarios diversos, la probabilidad de fallo disminuye. |
| Prueba falla | Posiblemente, dependiendo del fallo. Pero la probabilidad disminuye con el tiempo. Hemos predicho que este modo de fallo ocurriría; nuestra elección de prueba está justificada. Afortunadamente, ahora podemos corregir esto y enfocar nuestras pruebas para reducir el riesgo de otros fallos de este tipo. | No es probable, a menos que hayamos evaluado mal el riesgo. |
Ejecutar pruebas que asociamos con un riesgo particular nos brinda cada vez más información para perfeccionar nuestra evaluación de riesgos. Si las pruebas fallan, nuestra elección está justificada. Cuando corregimos y volvemos a probar, a medida que las pruebas pasan nuestra valoración del riesgo debería reducirse. Pero si seguimos encontrando nuevos/más errores, podríamos reevaluar el riesgo como mayor.
Considera esto: si ejecutas una prueba y el resultado no afecta tu valoración de probabilidad en ningún sentido, probablemente esa prueba no sirva para nada.
Ahora que comprendes el potencial de las pruebas para informar nuestra evaluación de riesgos, podemos pasar a especificar pruebas a partir de descripciones de riesgos.
Planificación de pruebas basada en riesgos
Como testers, una vez que hemos identificado un riesgo de producto que nos preocupa, debemos formular un conjunto de pruebas que demuestren que ese modo de fallo es menos probable. Obviamente, nuestro enfoque será estimular el modo de fallo de tantas formas como podamos y, haciendo esto, lograremos:
- Experimentar fallos, detectar errores y corregirlos (reduciendo el riesgo de ese modo de fallo) o
- Obtener resultados satisfactorios y aumentar nuestra confianza en que un modo de fallo es menos probable.
Nuestras pruebas, en conjunto, se enfocan en las formas en que puede ocurrir un modo de fallo seleccionado. Supongamos, por ejemplo, que el riesgo fuera ‘falla en calcular correctamente una prima de seguro de autos’. En este caso, un objetivo de prueba apropiado podría ser ‘demostrar usando la técnica de todos los pares para variables de entrada que el sistema calcula correctamente la prima del seguro de autos’. Este objetivo de prueba se puede asignar a un tester para que derive un conjunto representativo de casos de prueba usando la técnica de todos los pares, por ejemplo.
Practicidad
Ahora veamos algunas consideraciones prácticas relacionadas con las pruebas basadas en riesgos.
¿Qué sucede si los interesados no están interesados en ayudar con la evaluación de riesgos?
Puedes hallar que es difícil obtener el tiempo de los interesados para que te ayuden a identificar y evaluar riesgos y formular tu plan de pruebas.
¿Qué sucede si hay múltiples opciones de prueba para un riesgo de producto?
Esto, por supuesto, ocurre casi siempre. Por ejemplo, para probar una funcionalidad preocupante puedes usar alguna de una variedad de técnicas de diseño de pruebas, o modelar la funcionalidad de alguna manera única y derivar pruebas de ese modelo. Existen diversas medidas de cobertura que podrías emplear para fijar un objetivo. Puedes probar una función manualmente o utilizando una herramienta u otra tecnología.
Veremos cómo podrías tomar decisiones en el próximo artículo, ‘¿Cuántas pruebas son suficientes?’.
¿Y si las pruebas (para abordar un riesgo) son demasiado costosas?
Ya que casi siempre hay opciones, y no hay un límite a cuántas pruebas podrías aplicar para explorar un riesgo y fundamentar una evaluación de riesgos, hay que tomar una decisión. Por supuesto, algunas opciones serán consideradas demasiado caras. Así que, cuando presentes opciones a los interesados, deberás tener al menos una opción que sea asequible y otra que podría no serlo.
Nuevamente: veremos cómo podrías tomar decisiones en el próximo artículo, ‘¿Cuántas pruebas son suficientes?’
Si probamos más las funcionalidades de alto riesgo, ¿probamos menos otras funciones?
Si el presupuesto para pruebas está predefinido para un equipo, o el tamaño del equipo y la cantidad de testers es fija, entonces la cantidad de pruebas que puede realizar la gente es limitada (dentro de un periodo de tiempo establecido). Así que, si ponemos más énfasis en algunas funciones, la cantidad de pruebas en otras debe reducirse. La cobertura, o al menos el esfuerzo sobre las funciones, varía en función del riesgo.
La forma de verlo es que cuando una prueba falla y se detecta un error en el sistema, la gravedad asignada a ese error suele estar muy relacionada con la consecuencia de ese fallo (en producción). Los errores más graves se corrigen porque simplemente son más importantes para los interesados.
Un análisis de riesgos de producto resalta las áreas donde los errores, por ser importantes, son más propensos a corregirse. Por lo tanto, usar un análisis de riesgos para resaltar dónde se realizan pruebas y/o dónde se aplican más pruebas, significa que es más probable que detectemos errores importantes y menos probable que hallemos errores en funcionalidades que quizás no sean tan relevantes para los interesados.
Sería bueno pensar que a veces podemos probar todo de manera más uniforme. Pero cuando los recursos y el tiempo son limitados (y siempre lo son, ¿verdad?), un enfoque basado en riesgos te ayuda a utilizar el tiempo del tester de forma más eficaz y eficiente.
¿Y si probar no es la respuesta adecuada?
Antes de que dediques tiempo a definir un enfoque de pruebas para un riesgo de producto con detalle, es importante considerar también las opciones que no implican pruebas. Por ejemplo, supongamos que existe una gran preocupación de que un componente del sistema no funcione lo suficientemente bien en producción y los tiempos de respuesta o la fiabilidad sean deficientes. Por supuesto, podrías realizar pruebas de carga e intentar depurar los problemas. Pero otras opciones podrían ser:
- Comprar el componente a un tercero en lugar de desarrollarlo y asumir el riesgo.
- Rearquitectar la solución para distribuir la carga entre varias instancias del componente.
- Desviar el procesamiento a un sistema por lotes sobre una copia de los datos.
- En lugar de implementar un despliegue para todos los usuarios de una sola vez, adoptar un enfoque gradual implementando clientes por regiones y monitorizando el rendimiento de cerca.
- Y así sucesivamente.
A menudo, tomar una medida diferente para prevenir problemas suele ser más efectivo y económico que probar para encontrarlos posteriormente.
Comprendiendo el rol de la gestión de riesgos en las pruebas
Las pruebas pueden reducir el riesgo en una liberación. Si utilizamos una evaluación de riesgos para orientar nuestra actividad de prueba, el objetivo de los testers se vuelve explícito: diseñar pruebas para detectar fallos que puedan corregirse y, al hacerlo, reducir el riesgo de entregar un producto defectuoso.
La detección de fallos reduce el riesgo residual de fallos en producción, donde los costes aumentan considerablemente. Cuando una prueba encuentra un fallo y se corrige, el número de errores disminuye y, en consecuencia, la probabilidad global de fallo también se reduce.
También podría verse de esta manera: el ‘micro-riesgo’ derivado de ese fallo se elimina. Pero no debe olvidarse que las pruebas no pueden encontrar todos los fallos, por lo que siempre existirán errores latentes sobre los que la prueba no ha proporcionado información directa.
Sin embargo, si nos enfocamos en las características críticas y detectamos fallos en éstas, es menos probable que queden fallos sin detectar en dichas características críticas. Los fallos que quedan en las funcionalidades no críticas del sistema tienen una menor consecuencia.
Una nota final: el proceso de análisis de riesgos en sí mismo conlleva riesgos. El análisis de riesgos puede tanto sobrestimar como subestimar los riesgos, lo que lleva a tomar decisiones menos que perfectas. Un análisis de riesgos llevado demasiado lejos puede incluso contribuir a una cultura de culpabilización.
Entre otros posibles inconvenientes del análisis de riesgos, debes comprender que no existe el riesgo absoluto que pueda calcularse una vez finalizado el proyecto. La naturaleza de los riesgos es incierta. Al igual que ocurre con la eficacia de las pruebas, el valor de un análisis de riesgos sólo puede determinarse a posteriori, una vez terminado el proyecto.
Y eso es todo para nuestro manifiesto de pruebas basadas en riesgo. El concepto volverá a aparecer a lo largo de la serie Leadership in Test, ¡así que estate atento a más artículos!
Apúntate al boletín de The QA Lead para recibir una notificación cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Leadership In Test de Paul, que recomendamos mucho para profundizar en este y otros temas. Si te animas, usa nuestro cupón exclusivo QALEADOFFER y consigue $60 de descuento en el precio total del curso.
