En general, en el ambiente del software se conocen los beneficios de disponer de pruebas automatizadas. Sin embargo, es menos común entender los costos que esto implica. No están claras las características de la inversión asociada.
El desafío es decidir cuándo y cómo invertir en automatización de pruebas para conseguir un proyecto exitoso (proyecto de automatización). Para esto es vital analizar el contexto, o sea, el producto, el proyecto de desarrollo y la empresa (desarrolladora o consumidora de software).
Para aquellos que aún no han automatizado pruebas funcionales en su ámbito de trabajo, a continuación se presentan ideas que pueden ayudar a evaluar cuándo empezar.
Es una inversión
Los beneficios de la automatización se verán luego de varios ciclos de ejecución, por lo tanto la inversión tendrá que ser sostenida.
No se trata de un esfuerzo inicial y luego esperar. De nada sirve comprar la licencia de una herramienta de automatización y no invertir en la creación, mantenimiento y ejecución de las pruebas. Sería como comprar una licencia de Visual Studio 2010 y esperar que las aplicaciones estén listas. Esto es sólo el comienzo, un proyecto de automatización de pruebas es también un proyecto de desarrollo de software.
Son conocidos los casos en los que se compran “mágicas” herramientas de automatización y luego quedan olvidadas en el armario.
Si en cambio, se decide invertir en dominar una herramienta de código abierto o libre, la situación será similar. Una vez adquirida la experticia necesaria, se deberá seguir trabajando en el proceso de creación y uso de las pruebas.
Según el producto
Será necesario considerar las herramientas existentes para automatizar las pruebas según la tecnología usada, Web, GUI, Web services, protocolo de comunicación, etc. Las interfaces del producto nos dirán si automatizar las pruebas será difícil, factible, fácil, etc. La complejidad para automatizar el accionar de una interfaz y la forma de validar el resultado de una prueba nos dará información sobre el esfuerzo necesario.
El producto puede requerir trabajar en múltiples plataformas: sistemas operativos, bases de datos, navegadores, etc. Si se mantienen las interfaces para las diferentes plataformas, podemos probar con las mismas pruebas automatizadas ahorrando tiempo de desarrollo. Por ejemplo, supongamos que tenemos una aplicación que requiere ejecutar sobre plataformas de PC (Intel y Mac) y en móviles (con iOS, Android, Windows Phone), con las variantes posibles en cuanto a navegadores (IExplorer, Firefox, Chrome, Opera). Las pruebas pueden ser las mismas y simplemente ejecutarse en cada configuración.
Según el proyecto
El proyecto determina cuántas iteraciones se esperan y con qué frecuencia. También puede tratarse de un producto que no tiene un plan determinado por un proyecto, sino que el ritmo y calidad de liberación son determinadas por las exigencias del mercado. Esto nos dirá cuánto utilizaremos nuestras pruebas automatizadas.
Por ejemplo, si estamos hablando de un desarrollo con metodologías agiles, está soportado en la automatización. En el otro extremo, si esperamos pocas iteraciones le daremos menos uso a la automatización.
Hay que considerar no sólo las iteraciones en la etapa de proyecto, sino aquellas que aparecen una vez liberado el software, en el mantenimiento urgente y evolutivo. En esta etapa las pruebas automatizadas toman un valor importantísimo, para probar rápidamente liberaciones urgentes, aportando tranquilidad sobre el cubrimiento de las pruebas.
Según la empresa
Se puede afrontar el desafío de la automatización desde el inicio del proyecto de desarrollo de la aplicación o después, esto también depende de las características de las empresas.
Empresas pequeñas o nuevas quizás no lo pueden afrontar al inicio. Es posible que no tengan los recursos para destinar a la automatización.
Otras pueden afrontar el desafío, pero se pospone, llegando a un momento en el cual las versiones salen casi sin testing. Esto puede darse porque el producto es muy grande, o se liberan versiones muy frecuentemente, o tienen múltiples versiones de un producto para diferentes clientes, plataformas, etc. El testing manual no tiene la capacidad de llevar a cabo el trabajo.
Es importante analizar el entendimiento en la gerencia y en el equipo de desarrollo sobre los beneficios y trabajo detrás de la automatización. Se necesitará el apoyo y compromiso de ambas áreas para llevar adelante el proyecto.
Se tendrá que evaluar la disponibilidad de recursos humanos para destinar a la automatización. Como mencionamos, la automatización es también un proyecto de desarrollo, lo que implica que se necesita un perfil desarrollador/tester.
Cuándo
El momento adecuado dependerá de todas estas variables.
Si nos adelantamos podemos encontrarnos con inmadurez en el equipo de testing, esto podría llevarnos a descuidar las pruebas manuales, que nos dan beneficios a corto plazo. Si la organización no tiene claro lo que implica la automatización, pueden aparecer expectativas no realistas, frustración y abortar el proyecto.
Como se dice comúnmente, “nunca es tarde” para hacer las cosas. Pero puede pasar que otros competidores liberen más rápido, con mayor calidad, los clientes no estén conformes con la calidad, los usuarios ya no crean en la aplicación, etc. Todos estos problemas pueden afectar seriamente las ventas del producto o el éxito del proyecto.
Por lo presentado, resulta importante evaluar desde el inicio y periódicamente si estamos en el momento adecuado para arrancar con la automatización de pruebas. Se puede comenzar con una inversión pequeña aunque sostenida, tratando de no dejar pasar el tren.
En posteriores entradas al blog hablaremos de cómo encarar de mejor manera este camino.
