 No es un remplazo para pruebas exploratorias

1.2 Factores de Éxito en la Automatización de Pruebas

Los siguientes factores de éxito aplican para proyectos de automatización de pruebas que están en
operación y además, el foco es sobre la influencia que impacta sobre el éxito de un proyecto a largo
plazo. Factores influyentes en el éxito de un proyecto de automatización en la fase piloto no son
considerados aquí.
Principales factores de éxito para automatización de pruebas incluyen los siguientes:
Test Automation Architecture (TAA)
El TAA es alineado muy cercanamente con la arquitectura del producto de software. Deberían ser claro
cuáles requerimientos funcionales y no funcionales de arquitectura a soportar. Típicamente estos serán
los requerimientos más importantes.
Con frecuencia TAA es diseñado para mantenibilidad, desempeño y fácil aprendizaje. (Mirar ISO/IEC
25000:2014 para detalles de estos y otras características no funcionales). Es de mucha ayuda involucrar
ingenieros de software que entienden la arquitectura del SUT.

Capacidad del SUT para ser probado

El SUT necesita ser diseñado para ser probado por pruebas automatizadas. En el caso de pruebas para
GUI, esto podría significar que el SUT debería desacoplar la Interacción de la GUI y datos con la
apariencia de la interfaz gráfica cuanto más sea posible. En el caso de pruebas de API, esto podría
significar que más interfaces de clases, módulos o comandos de CLI necesitan ser expuestas como
públicas para que pueden ser probadas.
Las partes que pueden ser probadas de un SUT deberían ser el primer objetivo. Generalmente un factor
clave en el éxito de automatización de pruebas recae en la fácil implementación de scripts de pruebas
automatizados. Con este objetivo en mente, y también proveyendo una prueba de concepto exitosa, el
TAE necesita identificar módulos o componentes del SUT que son probados fácilmente con
automatización y empezar por ahí.

Estrategia de Automatización de Pruebas

Una estrategia de automatización de pruebas practica y consistente que se dirija hacia la mantenibilidad
y consistencia del SUT.
Puede no ser posible aplicar la misma estrategia de automatización de pruebas en la misma forma para
partes nuevas y viejas del SUT. Cuando se está creando la estrategia de automatización, considere los
costos, beneficios y riesgos de aplicarlos a diferentes partes del código.
La consideración debe ser dada para probar los dos, la interfaz de usuario y la API con casos de prueba
automatizados para verificar la consistencia de los resultados.
Test Automation Framework (TAF)
Un TAF que es fácil de usar, bien documentado y actualizable, soporta un enfoque consistente para la
automatización de pruebas.
Para establecer un TAF fácil de usar y actualizar, se debe hacer lo siguiente:

 Implementar servicios de reporte: Los reportes de pruebas deberían proveer información (paso,
fallo, error, no ejecutado/abortado, estadísticas, etc.) a cerca de la calidad del SUT. Reportes
debería proveer la información para los testers involucrados, administradores de pruebas,
desarrolladores, administradores de proyectos y otros interesados para obtener un vistazo de la
calidad.
 Habilitar fácil resolución de problemas: Además de la ejecución de pruebas y registro de eventos,
el TAF tiene que proveer una forma fácil de resolver las pruebas fallidas. La prueba puede fallar
debido a:
o Fallas encontradas en el SUT
o Fallas encontradas en el TAS
o Problemas con las pruebas ensimismas o el ambiente de prueba
 Abordar el ambiente de pruebas apropiadamente: Las herramientas de pruebas dependen en
gran medida de la consistencia del ambiente de pruebas. Tener un ambiente de pruebas
dedicado es necesario en pruebas automatizadas. Si no hay control del ambiente de pruebas y
los datos de prueba, la configuración para las pruebas podría no cumplir los requerimientos para
la ejecución de las pruebas y sería muy probable de producir falsos resultados de ejecución.
 Documentar los casos de prueba automatizados: Los objetivos para la automatización de
pruebas tienen que ser claros, por ejemplo, cuales partes de la aplicación son para ser probadas,
a que grado, y que atributos van a ser probados (funcionales y no funcionales). Esto debe ser
claramente descritos y documentados.
 Rastrear las pruebas automatizadas: TAF debería soportar rastreo para que los ingenieros de
automatización de pruebas puedan localizar pasos individuales o casos de prueba.
 Habilitar fácil mantenimiento: Idealmente, los casos de prueba automatizados deberían ser
fácilmente mantenidos para que el mantenimiento no consuma una parte significativa de los
esfuerzos de la automatización de pruebas. Asimismo, el esfuerzo de mantenimiento necesita
estar en proporción a la escala de los cambios hechos en el SUT. Para hacer esto, los casos
deben ser fácilmente analizables, cambiables y expandibles. Además, el re uso del testware
debería ser alto para minimizar el número de ítems que requieren cambios.
 Mantener las pruebas automatizadas al día: Cuando un nuevo requerimiento o cambios en ellos
causen que las pruebas o la suite entera fallen falle, no deshabilitar las pruebas fallidas –
arreglarlas.
 Planear el desarrollo: Estar seguro que los scripts de pruebas pueden ser fácilmente
desarrollados, cambiados y re-desarrollados.
 Retirar los casos cuando sea necesario. Estar seguro que los scripts de pruebas automatizados
pueden ser fácilmente retirados si ya no son útiles o necesarios.
 Monitorear y restaurar el SUT: En la práctica real, para ejecutar un caso de prueba o un conjunto
de pruebas continuamente, el SUT debe ser monitoreado continuamente. Si el SUT encuentra
un error fatal (tales como una caída), el TAF debe tener la capacidad de recuperarse, saltar el
caso actual, y reanudar las pruebas con el siguiente caso.