Por Darío Ochoa, ingeniero de control de calidad de Distillery
Llevo bastantes años trabajando como QA, en proyectos de todo tipo. Con el tiempo, no dejo de preguntarme ¿Por qué necesitamos pruebas? ¿Realmente lo necesitamos? ¿Estoy aportando valor como GC?
Luego veo videojuegos que se cuelgan el día del lanzamiento con las acciones más básicas, aviones que pierden una puerta en pleno vuelo, teléfonos móviles que explotan o incluso carteros que son detenidos por error. Son recordatorios de que cuando faltan pruebas, las consecuencias pueden ser graves.
La verdad es que, en el software -como en la vida-, lo que realmente necesitamos es equilibrio.
“La invencibilidad reside en la defensa; la posibilidad de victoria, en el ataque”. – Sun Tzu
Como QAs, jugamos a la defensiva, nos centramos en el porqué. Si dependiera de nosotros, los productos se lanzarían con casi cero fallos… pero sólo después de años de pruebas. Los desarrolladores, en cambio, son los que hacen las jugadas, los quarterbacks: se centran en el cómo, en crear funciones y avanzar. Los Propietarios de Producto y los Analistas de Negocio se centran en el qué, y a la Dirección le importa más el cuándo.
Cada perspectiva es válida, pero cuando una pesa más que las otras, se produce un desequilibrio. Si la defensa desaparece, los errores se cuelan. Si la dirección lo anula todo, los plazos vencen a la calidad. Cada parte debe llegar a un compromiso mediante una discusión equilibrada. Es la única forma de que los proyectos tengan éxito.
“Tanto los optimistas como los pesimistas contribuyen a la sociedad: el optimista inventa el avión, el pesimista el paracaídas”. – George Bernard Shaw
En cuanto a las pruebas, creo que puedo argumentar su valor y participar en esa guerra por el equilibrio. Creo que necesitamos las pruebas porque son aburridas, lentas y añaden más tareas. Me explico. Todos los demás están jugando al ataque, y cuando añades una tarea para probar algo, todos los demás te miran como diciendo: “¿Por qué nos retrasas? “Ya he comprobado el código, funciona, ¿por qué añadir más pruebas?”, y a veces tienen razón. Pero si nosotros, como QAs, no desafiamos eso, si no hacemos más preguntas, entonces no tendríamos defensa, si nuestra visión no forma parte de ese equilibrio, seguramente pronto tendremos problemas.
Los desarrolladores quieren construir, no guardar pruebas ni explorar casos límite, y eso está bien. La dirección quiere las cosas ahora, no después de otra ronda de pruebas. Las pruebas suelen parecer más lentas, menos emocionantes y a veces impopulares, pero es porque son una inversión.
Eso hace que la GC sea una función difícil: tenemos que convencer constantemente a los demás de que la prevención es estratégica, no sólo un obstáculo. Sin defensa, el equipo está totalmente abierto.
“Una onza de prevención vale más que una libra de curación”. – Benjamin Franklin
Cuando los proyectos están llenos de fallos, el valor de la garantía de calidad es obvio. Encuentras defectos, los comunicas y el equipo ve resultados inmediatos. Pero a medida que los equipos maduran y los procesos mejoran, los fallos son más difíciles de encontrar. Irónicamente, es entonces cuando la gente empieza a cuestionarse si la GC sigue siendo necesaria.
Las pruebas se convierten entonces en algo parecido a comer verduras o hacer ejercicio: aburridas, fáciles de pasar por alto, pero esenciales para la salud a largo plazo. Cuando las cosas van bien, parece que no las necesitamos, hasta que vuelven a aparecer los problemas. La prevención es invisible. Pero invisibilidad no significa falta de valor: significa que el sistema está sano.
“Lento es suave, suave es seguro, seguro es rápido”. – Navy SEALs
Un desequilibrio común proviene de una mala interpretación de los marcos de trabajo. Ágil no significa rápido. Ágil significa “capacidad de cambiar de dirección fácilmente”. Se trata de adaptabilidad: cumplir en pequeños incrementos, aprender de las reacciones y ajustarse. Eso no es lo mismo que ir rápido (y menos aún que precipitarse).
Del mismo modo, la metodología Lean no consiste en eliminar todos los procesos. Se trata de mejorarlos, reduciendo los residuos y manteniendo lo que añade valor. Cuando la dirección confunde lean con “recortar gastos”, las pruebas suelen ser lo primero que se recorta. Es entonces cuando se producen fallos evitables, a veces con resultados trágicos, como el desastre del sumergible OceanGate.
La velocidad de un equipo reside más en los procesos y la madurez – un caballo de carreras puede esprintar si se le fuerza, pero sólo puede seguir ganando si se le entrena. La presión da velocidad para un momento; el entrenamiento da velocidad para una carrera .
“Ubuntu: Soy porque somos”.
Al final, la teoría define la estrategia y la realidad exige la táctica. Se necesitan conocimientos y experiencia (y humildad) para poner en marcha marcos de trabajo equilibrados. Para que un proyecto funcione sin problemas, todos los papeles deben respetarse y aprender unos de otros:
- La garantía de calidad defiende la calidad.
- Los desarrolladores construyen el producto.
- Las OP definen la dirección.
- La gestión capacita al equipo.
Sólo cuando estas perspectivas están equilibradas, el desarrollo de software funciona como debería. Las pruebas pueden ser menos visibles, pero sin ellas, el equilibrio se derrumba.
