Transformación digital
Cultura organizativa
Puede resultar difícil de creer, pero hubo un tiempo en el que la gente —ya fuera antes, durante o después de la compra— no comprobaba el funcionamiento de un producto, sino que esperaba a que fallara. Esta costumbre también era muy habitual en los inicios de la industria del software, cuando las prácticas de verificación eran prácticamente inexistentes. Esta situación comenzó a cambiar a partir de la década de 1950, cuando se iniciaron las pruebas en el desarrollo de aplicaciones.
En setenta años, la actividad de pruebas ha evolucionado considerablemente. En la actualidad, forma parte integrante de la rutina de creación de productos digitales o de los proyectos de modernización de aplicaciones. A medida que el desarrollo de software ha ido creciendo y volviéndose más complejo, impulsado en gran medida por la computación en la nube, se ha producido un aumento exponencial en el volumen de pruebas.
Sin embargo, no solo cambió la cantidad. La perspectiva y la función de las pruebas también fueron variando, sobre todo a partir del cambio de década, de los años 70 a los 80. Sigue leyendo este artículo para conocer un poco más sobre la historia de las pruebas y comprender qué papel desempeñan actualmente en el desarrollo de aplicaciones.
Las primeras reflexiones de la literatura técnico-científica sobre las pruebas son de Alan Turing. En artículos publicados a finales de la década de 1940 y principios de la de 1950, el «padre de la informática» aborda el uso de aserciones para verificar la corrección de los algoritmos.
Los textos se enmarcan en el periodo que David Gelperin y Bill Hetzel denominan «fase orientada a la depuración», el primero de los cinco periodos de la historia de las pruebas. Según los autores, estas fases son:
| FASE | PERÍODO | TEMA PRINCIPAL |
| Hasta 1956 | Guía de depuración | Corregir errores cuando la máquina fallaba |
| De 1957 a 1978 | Instrucciones para la demostración | Demostrar que el software cumplía los requisitos |
| De 1979 a 1982 | Orientación hacia la destrucción | Detectar de forma proactiva los fallos antes de que se produjeran |
| De 1983 a 1987 | Orientación hacia la evolución | Utilizar los errores como punto de partida para mejorar |
| A partir de 1988 | Orientación sobre prevención | Garantizar una calidad constante desde el inicio del proyecto |
Podemos clasificar los dos primeros períodos como la «prehistoria» de las pruebas. Esto se debe a que 1979 es el año en que se publicó el libro«The art of software testing» —en español, «El arte de las pruebas de software»— del científico informático Glenford Myers. La obra constituye el hito más importante sobre este tema en el sector, hasta tal punto que, a día de hoy, sigue siendo una referencia en materia de gestión de la calidad en el desarrollo de software.
En la primera etapa de la historia de las pruebas, la orientada a la depuración, estas solo se aplicaban cuando el sistema presentaba algún error. La ejecución de pruebas era la propia actividad de depuración. Tanto es así que, en gran parte de la literatura técnica de la época, los términos «depuración» y«pruebas»se utilizaban con frecuencia como sinónimos.
Nunca está de más recordar que, en ese periodo de la historia, los ordenadores y los programas no eran componentes intercambiables; cuando una empresa adquiría una máquina, esta venía con su propio sistema. Esta peculiaridad también se ponía de manifiesto en las pruebas: estas se centraban mucho más en el hardware que en el software. Los problemas relacionados con este último pasaban a un segundo plano —y a menudo se ignoraban— ante la preocupación por la fiabilidad del hardware.
En la segunda fase, la dedicada a la orientación hacia la demostración, las pruebas y la depuración pasaron a considerarse actividades distintas. Esta separación queda clara en el libro «Digital Computer Programming» —en español, «Programación de ordenadores digitales»—, de Dan McCracken. Partiendo de este enfoque, el objetivo de las pruebas no era corregir una máquina cuando presentaba errores, sino demostrar que el programa funcionaba y que resolvía los problemas planteados. En otras palabras, que el software cumplía los requisitos.
Este enfoque más profesional y riguroso en las pruebas se ha hecho necesario ante la evolución de las aplicaciones, tanto en complejidad como en coste. Con más programas en el mercado, el número de errores y problemas se multiplicaba. Esto aumentaba el riesgo económico que podían provocar los fallos de los programas, lo que a su vez incrementaba tanto las exigencias de calidad como la inversión en las pruebas.
En 1979 se publicó «El arte de las pruebas de software», el hito más importante de esta disciplina. Su relevancia se debe a que propone tanto una nueva lógica como un nuevo objetivo para la actividad de las pruebas.
En la fase de orientación hacia la destrucción, el resultado final deseado era el mismo que en la anterior: un software que funcionara y cumpliera los requisitos. Pero Myers propone una forma nueva y holística de alcanzar ese objetivo: verificar todas las hipótesis que podrían dar lugar a un error. La actividad de las pruebas de software no debería consistir en comprobar lo que funcionaba, sino en ejecutar un programa con la intención de encontrar errores.
Es gracias a «El arte de las pruebas de software» que las pruebas han adquirido su función actual: la prevención. Al cambiar el enfoque, pasando de la demostración a la detección de posibles problemas, esta actividad pasa a tener como objetivo la calidad total, lo que permite comprobar la conformidad de las aplicaciones en el momento de su finalización.
Las dos fases posteriores, tanto la orientada a la evolución como la orientada a la prevención, son desarrollos de la fase orientada a la destrucción. No modifican el principio, sino que simplemente añaden objetivos a la actividad de pruebas.
En la fase orientada a la evolución, las pruebas pasan a integrarse en la revisión y el análisis para promover la evolución del producto a lo largo del ciclo de vida de la aplicación. Dicho de otro modo, la actividad de pruebas sigue teniendo como objetivo detectar errores. Sin embargo, ahora la información sobre dichos errores constituye el punto de partida para planificar la mejora del sistema.
Por último, la fase actual, orientada a la prevención, puede resumirse en la expresión«calidad como servicio». La actividad de pruebas no se lleva a cabo una vez que el software está listo, sino a lo largo de todo el ciclo de desarrollo, desde la fase de concepción. Las pruebas se realizan en paralelo a la creación de la aplicación, en todas las fases del proyecto.
Es en el marco de este enfoque donde surgen las metodologías de desarrollo que se utilizan ampliamente en la actualidad en el mercado: el desarrollo orientado a pruebas —aplicado a las pruebas unitarias —, el desarrollo orientado al comportamiento y el desarrollo orientado a pruebas de aceptación.
Toda la historia de Inmetrics está estrechamente ligada a la actividad de pruebas. Nacimos como una empresa cuyo objetivo era mejorar la calidad y el rendimiento de las aplicaciones. Como parte de nuestro ADN, esto está presente en todas nuestras actividades. No en vano, somos una empresa líder en pruebas continuas en el informe «ISG Provider Lens Next-Gen ADM Services Brazil 2022».
Si necesitas desarrollar aplicaciones realmente robustas y que funcionen sin errores, con todo el entorno supervisado y corregido casi al instante, ¡haz clic aquí, habla con nuestro equipo de expertos y descubre todas nuestras soluciones!
