Estos “Scripts de Prueba” simulan a un usuario y ejecutan los pasos de el procedimiento de prueba y valida que la aplicacion se comporte de acuerdo a los requerimientos.

Estos es muy util cuando introduces un release con cambios o mejoras a tu aplicacion y necesitas saber si esos cambios no hecharon a perder algo mas en la aplicacion.

Basicamente asegurarnos de que lo nuevo no heche a perder lo que ya funciona. Este es el principal beneficio de las “pruebas de regresion”

Ahora el beneficio de tener “Automated Regression Testing” es que puedes correr tus scripts de prueba cuantas veces quieras ya que no necesitas de “testers” para que ejecuten las pasos del procedimiento de prueba.

Imaginense tener 1000 procedimientos de prueba para una aplicacion que recibe mejoras o cambios 5 veces al mes. Tendriamos que tener un equipo de testers que manualmente pruebe los 1000 procedimientos de prueba cada vez que hay un cambio, esto serian 5000 pruebas. Necesitarias bastantes recursos para poder probar tu aplicacion. Pero con “automated regression testing” puedes correr los scritps y checar resultados cuando terminen de ejecutarse. No hay comparacion en lo que se puede ahorrar un empresa en tiempo y dinero con esta tecnica.

Mencione solo lo basico de este metodo de prueba, si alguien necesita mas informacion puede buscar en Google o mandarme un Email con su pregunta: george_pip@hotmail.com

Espero y esto le sirva alguien. Saludos

Pruebas unitarias: estas las corre el desarrollador, cada vez que va probando pedazos de codigo o scripts para ver si todo funciona como el desea. Estas pruebas son muy tecnicas. PE: probar una consulta, probar que un pedazo de codigo me envie algo a imprimir, probar que una funcion me devuelva un flag…

Pruebas de Sistema: si la aplicacion se compone de varios modulos, hago la prueba de toda la aplicacion aun cuando solo haya modificado una parte de el, solo para ver si en conjunto todo funciona bien, esta las hace el desarrollador pero tambien debe correrlas un tester. PE: modifique un modulo para generar un reporte de imagen a pdf, pruebo la funcionalidad en varios modulos diferentes para ver si se integro bien al funcion con todo el sistema.

Pruebas de Integracion: esta se usa si tu sistema usa otros servicios o sistemas externos a el, la corre el desarrollador y tambien un tester. PE: Mi aplicacion ademas de generar un pdf lo envia por email, encolandolo en un servidor de correo, pruebo que el server de correo encole bien el mensaje y que agregue toda la informacion y el adjunto.

Prueba de aceptacion: esta prueba debe ser hecha asi con dibujos y todo detallando cada paso ya que el que la realiza es el tester y el usuario final y de ahi el dice si cumple con la funcion que requeria o si hay que manejarlo, a esta altura no debe haber ningun error si el tester hizo pruebas de integracion y de sistema… PE: el usuario hace una tarea cotidiana con datos reales en un ambiente de prueba y hace otras pruebas con datos raros para poner al sistema en jaque esperando que el sistema funcione correctamente y el de la aprobacion para implementarlo en un ambiente de pruebas.

Para mi estas son basicas, cualquier duda pueden consultarme, soy analista de calidad de software…

Exitos.

cuidenc bye…

Desafortunadamente no cuento con una buena referencia en este instante, pero una búsqueda en google sobre “pruebas de software” seguro podrá ampliar el tema.

Infórmense, vale la pena…