«¿Cuál es el riesgo de salir el jueves?»
La preguntó el gerente de producto mirando a toda la sala. Y la sala te miró a ti, porque eres QA y esa pregunta se supone que es tuya.
Dijiste lo que digo yo, y lo que dice cualquiera que conozca bien su suite: «todavía faltan pruebas». Y viste cómo la cara del otro lado no se movía ni un milímetro. No porque no te creyera. Porque con eso no puede hacer nada.
Si te pasó, el problema no fue tuyo: la pregunta estaba mal hecha. «¿Cuál es el riesgo?» es tan amplia que no tiene una respuesta buena, y quien la hace casi nunca sabe qué está pidiendo. Tú tenías la información. Lo que faltaba era el formato en el que esa persona podía usarla — y ese formato, si no lo pones tú, no lo pone nadie.
Esta es la parada 01 de una serie de cuatro sobre gestión de riesgos para QA. Hoy: qué es, por qué esa pregunta está mal formulada, y cómo se contesta sin inventar. Al final hay dos secciones que puedes saltar según quién seas: una para quien lidera el equipo y otra para quien está en esa reunión sin ser QA —esa está escrita para que se la reenvíes—. Después vienen la disciplina, la matriz para cuando son doce riesgos y no uno, y dónde entra la IA sin meter humo.
Te piden evidencia de algo que todavía no pasó
Un bug ya pasó. Está ahí, lo reproduces, lo grabas, lo pegas en el ticket. Tu profesión entera está construida alrededor de demostrar cosas que ya ocurrieron.
Un riesgo todavía no pasó. Puede que no pase nunca.
Tu oficio se apoya en demostrar. La pregunta te pide estimar. Cambia el tipo de prueba que tienes que dar, y eso no viene aclarado en la pregunta.
Por eso «faltan pruebas» es la respuesta prudente: es cierta, es honesta y no compromete a nada que no puedas sostener. El problema es otro. Describe tu trabajo pendiente, no la decisión que el otro tiene que tomar — y él está preguntando por la decisión.
La buena noticia: ya lo haces todos los días
Te quedan dos días y treinta casos de prueba. No te alcanza. Eliges catorce.
Nadie te dio una fórmula para elegir esos catorce. Los elegiste igual, y probablemente bien, cruzando dos cosas en la cabeza sin ponerles nombre: qué tan probable es que esta zona se rompa y cuánto dolería si se rompe.
Eso es gestión de riesgos. Lo vienes haciendo desde tu primer sprint.
Lo que te falta no es el criterio. Es poder sacarlo de tu cabeza en un formato que otra persona pueda revisar, discutir y firmar.
Mientras vive solo en tu instinto, tu criterio es intransferible. Y un criterio intransferible no se puede defender en una reunión, no se puede delegar en alguien más junior, y no sirve para justificar por qué el release espera.
Eje 1 — Probabilidad
La probabilidad no es un porcentaje que te inventas. Es una lectura de evidencia que ya tienes.
Las cuatro preguntas que la responden
¿Es código nuevo o código que se tocó? El código que nadie tocó en ocho meses y funciona no es donde está tu riesgo. Está en lo que se movió esta semana.
¿Cuántas veces falló esta zona antes? Abre el historial de bugs por módulo. Las zonas tienen memoria: la que te dio problemas tres veces te va a dar una cuarta. Si nadie en tu equipo lleva ese registro, empezar a llevarlo es el trabajo de una tarde y te cambia todas las conversaciones de los próximos seis meses.
¿Cuántos sistemas cruza? Cada integración es un punto donde alguien puede cambiar algo sin avisarte. Un flujo que toca tres servicios y un proveedor externo tiene cuatro dueños, y solo uno eres tú.
¿Lo entiende una sola persona del equipo? El conocimiento concentrado en una cabeza es riesgo, aunque el código sea impecable. Si esa persona está de vacaciones el jueves, la probabilidad de que algo se rompa y nadie sepa por qué sube sola.
Ninguna de las cuatro te da un número, y no lo necesitas. Te dan motivos.
Mira la diferencia entre estas dos respuestas:
«Yo creo que es riesgoso» se contesta con «yo creo que no», y ahí la conversación se acabó.
«Es riesgoso porque ese módulo se tocó esta semana, ya falló tres veces este año y lo entiende una sola persona» obliga a quien no esté de acuerdo a decir cuál de esas tres cosas es falsa.
Lo segundo se puede revisar. Lo primero, no.
Eje 2 — Impacto
El error más común es creer que impacto significa «qué tan roto queda el sistema».
Impacto es a quién le duele, cuánto le duele y por cuánto tiempo.
La primera describe el sistema. La segunda describe una consecuencia que alguien que no lee código puede evaluar. Y no hace falta saber más para escribirla: hace falta terminar la frase.
Un detalle que cambia prioridades: un fallo que afecta al 2% de los usuarios puede tener más impacto que uno que afecta al 100%. Si ese 2% es el que paga, o el que tiene un contrato firmado con penalización, o el que se va a ir a Twitter, el porcentaje no te dice nada por sí solo.
Eje 3 — El que casi nadie nombra: la detección
En ISTQB y en la mayoría de los manuales el riesgo se calcula con esos dos ejes: probabilidad e impacto. Y así quedó en la cabeza de todo el mundo.
Pero hay otra forma de mirarlo, y viene de fuera del software.
Se llama FMEA — Failure Mode and Effects Analysis, análisis de modos de fallo y sus efectos. Nació en 1949 en una norma militar estadounidense, se usó en el programa Apollo de la NASA y terminó de volverse estándar en la industria automotriz después de que a Ford le explotara el tanque de combustible del Pinto en choques traseros. Setenta y cinco años analizando qué puede fallar en cosas donde fallar se paga muy caro.
FMEA puntúa cada fallo posible con tres factores, no dos:
- Occurrence — cada cuánto pasa. Es el eje 1, probabilidad.
- Severity — cuánto duele si pasa. Es el eje 2, impacto.
- Detection — si pasa, ¿lo vas a ver?
Los dos primeros son los que acabas de leer, en inglés. El tercero es el que el software dejó por el camino.
La pregunta es esta:
Si esto falla, ¿cómo nos enteraríamos?
El monitoreo, las alertas y lo que corre en cada pipeline son territorio tuyo: nadie más en esa sala sabe qué se detecta hoy y qué no. Y casi nunca te lo preguntan.
Piénsalo con dos riesgos idénticos en los otros dos ejes:
Misma probabilidad, mismo impacto, y son dos decisiones completamente distintas. El primero se puede asumir un jueves. El segundo no, aunque el número que sale de multiplicar los otros dos ejes sea exactamente igual.
Los otros dos ejes te obligan a opinar sobre el futuro, que es terreno incómodo. La detección se responde con hechos del presente: qué monitoreo hay, qué alerta existe, qué test corre en el pipeline. Es donde puedes hablar con certeza, y de ahí sale el peso de lo que digas en los otros dos ejes.
Un caso concreto
El equipo va a cambiar el proveedor que manda los SMS de verificación. La migración está lista y quieren salir el jueves.
Lo que dirías por instinto: «no me da tiempo de probar todo».
Lo que dicen los tres ejes:
Qué puede salir mal. Que el proveedor nuevo entregue el SMS más lento, o directamente no lo entregue, en las operadoras que menos usamos.
Probabilidad: alta. Es un proveedor que nunca corrió en producción con nuestro tráfico, cruza un sistema externo que no controlamos, y en las pruebas solo se probó con dos operadoras de las seis que tienen nuestros usuarios.
Impacto: alto, y concreto. Un usuario que no recibe el SMS no puede terminar de registrarse. No abre un ticket: cierra la app. No lo vemos como bug, lo vemos como una caída del registro que alguien va a atribuir al diseño de la pantalla.
Detección: mala, y esto es lo que cambia la decisión. No hay ninguna alerta que se dispare cuando un SMS no llega. El proveedor nos devuelve «enviado» y ahí termina nuestra visibilidad. Nos enteraríamos por el reporte mensual de registros, que sale el día 5.
Ahora la pregunta ya no es «¿salimos el jueves?». Es otra, y la puede contestar quien tiene que contestarla: ¿salimos el jueves con una alerta de tasa de verificación exitosa, o salimos sin ella y aceptamos enterarnos en diecisiete días?
Eso no es pedir más tiempo. Es poner la decisión sobre la mesa con sus costos a la vista.
Qué significa de verdad el número de la matriz
En algún momento alguien te va a mostrar una matriz con números del 1 al 5 en cada eje, multiplicados entre sí. Probabilidad 4 × impacto 5 = 20. Riesgo alto.
La matriz sirve, y bastante. Ordena, deja registro de lo que se decidió y obliga a que todo el equipo puntúe con el mismo criterio en vez de con el humor del día. Vale la pena usarla.
Lo que conviene tener claro es qué clase de número es ese 20. Multiplicar tres estimaciones no las convierte en una medición: el resultado hereda toda la incertidumbre de las tres, solo que ahora se ve prolijo.
El descuido más común viene justo después. Un número redondo cierra la conversación antes de tiempo, y nadie llega a preguntar de dónde salió el 4. Es la misma idea de la rúbrica para juzgar una suite de tests: un puntaje sin evidencia es una opinión disfrazada.
El número no mide el riesgo. Sirve para que dos personas que puntuaron distinto descubran en cuál de los tres ejes está el desacuerdo.
Cuando tú pones probabilidad alta y el desarrollador pone baja, la discusión útil no es sobre el promedio. Es sobre qué sabe él de ese código que tú no sabes, o al revés. La matriz vale por la conversación que fuerza, no por el resultado.
Las tres frases
Si te quedas con una sola cosa de este artículo, que sea esta. La próxima vez que te pregunten por el riesgo, contesta tres frases en este orden:
- Qué puede salir mal, con sujeto y verbo. No una categoría («riesgo de integración»), una escena («el SMS no llega en las operadoras chicas»).
- A quién le duele y cuánto. Termina la frase hasta la consecuencia, no hasta el síntoma.
- Cómo nos enteraríamos. Con lo que existe hoy, no con lo que deberíamos tener.
Tres frases. No necesitas una plantilla, ni una herramienta, ni permiso de nadie para usarlas mañana.
La primera vez que las digas completas vas a notar que la conversación cambió de tema: ya no se discute si QA necesita más tiempo, sino qué está dispuesto a aceptar el equipo.
Si lideras el equipo, esto es otra conversación
Todo lo de arriba te sirve para contestar tú. Si tienes gente a cargo, tu trabajo es otro: que no dependa de que la persona con más años sea la que esté en esa reunión.
Tres cosas que sí puedes mover esta semana.
Conviértelas en plantilla, no en habilidad. Mientras las tres frases sean algo que tú haces bien, cada decisión de riesgo depende de que estés tú en esa reunión. Ponlas como tres campos fijos ahí donde tu equipo ya reporta: la plantilla del ticket, el acta del refinamiento, el mensaje con el que se avisa que algo sale a producción.
Un QA con un año de experiencia puede completar tres campos. Lo que no puede es construir el análisis entero de memoria mientras un gerente espera la respuesta. La plantilla le da por dónde empezar, y a ti te saca de tener que estar en todas las reuniones.
Empieza a llevar el registro de fallos por módulo. Es el trabajo de una tarde y es lo único que convierte el eje de probabilidad en un dato en vez de una opinión. Sin ese registro, cada discusión de riesgo empieza de cero y la gana quien habla más fuerte.
Adúeñate del tercer eje como área. La detección no es una respuesta que se improvisa en la reunión: es el inventario de qué monitoreas, qué alerta existe y qué corre en el pipeline. Si tu equipo lo tiene mapeado, dejas de opinar sobre el futuro y empiezas a informar sobre el presente.
Un equipo maduro en riesgo no es el que acierta más. Es el que puede explicar por qué decidió lo que decidió, seis meses después, cuando alguien pregunta.
Si no eres QA y estás en esa reunión
Esta sección es para reenviar. Si eres quien pregunta —product manager, tech lead, quien firma la salida— hay algo que conviene que sepas: casi siempre estás haciendo la pregunta equivocada.
«¿Está todo probado?» y «¿cuál es el riesgo?» son preguntas que no tienen respuesta útil. La primera se contesta sí o no y las dos mienten. La segunda es tan amplia que el otro no sabe por dónde entrar.
Pregunta estas tres, en este orden:
La tercera te dice si estás decidiendo con red o sin red. Un riesgo que se detecta en dos minutos y se revierte es un riesgo que puedes asumir un jueves; el mismo riesgo, si te enteras por un cliente tres semanas después, no lo es — aunque en el papel tengan el mismo puntaje.
Una cosa más. Cuando tu QA dice que algo es riesgoso, no te está pidiendo más tiempo. Te está diciendo que hay una decisión que alguien tiene que tomar, y que no le corresponde a él. Tomarla es tu trabajo. Ponerla sobre la mesa con sus costos visibles es el suyo.
La próxima parada
Ya sabes contestar. Falta lo otro: qué haces con la respuesta.
En la parada 02 sale de esta reunión y recorre las demás. El riesgo no vive en el refinamiento: pasa por las seis ceremonias y en cada una hace algo distinto — en el daily aparecen los que se llevan el sprint por delante, y en la retro se calibra tu criterio. Ahí también están las cuatro respuestas posibles a un riesgo, que no son «probar más».