A comienzos de la década de los 50 del 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.
Virginia Apgar fue una de las primeras mujeres en especializarse en cirugía, algo nada fácil atendiendo a los años que eran y a que la sociedad era puramente machista. De la cirugía pasó a dedicarse a la anestesiología, una actividad relacionada, pero muy diferente. Dentro de la anestesiología le gustaba dedicarse a los partos, donde comenzó a comprobar una realidad terrible detrás de la alta tasa de mortalidad.
Tras alumbrar al niño a este nuevo mundo, 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?
Si la respuesta a estas preguntas era pesimista, el criterio del médico era que el bebé no sobreviviría y que 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.
Estandarización para salvar vidas
Virginia no pudo mirar a un lado a pesar de las dificultades que imponía esa época a una mujer que además no era ni tocóloga. Con determinación se propuso definir un método objetivo y fácilmente replicable en todos los partos que ayudaran a salvar vidas y así es como nació el Test de Apgar.
El Test de Apgar consiste en obtener un valor numérico midiendo cinco aspectos simples: frecuencia cardiaca, esfuerzo respiratorio, presencia de reflejos, tono muscular y color.
El test 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?
Estandarización para salvar la calidad de tus proyectos
Muchos de nuestros proyectos no salvan vidas, ni las pierden, pero los proyectos son casi como el alma que hace que nuestras organizaciones evolucionen y 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 tanto, que un proyecto tenga la calidad adecuada y fundamentada en unos aspectos sencillos y medibles es uno de los pilares fundamentales.
Y esto 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?
En la mayoría de los casos ese esfuerzo se determina de la misma forma en la que los médicos determinaban la viabilidad de vivir de un bebé, 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”.
En otros casos, 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, como determinó Virginia. Está en el objeto de nuestro estudio. Y el objeto de estudio en nuestro caso será el producto que queremos probar.
El producto software
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?
Una primera duda puede surgir por pensar que el producto software no se puede medir. 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.
A partir de esos valores existen cálculos establecidos de forma precisa 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, que determinan la cantidad de pruebas a realizar, tanto en número de pruebas como el número de defectos que se van a detectar y así el esfuerzo que deberemos invertir.
Esto permite que nuestros proyectos, sobrevivan de la misma manera que los bebés sobreviven con el Test de Apgar.
Calcular el Testware de la forma adecuada nos ayuda no solo a optimizar los procesos a un menor coste sino también a esta 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.
Julián Gómez Bejarano
Chief digital officer de LedaMC
