La dura verdad sobre el software sin defectos
Hace muchos años, el día que decidimos lanzar una actualización importante de nuestro producto, una decisión que por supuesto requería mi aprobación como Director de QA, caminaba por el pasillo y el CEO se cruzó conmigo.
Se detuvo y me dijo: “¿Entonces puedo asumir que entregaremos sin defectos?”
Sin pensar tanto como probablemente debería, respondí alegremente: “Por supuesto que no. No existe tal cosa como un software sin defectos.”
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Mi respuesta lo dejó atónito y horrorizado. Estaba tan molesto conmigo que dio por terminada nuestra conversación y se alejó rápidamente por el pasillo.
En ese momento pensé que esto se debía a que era nuevo en el mundo del software y su ciclo de vida, ya que venía del sector editorial (larga historia—para otro momento). Porque todos en el equipo de desarrollo sabíamos que estábamos lanzando con defectos. Pero sabíamos cuáles eran esos defectos desde el principio, y eso marcó toda la diferencia en nuestra evaluación de riesgos.
Sin embargo, observo con alarma que últimamente este malentendido por parte de mi antiguo CEO se ha extendido en nuestra industria. Un software libre de errores, “software cero defectos”, es una nueva promesa/mantra que estoy viendo y escuchando cada vez más. Y no solo de CEOs despistados (redundante, lo sé), sino también de gente de la industria que debería saber mejor. Y que, de hecho, lo sabe. Eso me resulta inquietante.
En cierto sentido, pensar en “cero defectos” no es solo un sinsentido mendaz y oportunista. En Occidente, normalmente es pura palabrería para dar buena imagen. Pero en Japón sí tiene un significado real. Y no solo en la industria del software, sino en todas sus industrias.
Trabajé en Japón durante un año, y esto me sorprendió, pero en el mejor sentido. Porque su definición de “defecto” es muy diferente a la nuestra. Por ejemplo, si hay un envoltorio de chicle en el suelo de la fábrica, eso se considera un defecto, tanto como un problema con la maquinaria o el resultado de un proceso. Si realmente tomáramos en serio el “cero defectos”, pensaríamos en este tema como lo hacen los japoneses. Pero no lo hacemos, así que no lo haremos.
Lo que intentaba decirle a ese infortunado CEO, quizá de manera demasiado directa, es que cualquier software comercial moderno es infinitamente complejo, y las formas en las que puede interactuar consigo mismo o con su entorno son igualmente infinitas. Solo es posible encontrar todos los defectos si tienes una cantidad infinita de tiempo para probar. Pero ninguno de nosotros es inmortal.
Aun si pudieras encontrar hasta el último defecto en la primera ronda, no tendrías tiempo para corregirlos todos y lanzar el producto en este siglo: el tiempo de llegada al mercado es algo real. Así que, incluso si se detectan, tendrás que lanzar con ellos.
Así que toda la noción de “software cero defectos” es, desde el inicio, inherentemente ilusoria.
¿De dónde proviene la noción de software cero defectos?
La raíz de esta ilusión es pensar que la función del equipo de QA es “garantizar” la calidad. No es así. Esa es tarea de Product Management y de Ingeniería. La función de aseguramiento de calidad es *evaluar* qué tan exitosos han sido en eso.
Pero hay otra capa perniciosa en este problema.
Recientemente estaba discutiendo este mismo tema con un desarrollador de software. Me señaló que la forma en que le habían explicado el significado de “software cero defectos” era justo lo que acabo de decir arriba. Significa lanzar con todos los errores corregidos que el equipo decidió que debía corregir para entregar. Y luego lanzar con todos los defectos que decidieron no corregir. Una definición con la que, por cierto, mi interlocutor no estaba de acuerdo.
Esto es claramente una maniobra semántica. Realmente estás lanzando con defectos, y lo sabes, pero usas el eslogan de “cero defectos” para ocultar ese hecho ante ti mismo—y, por supuesto, ante la dirección. Todos sabemos que la dirección es fácilmente hipnotizable por eslóganes vacíos que les hacen sentirse exitosos.
Es una reducción selectiva de defectos, nada más.
¿Cómo nos alejamos de la falacia del cero defectos?
Además, la base de esa falacia es el propio lenguaje, uno que moldea y condiciona nuestro pensamiento antes incluso de que empecemos a responder conceptualmente sobre lo que expone. Es ese lenguaje falso el que crea, en primer lugar, la necesidad de explicar por qué está equivocado. Y así quedamos acorralados por el vocabulario de un eslogan.
Se trata de una práctica muy común en el desarrollo de software. Por desgracia, no se restringe a mentirnos sobre el “cero defectos”. Contamina todos los niveles de nuestro pensamiento y trabajo, como testers, en nuestro proceso de desarrollo, metodologías y métricas.
Miremos la realidad de lo que hacemos y de lo que no hacemos. Y el primer paso para lograr esa recuperación es emplear un lenguaje que describa honestamente lo que logramos y lo que no. Porque si el lenguaje mismo con el que comunicamos esas realidades es, en esencia, fraudulento, deshonesto y delirante, no estamos creando software de calidad. Estamos fabricando propaganda.
El otro problema con el discurso de "software sin defectos" es que, incluso si se trata de un objetivo sinceramente asumido—en el sentido de que la gente cree sinceramente que es posible y no es solo un ejercicio de cinismo—otro problema, aún más serio, limita la utilidad de esta idea. Ese problema es el siguiente:
¿Cómo podrías saber, y probar, que has encontrado "todos" los defectos que existen en el software bajo prueba? ¿Y no solo el número de defectos que has logrado hallar en el tiempo asignado? ¿Cómo podrías demostrarte a ti mismo que el conjunto de errores que has encontrado es el conjunto completo de fallos que realmente contiene el software?
No puedes. Porque para ello sería necesario algún proceso externo al propio QA para determinarlo. De otra manera, es solo un argumento circular. ¿Y cuál sería ese proceso externo?
Y esto es cierto sin importar cuántos errores hayas encontrado ya. Podrías haber hallado un millón de ellos. Eso no prueba que no exista un error un millón uno acechando en las sombras del software.
¿Hay algo valioso en el concepto de cero defectos?
Los evidentes problemas lógicos y epistemológicos de hablar y pensar en términos de “software sin defectos” son simplemente insuperables. El epíteto en sí es irrecuperable, no importa cómo lo reformulemos.
Pero si miramos más allá del eslogan engañoso, hacia lo que lo vuelve atractivo y conceptualmente válido para personas que suelen razonar, encontraremos algo valioso en lo que centrarnos.
Ese “algo” es una pregunta diferente, pero que responde a las necesidades prácticas y emocionales que parece abordar el falso discurso del software libre de defectos, y lo hace de manera más coherente y defendible.
La cuestión con la que realmente intentan enfrentarse las personas en software al recurrir al autoengaño es, en sí misma, engañosamente simple. A saber: “¿Cuándo sabemos que podemos dejar de probar?”
Es la única pregunta que hago a los candidatos para puestos de liderazgo en QA en mi organización. Porque, en realidad, esa es la única cuestión que el área de QA debe responder. Y si no puede, QA es una completa pérdida de tiempo. Para responder esa pregunta, antes tenemos que responder otra pregunta previa.
Cero defectos vs % cobertura de pruebas
¿Cómo sabemos si los defectos que ya hemos encontrado—sean muchos o pocos—pueden ser aceptados plausiblemente como representativos del espectro de riesgo generado por cómo se especificó y diseñó el software bajo prueba? De modo que podamos afirmar con confianza que los defectos no detectados restantes representan un riesgo aceptable para la decisión de lanzar el software al público.
Planteada así, vemos que esta no es una cuestión sobre defectos en absoluto. Es una cuestión sobre la cobertura de pruebas. Tu análisis de los errores encontrados, por cuantiosos que sean, no significa nada si no pueden correlacionarse con un entendimiento analítico de la cobertura de pruebas alcanzada hasta la fecha en el esfuerzo de QA, respecto de la cobertura que aún resta por conseguir.
Porque si ese conjunto de defectos conocidos, sin importar el tiempo invertido en pruebas, representa solo un 30% de cobertura de pruebas real—y no sabes esto—entonces no tienes una base racional para saber qué significan esos hallazgos a la hora de tomar la decisión de lanzar el software.
La verdadera discusión sobre los esfuerzos de QA realmente efectivos, y el verdadero objetivo, no puede ser acerca de los “cero defectos”, sino de la “cobertura de pruebas al 100%”. Por la razón que acabo de exponer.
La gran ventaja de este enfoque para pensar la calidad del software reside en que se apoya en una definición previa de cobertura adecuada realizada por el propio equipo de QA antes de efectuar las pruebas. Por lo tanto, esa definición puede contrastarse con especificaciones, requerimientos, problemas históricos de clientes y necesidades de clientes, etc., y modificarse según sea necesario.
Avanzando: cobertura de pruebas sin brechas
Pensar este problema únicamente en términos de defectos fracasa precisamente porque no es algo que se pueda definir de manera significativa de antemano, ya que el número y la gravedad de los problemas solo pueden descubrirse después de las pruebas.
Además, no se evalúa en relación con una definición previa (y significativa) de qué podría significar realmente el umbral de “cero”. Es una pérdida de tiempo definir el éxito en función de una variable que en sí misma no está definida y que no puede definirse.
Por eso, la única manera de rescatar la idea de software sin defectos es canalizar ese pensamiento y planificación hacia una cobertura de pruebas sin brechas. La motivación detrás de la consigna de cero defectos no es equivocada por sí misma. Simplemente ha sido desviada de su verdadero objetivo. Haz ese ajuste, y las definiciones significativas y medibles de calidad aceptable en el software se vuelven posibles.
Si estás listo para aprender más y para aprender de expertos y CEOs, aquí hay un podcast que creemos que te va a gustar: TRABAJO EN EQUIPO, IA Y CONTENERIZACIÓN (CON MICHAEL RITCHSON DE LA NASA)
Lectura relacionada: LOS 10 MEJORES HERRAMIENTAS DE SEGUIMIENTO DE DEFECTOS PARA PRUEBAS DE SOFTWARE
