Aspectos Básicos del Testing

1. Aspectos Básicos del Testing

2. Saquen una hoja ... • Escribir un conjunto de casos de prueba, un conjunto de datos que van a testear bien el siguiente programa. • El programa lee tres enteros. Los tres valores representan la medida de los lados de un triángulo. El programa imprime un mensaje que determina si el triángulo es esacaleno, isóceles o equilátero.

3. Evaluar el conjunto de los casos de prueba • Un caso de prueba que representa un triángulo válido • escaleno (1,2,3 / 2,5,10) • equilátero • isóseles (2,2,4) • Al menos tres casos de una posibilidad válida, en donde se permuten los datos (3,3,4 4,3,3 3,4,3) • uno con un 0 • uno con un valor negativo FI: En todo triángulo un lado es menor que la suma de los otros dos y mayor que su diferencia

4. Evaluar el conjunto de los casos de prueba • la suma de dos de los números es igual al tercero (1,2,3) • idem anterior + la permutación de lugar • la suma de dos de los números es menor al tercero (1,2,4) • idem anterior + permutación del lugar • (0,0,0) • números no enteros • valor erróneo (asdfk dfjka aldj) • para cada caso de prueba especificó la salida

5. Evaluar el conjunto de los casos de prueba Buenos programadores 7 u 8, entre 14

6. Psicología y economía • Testing es un proceso que ejecuta un programa con la intención de encontrar errores. • Es posible encontrar todos los errores?

7. Principios • Una parte necesaria de un caso de prueba es la definición de la salida esperada o resultado. • Un programador debe evitar testear su propio programa. • Una organización debe evitar testear sus propios programas. • Inspeccionar detenidamente los resultados de cada test

8. Principios • Los casos de prueba deben ser escritos tanto para valores de las entradas/salidas inválidos e inesperados cómo para los válidos. • Examinar un programa para ver si hace lo que se espera que haga es sólo la mitad del test, la otra parte es examinar si el programa no hace algo que no se espera que haga.

9. Principios • No tirar nunca los casos de prueba hasta que no se halla descartado el programa • No planear el esfuerzo del testing habiendo asumido tácitamente que no se van a encontrar errores • La probabilidad de que existan más errores en una sección del programa es proporcional a la cantidad de errores que se han hallados en esa sección.

10. Principios • Cuanto antes se detecte un error más fácil es corregirlo • Testing es una tarea extremamente creativa y un desafío intelectual • Un buen caso de prueba es aquel que tiene una probabilidad alta de descubrir errores. • Un caso exitoso es aquel que detecta un error no encontrado.

11. Human Testing • Inspecciones • Walkthroughs • Prueba de escritorio • Ratings de calidad

12. Inspecciones & Walkthroughs • Lectura o visual inspección hecha por un grupo de gente (3 o 4). Uno de ellos es el autor del programa. • 90-120’ sin interrupciones • Climax “meeting of the minds” • Disminuye la labor de debugging • Efectivo: 30% a 70% de errores de lógica en el diseño. No errores análisis-requerimientos. • Human testing es complementario del testing basado en la computadora.

13. Inspecciones • Team: • Moderador (programador competente) • Distribución del material • Cronograma • Liderar la sesión de inspección • Anotar todos los errores encontrados • Se debe asegurar que se corrijan los errores • Programador • Diseñador del programa • Testeador del programa

14. Inspecciones • Procedimiento: • El moderador distribuye el listado del programa y las especificaciones • Debe ser leida antes de la sección • El programador narra el programa (suele encontrar sus propios errores) • El programa es chequeado con una lista histórica de errores (se retroalimenta en cada sección) • Al terminar la sesión se le da al programador la lista de errores encontrados • De acuerdo a la cantidad y tipo de errores se arma otra reunión

15. Walkthroughs • Team, 3 a 5 personas • Moderador (programador competente) • Programador • Programador experto • Experto del lenguaje • Un programador novato • Alguien de otro proyecto • Alguien del mismo proyecto

16. Walkthroughs • Procedimiento (play computer) • tester (casos de prueba / salidas esperadas). Medio para seguir la lógica. No lo más importante. • el programa es seguido leyendo la lógica • los estados se van anotando

17. Ratings de calidad • Evaluación anónimas de programas • Auto evaluación • Un programador es seleccionado como administrador del proceso • El mejor hecho y el más malo (anónima) • Se distribuyen en forma aleatoria • 30’ • Se contesta: • fácil de entender • tiene un diseño de alto nivel visible y razonable • tiene un diseño de bajo nivel visible y razonable • fácil de modificar • estaría orgulloso de ser el autor • Se publican en forma anónima los resultados