No necesitas una IA para mejorar la calidad de tu proyecto, sólo haz esto. Voy a partir de un ejemplo, real, y determinante en la historia de la medicina para demostrar la importancia 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.
Si nos remontamos a principios de los 50, allá por siglo pasado, 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.
En una sociedad puramente machista, como la de la época, ser mujer médico, y ya especializarse en cirugía, fue un hito. Virginia fue de las primeras en conseguirlo. De la cirugía pasó a dedicarse a la anestesiología, una actividad relacionada, pero muy diferente, y dentro de esta rama optó por dedicarse a los partos donde comenzó a comprobar una realidad terrible detrás de la alta tasa de mortalidad que comprobaba.
Inmediatamente después de la llegada a este nuevo mundo del 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?
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.
A pesar de las dificultades que imponía esa época a una mujer, que además no era ni tocóloga, Virginia no pudo mirar a un lado. Y fue en ese momento cuando se propuso 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.
Dicho Test, se basa en obtener un valor numérico midiendo 5 aspectos simples: frecuencia cardiaca, esfuerzo respiratorio, presencia de reflejos, tono muscular y color. Se realiza 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 ¿La estandarización permitirá salvar su calidad?
Calidad de proyecto
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.
En consecuencia, que un proyecto tenga la calidad adecuada y fundamentada en unos aspectos sencillos y medibles es uno de los pilares fundamentales. Pero todo ello requiere una dedicación y esfuerzo para ejecutar unas tareas de pruebas que confirmen la calidad que buscamos. Pero, ¿Cómo podemos estimar ese esfuerzo?
Son muchos los casos en los que ese esfuerzo se determina de la misma 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. Denominado en proyectos como “Juicio experto”.
No necesitas una IA para mejorar la calidad de tu proyecto, sólo haz esto
Sin embargo hay otros muchos casos, en los que el esfuerzo de pruebas se determina en función del esfuerzo de desarrollo, es decir, que si 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.
Y ¿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.
Como venimos diciendo, realmente, el producto software es el rey y reina con majestuosidad en todos los ámbitos de nuestra vida. Por tanto, si es el rey y es el que nos gobierna ¿Por qué no utilizamos directamente el Producto software para estimar las pruebas a realizar?
La duda que podría surgir en un primer momento es pensar que el producto software no se puede medir pero esto no es así. Existen 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.
Existen cálculos establecidos que partiendo de esos valores, de forma precisa, y teniendo en cuenta las condiciones del entorno, las tipologías de los equipos de testing, las pruebas que hay que realizar y algún parámetro adicional más, determinan la cantidad de pruebas que hay que 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.
Todo esto permite que nuestros proyectos, de la misma manera que los bebés sobreviven con el Test de Apgar, sobrevivan.
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. 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. El producto es el rey.
