¿Qué son las pruebas de software?
Cuando comencé en JMP hace más de una década, si me hubieran preguntado qué son las pruebas de software, habría ido a mi búsqueda web preferida (o en estos días a un asistente de AI LLM) y habría regresado con algo parecido a esto: Las pruebas de software son el proceso de evaluar una aplicación o producto de software para garantizar que funcione como se espera y cumpla con los requisitos del usuario.
Sin embargo, a través de muchas discusiones con mi colega Joseph Morgan, he adoptado una definición de ingeniería de software, enunciada sucintamente por Glenford Myers [1]:
“La prueba es el proceso de ejecutar un programa con la intención de encontrar errores”.
¿Es esta definición tan diferente? Yo diría que sí. Aunque Myers et al. [1] tienen un gran debate sobre esto, para la mayoría de las personas existe una diferencia psicológica entre pedirle a alguien que compruebe que algo funciona y tratar de romperlo. Al adoptar la definición de Myers, un ingeniero de pruebas logra su objetivo: encontrar errores. Esto no solo proporciona estructura, sino que al encontrar y corregir estos errores (o como podríamos pensar, bugs) de manera temprana y reflexiva, el resultado es un software que funciona como se esperaba y cumple con los requisitos del usuario.
¿Dónde están los bichos?
Si todavía estás conmigo y te sientes cómodo con la definición de prueba, la siguiente pregunta natural es por dónde empezar a intentar romper el software. Para esto podemos recurrir a Boris Beizer [2]:
“Los insectos se esconden en los rincones y se congregan en los límites”.
Dividiremos esto en dos partes, donde trataremos una entrada como algún tipo de datos o información que usted le da al software para obtener una reacción o hacer algo con esa información.
Los errores se concentran en los límites : esto pone de relieve que los errores suelen encontrarse en los límites de lo que el sistema está diseñado para manejar. Por ejemplo, si se supone que una función debe aceptar entradas entre 0 y 1, deberíamos probar los límites (0 y 1) así como también justo fuera de ellos.
Los errores se esconden en los rincones : esto sugiere que los errores suelen esconderse en las partes de un sistema que involucran más de una de las entradas. Es decir, de forma muy similar a como pensamos en las interacciones, no encontraremos un error a menos que probemos estas combinaciones.
¿Hacia dónde vamos desde aquí?
En las próximas semanas, mis colegas y yo hablaremos sobre distintos temas relacionados con la validación (¿estamos construyendo el producto correcto?) y las pruebas (encontrar errores, asegurarse de que el software funciona). Lo que me resulta particularmente interesante es que existe una profunda conexión entre las pruebas y el diseño de experimentos (otro tema del que me encanta hablar).
Ya sea que estés creando tus propias aplicaciones, te enfrentes a tu propio desafío de pruebas o simplemente estés interesado en este tema en general, espero que continúes leyendo. ¿Hay algún tema que te gustaría que se trate? ¡Háznoslo saber en los comentarios!
Y, como un blog no parece completo sin una imagen, imagen del primer “error informático”, como parte de un equipo de la Universidad de Harvard en 1947 que incluía a Grace Hopper.
Cortesía del Naval Surface Warfare Center, Dahlgren, VA., 1988., Primer error informático, 1945 , marcado como dominio público, más detalles en Wikimedia Commons
Referencias.
- G. Myers, C. Sandler y T. Badgett, El arte de las pruebas de software, 3.ª ed. , Nueva Jersey, John Wiley & Sons, Inc, 2011.
- B. Beizer, Técnicas de prueba de software , Serie de ingeniería y ciencias eléctricas e informáticas de Van Nostrand Reinhold, 1983
¡Hola @Ryan_Lekivetz !
Gracias por esta excelente introducción, no puedo esperar a aprender más sobre el uso de matrices de cobertura u otros métodos de localización de fallas para probar software.
