Varios gestores de proyecto esperan que la automatización de pruebas de software sea la receta milagrosa que alivie los problemas recurrentes de la fase de pruebas: desfases del cronograma, largos tiempos de espera para entrega de versiones y altos costos. El problema surge cuando se utilizan modelos de costos muy simples para tomar decisiones sobre la automatización de pruebas. Presentamos una guía para entender los costos asociados con este tipo de proyectos.
Costos, riesgos y beneficios
En cualquier análisis de caso de negocio, se deben considerar los costos, riesgos y beneficios. En nuestra experiencia con casos de costos, se pueden agrupar de dos formas: en costos iniciales y costos recurrentes.
Costos iniciales:
- Evaluar y seleccionar la herramienta adecuada. En muchos casos este paso es obviado y se manifiestan luego los problemas asociados.
- Comprar la herramienta o adaptar las herramientas open source, o bien desarrollar una herramienta personalizada. En el proceso de pruebas automatizado, las herramientas (por ejemplo, Selenium o QTP) solo juegan un rol de soporte. El diseño de un framework de automatización de pruebas tiene un rol principal. Se debe comprender que el estándar usado para diseñar este framework tiene una relación directa con el éxito del proyecto de automatización.
- Priorizar los casos de prueba a ser automatizados. Por ejemplo, se puede considerar primero en la priorización los casos de prueba que tengan mayor tasa de reúso (se ejecutan con la mayor frecuencia en el proceso actual: en pruebas de humo, en pruebas de regresión, en pruebas de sanidad, etc.)
- Generar los datos de prueba a consumir por los scripts de prueba.
- Aprender a usar la herramienta apropiadamente. Esto incluye los costos de transferencia de conocimiento dentro de la organización y la generación de nuevo conocimiento; por ejemplo: diseñar y documentar la nueva arquitectura de pruebas.
- El costo de integrar la herramienta con el proceso de pruebas actual, la integración con otras herramientas existentes (por ejemplo, la herramienta de gestión de casos de prueba o gestión de defectos, o integración continua) y la integración con el equipo de pruebas actual.
Costos recurrentes:
- Mantener la herramienta y los scripts de prueba. Este costo está asociado a la durabilidad de un script, es decir cuánto tiempo dura el script antes de que sea modificado. Puede convertirse pronto en un gran problema si no se diseña pensando en minimizar este costo. Por ejemplo, asegurarse de establecer una arquitectura adecuada (como el conocido patrón de diseño Page Object Model), o seleccionando apropiadamente los casos de prueba por automatizar. Incluso al iniciar eventualmente el proceso de automatización en un sistema que recibe cambios constantes de su funcionalidad o diseño de interfaz de usuario.
Mantener los scripts de generación de datos de prueba. - Ejecución de los scripts de pruebas y analizar los resultados. Este costo puede ser estimado mediante la multiplicación del tiempo en correr los scripts por la frecuencia de ejecución y por la tarifa por unidad de tiempo.
- Tarifas de renovación de licencias.
- Tarifas de soporte a las herramientas.
- Entrenamientos continuos, por ejemplo: nuevos recursos que se agregan al equipo o actualizaciones de herramientas.
- El costo de migrar los scripts de pruebas a nuevas plataformas.
- Extender la cobertura a nuevas funcionalidades de la aplicación bajo pruebas, o nuevas aplicaciones.
- Lidiar con problemas relacionados con disponibilidad de la herramienta, limitaciones y dependencias.
- Instaurar una mejora continua de los scripts de pruebas. Al igual que el primer costo inicial mencionado, es una tentación ignorarlo. Esto se evidencia aún más cuando se tiene a un equipo de varias personas automatizando los scripts de prueba de una aplicación, lo que tiende a incrementar la probabilidad que el uso de la herramienta y el desarrollo de scripts evolucione de formas incompatibles y la probabilidad de reutilización de scripts descienda.
¿Cuándo automatizar las pruebas?
Otra forma de analizar costos es pensar en costos fijos y costos variables. De la lista anterior, los fijos serán aquellos que permanecerán sin importar la cantidad de casos de prueba que se automaticen. Por ejemplo: compra de herramienta, entrenamiento, licencias, etc.
Los costos variables son aquellos que cambian de acuerdo al número de casos de prueba en un determinado momento. Por ejemplo, el desarrollo de scripts de pruebas o el desarrollo de datos de prueba.
La lista descrita nos permitirá determinar con un muy buen nivel de detalle el costo relacionado a un proyecto de automatización de pruebas y el uso recurrente de los scripts generados en los futuros ciclos de pruebas.
Sin embargo ante la pregunta: ¿Cuándo automatizar las pruebas?, todavía nos queda pendiente analizar otros costos asociados al proyecto, como el costo de oportunidad en la automatización de pruebas con respecto a las pruebas manuales o el costo de recurrencia de ejecución automatizada versus ejecución manual.
Estos temas se abordarán en futuros artículos con el fin de poder determinar cuál es el momento ideal para obtener el máximo beneficio del proceso de automatización de pruebas.
.png)
