La conmemoración del 9 de septiembre remite a un hallazgo de 1947. Qué hacen los especialistas que prueban programas y por qué su tarea continúa después del lanzamiento.
El 9 de septiembre se celebra el Día del Tester de Software, una jornada dedicada a los profesionales que buscan fallas en los programas y evalúan su funcionamiento. La fecha recuerda un episodio inusual: el hallazgo de una polilla en una computadora de Harvard en 1947, que quedó asociado a la historia de los errores informáticos. La asociación de certificación de testers de Emiratos Árabes Unidos recoge esa relación entre la conmemoración y el incidente.
En 2026 se cumplen 79 años de aquel registro. Desde entonces, las pruebas de software adquirieron un alcance que incluye evaluar riesgos y documentar los problemas de un producto para que el equipo pueda resolverlos. El programa de formación del ISTQB, una organización internacional de certificación en esta especialidad, contempla esas tareas durante el desarrollo y el mantenimiento de los sistemas.
Qué ocurrió con la polilla del Harvard Mark II
El 9 de septiembre de 1947, el equipo que trabajaba con el Harvard Mark II encontró una polilla atrapada entre los contactos de un relay, un componente que abre o cierra un circuito. Los investigadores pegaron el insecto en el cuaderno de trabajo y dejaron una anotación sobre el hallazgo. El Computer History Museum conserva el relato del episodio.
El museo atribuye el hallazgo al equipo y señala que la programadora Grace Hopper estaba presente. Ella contribuyó a popularizar el episodio a través de sus conferencias.
También conviene distinguir lo sucedido de una versión muy repetida de la historia. La palabra inglesa bug, que significa «bicho», ya se utilizaba en ingeniería para hablar de problemas técnicos antes de 1947. La polilla dio una interpretación literal a una expresión existente, como recuerda WIRED en su repaso histórico.
Qué hace un tester y por qué las pruebas continúan tras una actualización
El trabajo exige decidir qué conviene probar y cómo comunicar los resultados. El ISTQB incluye entre las competencias de esta actividad la planificación de las pruebas y la elaboración de informes de defectos claros, que permitan al resto del equipo comprender el problema. También contempla el uso de herramientas para automatizar pruebas repetitivas. Competencias y contenidos de la especialidad.
Dentro de ese proceso, probar y corregir cumplen funciones distintas. Una prueba puede revelar una falla; el diagnóstico posterior busca su causa y la corrección modifica aquello que la provoca. Después hay que comprobar que el arreglo funcionó y revisar si produjo efectos indeseados en otras partes del sistema. Esta última tarea se conoce como prueba de regresión.
Por eso, el control continúa cuando aparece una nueva versión. El temario técnico del ISTQB incluye pruebas de mantenimiento para los cambios en sistemas que ya están en uso y señala un límite importante: comprobar todas las situaciones posibles resulta inviable, salvo en casos triviales. La selección de pruebas debe considerar el riesgo, y un resultado sin fallas detectadas tampoco garantiza que el programa carezca de defectos.