OKRs para pruebas basadas en riesgos

  • Autor de la entrada:
  • Categoría de la entrada:Agile

¡Hola, Agile Tester! Sabemos que mantener la calidad del software es una de nuestras principales prioridades. Pero, ¿alguna vez te has preguntado cómo  podemos enfocarnos en lo que realmente importa y hacer que nuestras pruebas sean más eficientes y efectivas? Una de las respuestas a esta pregunta es aplicando las Pruebas Basadas en Riesgos (RBT).

Ahora bien, en este artículo trataré de explicarte una herramienta que puedes utilizar para concretar la acción: OKRs

Respecto de los OKRs

En anteriores publicaciones comencé a hacer mención del tema pero aquí te traeré un ejemplo sencillo como para que puedas aterrizar la idea y así, darte algunos elementos para que puedas investigar y hacer tu propio recorrido.

Uno de los principales objetivos es identificar y gestionar los riesgos en nuestros proyectos ágiles. Ahora bien, ¿Se incorporan en las historias de usuarios? ¿Forman parte de los criterios de aceptación? ¿Se encuentra en el ADN de todos los miembros del equipo de proyecto incluyendo al PO? Son preguntas que en algún momento tendrán que tener respuesta.

Te compartiré la idea compartiendo un ejemplo de un sitio que vende paquetes turísticos.

Ejemplo (Básico) de un OKRs

Objetivo 1: Mejorar la Confiabilidad del Proceso de Reserva en el Sitio Web

KR1: Reducir los fallos en el proceso de reserva en un 90%

  • Iniciativa 1: Automatizar las pruebas de reserva para incluir todos los posibles escenarios de usuario, desde reservas simples hasta cambios y cancelaciones.
  • Iniciativa 2: Revisar el código relacionado con el proceso de reserva cada sprint para identificar y corregir errores.
  • Iniciativa 3: Configurar un pipeline de integración continua que ejecute las pruebas de reserva cada vez que se realice un cambio en el código.

KR2: Aumentar la tasa de éxito de las reservas en un 95% durante picos de tráfico

  • Iniciativa 1: Realizar pruebas de carga para simular altas demandas y encontrar cuellos de botella en el rendimiento.
  • Iniciativa 2: Optimizar consultas a la base de datos relacionadas con el proceso de reserva para mejorar la velocidad y eficiencia.
  • Iniciativa 3: Implementar herramientas de monitoreo en tiempo real para detectar problemas de rendimiento y solucionarlos antes de que afecten a los usuarios.

¿El porqué de esta estructura?

La teoría indica que cuando planteamos OKRs debemos definir un claro Objetivo con sus respectivos Resultados Clave (KRs) que deben ser ambiciosos.

Una vez que se hayan definido estos dos aspectos principales, debemos definir las Iniciativas, que al fin y al cabo consistirán en las tareas que deben llevarse a cabo a fin de conseguir lograr el KR correspondiente.

Muy bien, ¿y ahora qué?

A partir de aquí, hay que pensar, evaluar, discutir, analizar, comunicar y ponerse de acuerdo con el equipo de desarrollo, en transmitir cuáles serán todas las actividades que nosotros deberemos llevar a cabo a los efectos de implementar pruebas basadas en riesgos, con todo lo que ello conlleva.

  • Necesidad de datos para recrear ciertas condiciones extremas que se deberán probar.
  • Necesidad de ambiente adecuado, previamente configurado con todos los paquetes de software que requieren ser instalados.
  • Necesidad de contar con un set de casos de prueba acordados entre las partes (desarrolladores y produc owner).
  • Necesidad de haber asignado una cierta prioridad al plan de pruebas que se haya elaborado y compuesto por los test sets que sean necesarios.
  • Necesidad de alguna herramienta que nos permita conducir el testing y tener registro como para armar los dashboards correspondentes que permitan visibilizar el estado del testing (los famosos radiadores de información).

En fin, hay mucho más para tratar pero sirva este contenido como un pequeño adelanto al tema.

¿Te ha interesado? ¿Te sirve? ¿Te hace sentido? ¿Necesitas implementar algo por el estilo? ¿Conocias del tema? ¿No sabes por donde comenzar? ¿No tenías conocimiento acerca de los OKRs?

Ok, ok, por fa, dejame un Like si te parece y un comentario con tus inquietudes en una publicación que se encuentra en LinkedIn también porque me ayudarías y de mucho, y por supuesto, si compartes este artículo y  el de LinkedIn, me super ayudas también.

Gracias por seguirme.

Gus Terrera

Apasionado por el agile testing y la ia.