¿Por qué hacer pruebas al software?
Estado actual de esta publicación: Borrador inicial.
Me ha gustado crear software desde adolescente. Al inicio, yo mismo era mi propio usuario final pues mis primeros programas para computadora estuvieron en la categoría de videojuegos muy básicos. Luego, vendí aplicaciones de software para contabilidad básica y conocí a mis primeros usuarios finales distintos a mí. En general, logré satisfacer los requerimientos elementales de esos usuarios finales y al mismo tiempo logré mis primeras ganancias monetarias directas de mi esfuerzo como programador de computadoras.
Durante esa etapa inicial no tuve conciencia de las disciplinas profesionales disponibles para hacer pruebas a una aplicación de software. Por lo que podría haber conservado la opinión de que no hace falta esfuerzo extra especializado para hacer pruebas al software y aun así lograr satisfacción para todos los involucrados. Pero en experiencias posteriores, a las malas, me enfrenté con algo que ahora llamo mayor complejidad. Y así entendí la patente necesidad de conocer esas disciplinas profesionales para hacer pruebas a una aplicación de software que tenga un tamaño no trivial o unos requerimientos no triviales.
Ahora, 35 años más tarde, sigo cayendo en cuenta de que el asunto de evaluar si una aplicación de software es o no trivial, en sí mismo, es un asunto no trivial. Así como lo es determinar la cantidad de esfuerzo necesario y suficiente para diseñar, ejecutar y evolucionar una estrategia convincente de pruebas para una solución global de negocio basada en software.
Hay muchas analogías para ilustrar aspectos de la creación y entrega satisfactoria de software de calidad. Por ejemplo, a veces crear software es como el arte de un chef profesional. Según mis propias vivencias como usuario de restaurantes, es evidente para mí que un chef, como autor a cargo de su obra, toma el papel de responsable de servir un platillo con la confianza de que el sabor y, en general, el buen estado del platillo, están presentes antes de poner su obra enfrente de su comensal. Ese chef se asegura de que lo que está sirviendo corresponde a lo solicitado por su cliente y a lo que él mismo supone que está sirviendo. Así, la probabilidad de que ese cliente regrese se hace mayor, así como se hace mayor la probabilidad de que prospere el negocio del chef.
¿Qué hace ese chef para lograr esa confianza y asegurar la prosperidad de su profesión?
Por supuesto, no tengo voz autorizada para responder por un chef profesional. Imagino que probar la buena calidad de los ingredientes escogidos desde el inicio, cuidar muchos aspectos del proceso, y saborear el platillo terminado quizá serían parte de la respuesta. Lo que sí puedo decir, como comensal recurrente en algún restaurante, es que mi vivencia directa con tal producto, así creado, ha sido buena o muy buena o sobresalientemente buena.
Análogamente, la confianza en la calidad de una aplicación de software no llega automágicamente de un único factor, sino que es el resultado de muchos factores. Un subconjunto de esos factores son los diferentes tipos de pruebas diseñadas y ejecutadas a lo largo del proceso de creación antes de la entrega completa en las manos de los usuarios finales.
