Un producto exitoso debe verificar que no tiene errores (bugs) y validar que satisface las necesidades funcionales del cliente. Para ello es imprescindible realizar pruebas sobre el producto software.
Las pruebas pueden ser manuales, usuarios o miembros del equipo de desarrollo realizan pruebas sobre el producto software, o automáticas, miembros del equipo de desarrollo escriben software cuyo objetivo es probar el producto software.
Verificar que el software cumple las especificaciones y validar que el software suple las necesidades afloradas son cuestiones relacionadas, pero no responden a lo mismo:
La validación intenta responder a la pregunta: ¿Se está construyendo el producto correcto?
La verificación intenta responder a la pregunta: ¿Se está construyendo el producto correctamente?
El proceso de construcción debe garantizar que el producto se construye sin errores y que el producto es el adecuado. En este sentido, es habitual en la industria el uso del aforismo: “build the product right and build the right product”.
Para validar que el producto realmente suple las necesidades del cliente, identificadas durante la actividad de descubrimiento de requisitos, es necesario ponerlo en funcionamiento.
En la visión predictiva es habitual el señalamiento en la planificación de hitos en los que se hace una demostración ante el cliente de lo construido.
En la visión adaptativa el producto se despliega en el entorno de producción para ser usado. Es el cliente o el usuario líder quien periódicamente valida el producto desplegado usándolo en su día a día.
🔎 Clippy, el asistente para ayudar al usuario que Microsoft incluyó en la suite de productos Office 97 se construyó de forma impecable, sin embargo, fue un producto fallido. ¿Realmente necesitaban los usuarios ayuda interactiva mientras usan Office?
Clippy es utilizado en la industria como ejemplo paradigmático de construcción correcta del producto incorrecto. Ha sido objeto de numerosas parodias, como la divertida secuencia “pipy demo” en la serie de HBO “Silicon Valley”.
Para verificar que el producto se está construyendo adecuadamente se realizan pruebas.
En la visión predictiva, las pruebas son realizadas por el equipo de QA o testers al finalizar la construcción.
En la visión adaptativa, las pruebas son realizadas durante la construcción por el equipo de desarrollo. Las actividades de desarrollo y pruebas se solapan. El objetivo del testing no solo es detectar fallos, sino en la medida de lo posible, prevenir dichos fallos.
💬 [...] Las pruebas y el desarrollo van de la mano. Codifique un poco y pruebe lo que construyó. Luego codifique un poco más y pruebe un poco más. La prueba no es una práctica separada; es parte integrante del proceso de desarrollo en sí. La calidad se logra poniendo el desarrollo y las pruebas en una licuadora y mezclándolos hasta que uno sea indistinguible del otro.
James A. Whittaker, “How Google Tests Software”
Una prueba pretende certificar si el componente hace lo que debe. La prueba debe arrojar únicamente dos posibles resultados: SI o NO (verde o rojo, OK o NOK). A la hora de validar el componente existen dos tipos de pruebas:
Las pruebas de “caja negra” centran su interés en lo que hace el componente no en cómo lo hace. Para ello el componente es alimentado con un conjunto de valores de entrada, la prueba certifica que los resultados devueltos por el componente son los que deben. Es indiferente el código ejecutado para lograr los resultados. Cada una de los pares “entrada - salida esperada” se llama caso de prueba o “test case”. Son las pruebas más habituales.
Las pruebas de “caja blanca” no solo centran su interés en lo que hace el componente sino también en cómo lo hace. Para ello el componente es alimentado con un conjunto de valores de entrada y la prueba certifica que tanto los resultados devueltos por el componente como el código ejecutado es el que debe ser.
Las baterías de casos de uso pueden ser extensas y su ejecución puede llevar mucho tiempo. Además, requieren preparar el escenario adecuado para el caso de uso, lo cual puede implicar montar parte o todo el producto software. Por otro lado, la labor de documentación tanto de los casos de uso como de sus resultados puede resultar tedioso. Por todo ello las pruebas manuales resultan “caras”.
La solución a todos estos problemas pasa por automatizar las pruebas. Los beneficios de la automatización son mayores cuanto mayor sea el proyecto. Automatizar las pruebas genera costes acumulados grandes en comparación con las pruebas manuales al comienzo del proyecto. Cuando el proyecto crece los costes acumulados de la automatización se estabilizan, sin embargo, los costes acumulados de las pruebas manuales no paran de crecer (en ocasiones exponencialmente). En cualquier caso, en todos los proyectos deben convivir las pruebas automatizadas con las manuales. De hecho, existen algunas pruebas para las que no es posible escribir un script, por ejemplo, ciertas verificaciones estéticas de la interface de usuario.
Referencias:
• M.Cohn "Succeeding with Agile", Addison-Wesley Signature Series, 2009
• Métrica-3 Técnicas. Administración Electrónica del Gobierno de España.
• K.Beck; "Extreme Programming Explained", Addison-Wesley Professional, 1999
• R.C. Martin "Código Limpio", Anaya, 2009