Hola Lucía y resto de los compañeros,
Voy contestando entre líneas el mensaje de Lucía.
En la pregunta 1 se marca como correcto que es de valor que el tester tenga conocimientos de programación, pero por como lo definimos en el curso el tester es simplemente quien ejecuta los test, por lo tanto no veo ningún valor en que tenga conocimientos de programación.
R: El tester no es simplemente quien ejecuta los test, también es quien diseña y especifica los casos de prueba, entre otras actividades. Para estas actividades es de valor tener conocimientos de programación. Por poner un par de ejemplos:
- las técnicas de caja blanca derivan casos de prueba a partir del código del programa, tener conocimientos de programación es de utilidad para utilizar este tipo de técnicas.
- un tester que automatice o realice pruebas de performance, seguramente necesite codificar.
- los conocimientos de programación pueden facilitar la comunicación con el equipo de desarrollo.
Por otro lado me parece que el equipo de desarrollo puede hacer pruebas de tipo dogfood testing para hacer una validación parcial del software antes de, por ejemplo, pasar a beta testing. Capaz me pueden aclarar por qué este razonamiento no sería correcto.
R: Lo importante acá no es el tipo de pruebas que se realizan, sino con qué objetivo. Quien puede validar el software es el cliente/usuarios, porque son quienes lo solicitaron y para quienes está desarrollado el software. El equipo de desarrollo puede hacer pruebas (incluso las mismas pruebas que realice el cliente o los usuarios), pero con el objetivo de verificar el software, no validarlo.
En la pregunta 2 se marca que las pruebas de regresión se utilizan para verificar si nuevas versiones no degradaron la performance, pero por lo que entendi de las clases y las diapositivas las pruebas de regresión son para detectar fallos en el software introducidos por nuevos cambios, no temas de performance, capaz me pueden indicar donde se comenta esta característica de las pruebas de regresión.
R: En las diapositivas de la clase 2 de V&V dice "Tanto en el mantenimiento como en procesos iterativos
incrementales, es necesario realizar pruebas de regresión:
verificar que los cambios o agregados realizados a la nueva
versión no hayan degradado o “roto” el funcionamiento del
sistema." Degradar el funcionamiento del sistema es por ejemplo, que el sistema funciona más lento y esto refiere a la performance del mismo. En el capítulo 3 pag. 75 de la bibliografía (Spillner) menciona que el testing de regresión aplica a todos los niveles de prueba (desde unitario hasta aceptación) y al testing funcional y no funcional (que incluye performance).
Por último me queda una duda de la pregunta 4, si se marca que ninguna es correcta, entiendo que "Las técnicas de caja blanca no sirven para verificar características como performance o rendimiento." es incorrecto. Esto sería decir que las técnicas de caja blanca si sirven para verificar características como performance o rendimiento, me queda la duda de como esto sería posible dadas las características de las técnicas de caja blanca vistas en el curso.
R: Las técnicas de caja blanca vistas en el curso ayudan a derivar un conjunto de casos de prueba que cumpla con un determinado cubrimiento del software. Ahora bien, el objetivo de los casos de prueba, así como el resultado esperado de los mismos dependen de la especificación/requisitos del software y no tanto de la técnica que se utilice. Supongamos que tengo un requisito de performance que me dice que el tiempo de respuesta del sistema no puede superar los 5 segundos (bajo determinados supuestos). Tener un conjunto de casos de prueba que cubra el 100% del código me ayuda a verificar este requisito. Si no tengo un cubrimiento del 100% ¿cómo puedo asegurar que el código no cubierto no afecte los tiempos de respuesta?
Muchas gracias y disculpen la molestia.
De nada, no es molestia. Quedo a disposición por cualquier otra duda.
Saludos,
Cecilia.
