Partiendo de una realidad, fundamental para la medicina, vamos a demostrar la relevancia de la “estandarización” no sólo en la vida, que como veremos puede salvarlas, sino a la hora de “salvar” la calidad de los proyectos. Por lo que no vas a necesitar ni IA ni chatGPT.
A mediados del siglo pasado, para ser más exactos en la década de los 50, se comprobó que la mortalidad de los recién nacidos en Estados Unidos era muy alta. Prácticamente 1 de cada 30 recién nacidos fallecía. Esta situación cambiaría considerablemente con un método innovador y muy simple introducido por Virginia Apgar.
Si ser mujer médico en una sociedad tan machista como la de entonces era excepcional, ser cirujana ya era un hito. Una de las primeras mujeres en logarlo fue Virginia. De la cirugía pasó a la anestesiología, una actividad relacionada, pero muy diferente, y dentro de esta rama optó por especializarse en los partos donde comenzó a comprobar una realidad terrible detrás de la alta tasa de mortalidad que comprobaba.
En el momento de alumbrar al bebé, el médico evaluaba de forma subjetiva las probabilidades de vida de éste. ¿Tenía malformaciones? ¿Era demasiado pequeño? ¿Presentaba rasgos cianóticos (color azulado)? ¿Respiraba bien?
Sólo se valoraba el criterio del médico era el único válido para decidir que si la respuesta a estas preguntas era pesimista, el bebé no sobreviviría y para evitar sufrimiento adicional a los padres lo mejor era indicar que había muerto en el parto sin prestarle mayor atención. Virginia decidió hacer algo al respecto.
Superando los obstáculos que la época imponía a una mujer Virginia, que además no era tocóloga, decidió afrontar el problema. Decidió definir un método objetivo y fácilmente replicable en todos los partos que ayudara a salvar vidas. Así es como nació el Test de Apgar.
¿En qué consiste el esta prueba? No parece difícil. Consiste en obtener un valor numérico midiendo 5 aspectos simples: frecuencia cardiaca, esfuerzo respiratorio, presencia de reflejos, tono muscular y color. Se hace al minuto y se repite a los cinco minutos determinando con mejor precisión y criterio la salud del bebé y permitiendo salvar las vidas de muchos de los que hoy estamos aquí. Y, en tu proyecto ¿Se podrá salvar su calidad gracias a la estandarización?
La respuesta es, no. Nuestros proyectos no salvan vidas, ni las pierden, pero los proyectos son casi como el alma que hace que nuestras organizaciones evolucionen, crezcan y, muchas veces, “no mueran”. Necesitan que prestemos atención a su vida, para que sea una vida fructífera y llena de valor, de calidad, sin defectos que puedan provocar la degeneración. Por lo tanto, uno de los pilares fundamentales es que un proyecto tenga la calidad adecuada y fundamentada en unos aspectos sencillos y medibles.
Ahora bien, todo esto necesita una dedicación y un esfuerzo que permitan ejecutar unas tareas de pruebas que confirmen la calidad que buscamos. Pero ¿Cómo podemos estimar ese esfuerzo?
En muchas ocasiones el esfuerzo se determina de igual forma en la que los médicos determinaban la viabilidad de vivir de un bebé, sólo guiados por criterios subjetivos basados en su experiencia. Experiencia que sería mejor o peor en función de cada profesional. En proyectos esto se denomina como “Juicio experto”.
No obstante, hay muchos casos en los que la determinación del esfuerzo de pruebas viene de la mano del esfuerzo de desarrollo, esto quiere decir que si, finalmente, para implementar un desarrollo se ha empleado un esfuerzo determinado, el esfuerzo de pruebas será un porcentaje fijo de ese esfuerzo de desarrollo. Cálculo sencillo que será mayor o menor en función de la velocidad de desarrollo.
Ahora bien, podríamos preguntarnos por qué estamos relacionando el tiempo que tarda un desarrollador en implementar algo con el esfuerzo en pruebas. ¿Si el desarrollador es lento se necesitará más tiempo de pruebas?
La verdadera relación está en los bebés cómo determinó Virginia. Está en el objeto de nuestro estudio. Y el objeto de estudio en nuestro caso será el producto que queremos probar.
Tal y como hemos repetido en no pocas ocasiones, realmente, el producto software es el rey y reina con majestuosidad en todos los ámbitos de nuestra vida. Y, si es así, está claro, si es el rey y es el que nos gobierna ¿Por qué no utilizamos directamente el Producto software para estimar las pruebas que se han de realizar?
Podríamos pensar que el producto software no se puede medir pero no es así. Hay multitud de metodologías que se enfocan a medir la funcionalidad que el producto software aporta a negocio. Muchas de ellas estándar ISO que nos aseguran su validez.
A partir de estos valores, hay cálculos previamente establecidos, de manera precisa, que consideran tanto las condiciones del entorno, como las tipologías de los equipos de testing, las pruebas que hay que realizar y algún parámetro adicional más, que determinan la cantidad de pruebas que hay realizar, tanto en número de pruebas como el número de defectos que se van a detectar y así también el esfuerzo que deberemos invertir.
De esta forma todo ello permite que nuestros proyectos, de la misma manera que los bebés sobreviven con el Test de Apgar, sobrevivan.
Basarnos en la bueno o mala experiencia de un profesional o en un criterio de desarrollo de software del cual no dependen la dimensión de las pruebas, pueden ser errores que paguemos muy caro. Sin embargo, estimar el Testware de la forma adecuada nos ayuda a optimizar los procesos a un menor coste pero, además, contribuye a garantizar su supervivencia.
Está claro por tanto, el producto es el rey.
Opinión
