Automatizacion del Test

Jenkins, Nick. Test Automation. A Software Testing Primer: An Introduction to Software Testing. En http://www.softwaretestinghelp.com/ (en línea). 2008. Disponible en Internet: http://www.nickjenkins.net/prose/testingPrimer.pdf. Traducción: Juan Manuel Bertoni / María Pereyra. A menudo las organizaciones buscan reducir el costo del testing. La mayoría de las organizaciones no se sienten cómodas reduciendo la cantidad de testing entonces, en cambio, intentan mejorar la eficiencia del testing. Afortunadamente, hay un número de proveedores de software que afirman ser capaces de ofrecer exactamente esto! Ofrecen herramientas automatizadas que toman un caso de prueba, lo automatizan y lo ejecutan sobre un software reiteradamente. ¡Música para el oído de los directivos! Sin embargo, hay algunos mitos sobre las herramientas de test automatizadas que deben ser disipadas: El testing automatizado no encuentra más errores que el testing manual: un tester experimentado que está familiarizado con el sistema encontrará más nuevos defectos que un juego de tests automatizados. La automatización no corrige el proceso de desarrollo: a pesar de lo duro que suena, los testers no crean defectos, los desarrolladores lo hacen. La automatización no mejora el proceso de desarrollo aunque puede destacar algunos temas. El testing automatizado no es necesariamente más rápido: el esfuerzo de automatizar un test y mantenerlo es mayor que el de llevar a cabo un test manual. Entonces llevará más tiempo y será más costoso automatizar un test por primera vez. El costo de la automatización se recupera a largo plazo. No es necesario automatizar todo: algunas cosas no se prestan a la automatización, algunos sistemas cambian muy rápido como para automatizarlos, algunos test se benefician de una automatización parcial. Se debe ser selectivo sobre lo que automatizar para cosechar los beneficios. Pero, en su lugar, las herramientas automatizadas pueden ser muy beneficiosas. El caso de negocio más gracioso que he visto sobre las herramientas de testing automatizadas fue este: Usando testing manual, encontramos un número X de defectos en nuestro software. Cuesta $Y por año encontrar y corregir esos defectos (tiempo de desarrollador y tiempo de tester). Podemos comprar una herramienta de automatización de test a $Z por año. Dado que $Z < $Y deberíamos comprar la herramienta y, como bonus, encontrar <> Entonces, No solo estaremos comparando el costo de la herramienta contra el costo de hacer el test manualmente sino que, lo que se busca es dejar de hacer que el tester realice la tarea manualmente ya que ellos son los que hoy en día encuentran esos molestos defectos. El costo oculto El costo oculto de la automatización del test está en su mantenimiento. El costo de un test automatizado que pueda ser escrito una vez y ejecutado muchas, se recupera más rápido que el de uno que deba ser continuamente reescrito para estar en paz con el software. Ahí está el problema. Las herramientas de automatización, como cualquier otro software, “hablan” con el software bajo test a través de una interfaz. Si la interfaz cambia todo el tiempo, sin importar lo que diga el proveedor de la herramienta, los tests automatizados también deberán cambiar. Por otro lado, si las interfaces se mantienen constantes pero el código funcional subyacente cambia, entonces los tests automatizados seguirán ejecutándose y (con suerte) encontrando defectos. Muchos proyectos de software no tienen interfaces estables. La interfaz gráfica de usuario (GUI) es de hecho el área que tiene más cambios porque es la parte que el usuario más ve. Tratar de automatizar el test de la parte del software que cambia rápidamente de interfaz es un poco como querer colgar gelatina a la pared(*). ¿Para qué es bueno el testing automatizado? El testing automatizado es particularmente bueno para: Testing de carga y performance - Los tests automatizados son un prerrequisito para llevar adelante pruebas de carga y performance. No es factible tener simultáneamente 300 usuarios testeando manualmente un sistema, debe ser automatizado. '''Smoke Testing''' - Un test rápido y sucio para confirmar que el sistema "básicamente" funciona. Un sistema que no pasa un smoke test es automáticamente devuelto a un estado previo al que se llevó a cabo el trabajo, ahorrando tiempo y esfuerzo. Pruebas de regresión - Probar funcionalidad que no tendría que haber cambiado con la versión de código actual. Los tests automatizados existentes pueden ejecutarse y éstos destacarán los cambios en la funcionalidad para la que fueron designados a testear (desarrollos incrementales pueden ser rápidamente testeados y revisados por si han alterado la funcionalidad entregada en previos incrementos). Configurar los datos o precondiciones del test - Un test automatizado puede ser utilizado para configurar los datos o condiciones del test que de otra manera llevarían mucho tiempo. Pruebas repetitivas que incluyen tareas manuales que son tediosas y propensas a errores humanos (por ejemplo, comparar saldo de cuentas con siete decimales). Dificultades de la Automatización del Test La automatización del testing debe ser tratada como un proyecto por derecho propio. Se deben definir sus requerimientos. Se debe especificar lo que va a ser automatizado y lo que no. Se debe diseñar una solución para la prueba y esta solución debe ser validada contra referencias externas. Consideremos la situación donde una aplicación es escrita a partir de especificaciones funcionales incorrectas. Luego, un tester toma las mismas especificaciones funcionales y a partir de ellas escribe un test automatizado. El código, ¿pasará las pruebas? Por supuesto. Cada vez que se ejecuten. La aplicación, ¿cumplirá con lo que el cliente quiere? La prueba, ¿es válida? No. Por supuesto, el testing manual puede caer en las misma trampa. Pero el testing manual involucra a humanos quienes hacen preguntas impertinentes y provocan debate. Los tests automatizados sólo hacen lo que se les pida que hagan. Si le decimos que hagan algo mal, lo harán sin hacer preguntas. Además, los tests automatizados deben ser diseñados teniendo en mente su mantenimiento. Deben ser construidos a partir de unidades modulares y diseñados para ser flexibles y conducidos por parámetros (sin constantes hardcodeadas). Deben seguir estándares de codificación y debe haber un proceso de revisión para asegurar que los estándares son implementados. No hacer esto resultará en la generación de código base que es difícil de mantener, incorrecto en sus suposiciones y que se deteriorará más rápido que el código que se supone será testeado. __________________________________ (1) En inglés, "trying to pin a jellyfish to the wall".