La automatización de pruebas requiere un gran trabajo, es como cualquier otra actividad de test, necesita un toma de requisitos, un análisis, un diseño, una planificación y finalmente escribir el código. Si estás planificando la automatización de muchos casos de prueba, comienza lo antes posible…comienza cuando el producto está en su fase de diseño. ¿Porque? la automatización es una labor costosa, por eso es mejor que el project manager la tenga en cuenta en sus planificaciones desde el comienzo del proyecto, así evitarás que no se haga por falta de tiempo o de presupuesto. Tambiém es importante que el Test manager no olvide la importancia y los beneficios de la automatización, una vez los recursos están focalizados en pruebas manuales dificilmente permitirá el test manager que se dediquen esfuerzos a la automatización.
Si quieres tener exito automatizando, no lo dejes para el final. De todos modos, no es necesario que se haga toda la automatización al principio, lo primero es montar una intraestrutura apropiada y seleccionar correctamente las pruebas a automatizar.
En algunos proyectos se recomienda hacer un equipo destinado a la preparación del framework (o entorno) de automatización, sobre el que se diseñarán los test cases automatizados. Este equipo seria algo similar a un equipo de desarrollo pero enfocado a dar soporte y mantener el código que se usaria en los tests automáticos.
De este modo, el código automatizado se mantiene constantemente para cada versión que se realiza del producto a testear.
Por otra parte, el diseño de las pruebas automáticas las puede realizar otro equipo basándose en el framework diseñado por el equipo de automatización.
just my 2 cent.
Esta claro que lo que comentas es lo ideal, conozco algunas empresas que como bien dices, tienen recursos dedicados solo y exclusivamente a la automatización de pruebas. Como siempre, todo es cuestión de dinero…
El problema es que muy a menudo las organizaciones se plantean automatizar en fases tan tempranas que ni tan solo tienen clara la estrategia de test. A veces existe la errónea creencia de que automatizar es sinónimo de generar y ejecutar automáticamente los test. En cualquier caso, siempre es necesario tener claro qué se va a probar, cómo y quién.
Uhmmm… automatización, este tema puede dar mucho de sí. Muy interesante el artículo y los comentarios. Pello tiene mucha razón en que las actividades de test automático tienen que estar programadas desde el inicio del proyecto, y dando margen suficiente (pues se engaña el que piense que automatizar es ‘inmediato’ y que una vez hecho se puede vivir de ello sin mantenerlo).
Hay que empezar pronto, sí, pero ¿qué significa exactamente ‘al final’? Las tareas preliminares, empiezan por la evaluación/compra(o instalación) y training de la herramienta. Sin herramienta, no hay test automático. Luego, como bien decís, hay que tener muy claro qué pruebas se van a automatizar (los recursos dedicados en ocasiones superan en mucho la ejecución manual). Pero… hasta que no tienes una versión del programa y una UI con la que interactuar, no podrás tener casi nada automatizado (sólo aquellas pruebas independientes de la UI).
Así que si el final, es el final del proyecto, estoy contigo, pero en lo que discrepo es en poder tenerlo hecho ya en la fase de diseño…
Automatizar tiene sentido si la aplicación se implementa por etapas: cada vez que tienes una entrega, puedes automatizar una parte. Así incrementalmente puedes llegar a cubrir todo la funcionalidad básica. De esta manera te aseguras que tus pruebas automáticas se ejecutarán ‘n’ veces y tendrás un óptimo retorno de la inversión.
Larga vida al test automatico…larga vida al Silky!!!