El arte de probar el software

Siguiendo con el mismo patín de la entrada anterior, Glenford J. Myers en su libro sobre el arte de probar el software, desarrolla en su capítulo 2 una interesante guía o marco conceptual, por medio del cual entender en que consiste la responsabilidad de emitir criterio sobre una determinada aplicación.
En primer lugar el autor nos señala que puede existir un enfoque equivocado al definir qué es un test, es decir un pecado de origen. Si le pidiéramos al evaluador que "demostrará que no hay errores presentes" obtendríamos un resultado significativamente diferente de si pedimos "que encuentren todos los errores que pueda". Varias son las razones para esta diferencia. Primero, tomemos como ejemplo un enfermo que va a un Laboratorio, si el análisis indica que no hay nada mal en la persona, pero esta se siente mal, la prueba habrá sido un fracaso. El plantear como objetivo buscar que algo esté bien, no presenta oportunidades de mejora a las cuales aprovechar, es decir al paciente le interesa que le encuentren algo que lo guíe para sentirme mejor. La segunda razón por la cual la definición es importante es porque demostrar que algo está bien puede ser una tarea titánica de nunca acabar, con lo cual el costo de encontrar el error adicional puede ser tal que haga que la prueba tenga un mayor costo que la aplicación. Finalmente, la tercera razón que es relevante es la definición debe solventar el problema de demostrar no solo que el programa hace lo que debe hacer, sino que además no haga lo que se espera que no haga y esto solo es posible en un marco más flexible de buscar la mayor cantidad de errores posibles.
La segunda idea relevante que plantea el autor en su artículo es la existencia de dos tipos de pruebas: las de caja negra y las de caja blanca. Respecto de las primeras se menciona que parten del hecho de solo preocuparse de lo que entra y sale de la aplicación, sin que sea relevante la parte interna. En este tipo de pruebas deben plantearse un universo de casos exhaustivos, con inputs válidos y no validos a efecto de verificar que las salidas tenga razonabilidad. Ahora bien el universo de entradas y las correspondientes salidas pueden dar origen a infinidad de combinaciones. Respecto al segundo tipo de pruebas, el autor menciona que éstas se concentran en el interior de la aplicación, es decir en su lógica. Esto representa dos grandes retos. El primer reto consiste en identificar todas las posibles rutas por las componentes del software que se pueden presentar, para verificar que las interrelaciones ante determinadas circunstancia estén previstas en la aplicación y funcionen adecuadamente. El segundo reto tiene que ver con la prueba individual de los componentes internos, la verificación de si los componentes son todos los necesarios o si es que hacen falta y si cada uno de estos componentes es sensible a datos y como pudieran manejar las distintas excepciones. Como podrá darse cuenta el lector esta también es una tarea titánica. La conclusión acerca de cuál de los dos tipos de pruebas es más favorable no es definitiva, más bien dado el amplio espectro es que se recomienda combinarlas y tratar de aprovechar al máximo sus beneficios.
Finalmente el autor nos menciona algunos principios que toda evaluación de software debiera respetar:
1. Definir de previo los resultados esperados
2. No revisar el software que uno hace
3. Las organizaciones deberían buscar que un tercero también pruebe su software.
4. Los resultados de las pruebas deben inspeccionarse a fondo
5. Las pruebas deben contener escenarios inesperados o inválidos
6. Las pruebas deben llevarse a cabo en diferentes momentos y sobre los mismos.
7. Evitar improvisar al momento de realizar la prueba para poder repetirla posteriormente
8. Debe partirse del hecho de que hay errores
9. Al hacer la prueba en las partes, errores en un componente es proporcional a errores en el resto
10. Hacer pruebas es un trabajo creativo e intelectual.
Definitivamente estamos aprendiendo de las pruebas, cierto??