Norma de estrategia de diseño para automatización de pruebas funcionales en la Plataforma CI/CD Corporativa

Ámbito de aplicación de la norma

La Junta de Andalucía establece como objetivo estratégico la estandarización de herramientas y normas  corporativas orientadas a la homogeneización del ciclo de vida del desarrollo de productos software y a la implantación de prácticas DevSecOps.
En consecuencia, la estrategia de diseño para la automatización de pruebas funcionales es consideradas como un pilar clave en el ciclo de vida del desarrollo de software, especialmente cuando se integra dentro de un pipeline de CI/CD.
En su versión inicial, esta estrategia aplica exclusivamente a pruebas funcionales sobre aplicaciones web, ejecutadas en los navegadores Chrome, Firefox y Edge.
Por tanto, esta norma DEBE ser aplicada por todo sistema de información que:

• se encuentre en el Proceso de Transición a DevSecOps
• se encuentre operativo o en desarrollo para ser desplegado en las infraestructuras de despliegue de la ADA, utilizando el modelo DevSecOps impulsado por el Servicio de Gobierno TI y Calidad

Además, se RECOMIENDA que sea aplicada por:

• Todo sistema de información de nuevo desarrollo.
• Cualquier otro sistema de información de la ADA, teniendo en cuenta sus posibles restricciones 
  tecnológicas o presupuestarias.

Uso del framework de automatización de pruebas de funcionales

DIR_01 Uso del framework de automatización de pruebas funcionales en la Plataforma CI/CD Corporativa

Obligatorio  La automatización de pruebas funcionales en la Plataforma CI/CD Corporativa DEBE realizarse utilizando el framework corporativo de automatización desarrollado en lenguaje Java, con Maven como herramienta de construcción y gestión de dependencias. Este framework constituye el estándar corporativo en la Plataforma CI/CD Corporativa  para la elaboración de pruebas funcionales automatizadas y DEBE ser utilizado con independencia de la tecnología, lenguaje o arquitectura del sistema bajo prueba.

DIR_02 Integración del framework de automatización de pruebas funcionales en componentes que utilicen el stack Java /Maven

Obligatorio En aquellos componentes cuyo desarrollo se realice en Java y utilice Maven como herramienta de construcción y gestión de dependencias, el framework corporativo de automatización de pruebas funcionales DEBE integrarse directamente en el propio proyecto.
La automatización de pruebas funcionales se desarrollará dentro de la estructura del proyecto, conforme a las convenciones y directrices definidas en esta norma.

DIR_03 Automatización desacoplada para proyectos no Java/Maven

Obligatorio Cuando el componente bajo prueba esté implementado con tecnologías distintas de Java y/o no emplee Maven como herramienta de construcción, se DEBE crear un proyecto específico e independiente para la automatización de pruebas funcionales. La automatización de pruebas funcionales se desarrollará dentro de la estructura del proyecto, conforme a  las convenciones y directrices definidas en esta norma.
Este componente de automatización utilizará el framework de automatización de pruebas desarrollado en Java y Maven, conforme a las convenciones y directrices definidas en esta norma y se mantendrá desacoplado del código fuente del producto software, garantizando su independencia tecnológica.

Definición y diseño de la automatización de pruebas de funcionales

DIR_04 Valor primero

Obligatorio La selección y priorización de las pruebas funcionales que deban ser automatizadas DEBE realizarse atendiendo al principio de valor primero, con el objetivo de maximizar la reducción de riesgos y el retorno de inversión de la automatización.
El orden de desarrollo de las pruebas funcionales automatizadas DEBE basarse, al menos, en los siguientes criterios:

• Reducción del riesgo: se priorizarán aquellas pruebas cuya criticidad en caso de fallo sea mayor, de manera que los errores con mayor impacto sean detectados lo antes posible.
• Tiempo de ejecución y recurrencia: se priorizarán las pruebas que se ejecuten de forma recurrente y/o presenten tiempos elevados de ejecución manual, al proporcionar un mayor retorno de inversión mediante la reducción de tiempos y esfuerzo.
• Casos repetitivos y estables: se priorizarán los casos con alto coste de ejecución manual y baja variabilidad entre versiones del sistema bajo prueba, por ser más adecuados para su automatización.

DIR_05 Reutilización por diseño

Recomendado El desarrollo de las pruebas funcionales automatizadas DEBERÍA realizarse conforme al principio de reutilización por diseño, con el objetivo de minimizar la duplicidad de código y facilitar la mantenibilidad del framework de automatización.
Con carácter previo al desarrollo de las pruebas automatizadas, debería realizarse un análisis de los componentes, flujos y herramientas implicadas, identificando aquellos elementos comunes a múltiples pruebas funcionales.
La lógica común identificada debería abstraerse y reutilizarse de forma centralizada, evitando la duplicación de código y promoviendo un diseño modular y mantenible.

DIR_06 Determinismo en la automatización de pruebas funcionales

Recomendado Las pruebas funcionales automatizadas deberían diseñarse conforme al principio de determinismo, de forma que su resultado sea reproducible e independiente de la ejecución de otras pruebas.
En la medida de lo posible, cada prueba automatizada debería cumplir los siguientes criterios:

• Ser independiente del resto de pruebas automatizadas.
• No depender del orden de ejecución.

La aplicación de este principio, siempre que sea posible, garantiza una ejecución equilibrada de la batería de pruebas, evitando que fallos en pruebas previas o que un orden incorrecto de ejecución impida la validación del resto de escenarios automatizados.

DIR_07 Observabilidad en la automatización de pruebas funcionales

Obligatorio La ejecución de las pruebas funcionales automatizadas DEBE garantizar un nivel adecuado de observabilidad que permita el diagnóstico de fallos sin necesidad de re-ejecuciones manuales.
Tras cada ejecución de la regresión automatizada, DEBEN generarse y almacenarse evidencias, logs y trazas suficientes para que los equipos de desarrollo y/o Calidad puedan analizar los resultados, identificar la causa de los fallos y registrar los defectos correspondientes.

DIR_08 Seguridad y cumplimiento

Obligatorio Todos los datos sensibles necesarios para la ejecución de las pruebas funcionales automatizadas, incluyendo credenciales, secretos técnicos y datos personales reales, DEBEN gestionarse de forma segura y NUNCA incorporarse directamente en el código, ficheros de configuración ni repositorios del framework de automatización.
Dichos datos DEBEN ser gestionados como secretos, mediante el uso de gestores de credenciales externos, mecanismos de inyección segura de variables o sistemas de cifrado adecuados, conforme a las políticas de seguridad corporativas.

DIR_09 BDD (Behavior-Driven Development)

Obligatorio Las pruebas funcionales automatizadas DEBEN definirse y desarrollarse siguiendo el enfoque de Behavior-Driven Development (BDD), de manera que los escenarios representen el comportamiento esperado del sistema desde el punto de vista del negocio.
Los escenarios de prueba DEBEN expresarse mediante un lenguaje legible para perfiles no técnicos, evitando referencias a detalles de implementación o automatización (por ejemplo, identificadores técnicos, clics o interacciones de bajo nivel)
Cada escenario DEBE validar un único flujo funcional de negocio y NO DEBE combinar múltiples objetivos dentro de un mismo escenario.
Los escenarios BDD DEBEN estructurarse utilizando el patrón Given / When / Then o equivalente.
Los escenarios DEBEN clasificarse mediante etiquetas, permitiendo su selección, ejecución y análisis de resultados en los distintos contextos de ejecución (por ejemplo, smoke, regresión, criticidad)

DIR_10 Separación de la lógica de pruebas y la interfaz de usuario

Obligatorio La automatización de pruebas funcionales sobre interfaces web DEBE basarse en un patrón de diseño que garantice la separación entre la lógica de las pruebas y los detalles de implementación de la interfaz de usuario.
Como mínimo, DEBE existir una abstracción que encapsule:

• las acciones que el usuario puede realizar sobre una página o componente,
• los estados relevantes necesarios para la validación de las pruebas.

Los elementos web utilizados en las pruebas DEBEN definirse de forma centralizada y reutilizable, evitando su duplicación en los escenarios o pasos de prueba.

DIR_11 Page Object Model (POM)

Recomendado El uso del patrón Page Object Model (POM) se establece como patrón de referencia recomendado para cumplir este principio, aunque otros también son permitidos (Screenplay, Componentes Object Model, etc)

Convenciones de uso y estructura del framework de automatización de pruebas.

DIR_12 Estructura del framework de automatización de pruebas

Obligatorio La estructura de carpetas, así como los nombres y nomenclaturas de las carpetas y ficheros, utilizados en el framework de automatización de pruebas DEBEN seguir las regals marcadas en esta directriz.

• Todos los archivos .features que contienen los Steps asociados a cada prueba DEBEN de incluirse en la carpeta /src/test/resources/”Nombre del proyecto”/features.

  

• Todos los archivos asociados al PageObject Model que contienen los scripts de java con la lógica asociada a cada Step de las pruebas DEBEN de incluirse en la carpeta /src/test/java/”Nombre del proyecto”/steps.

  

• Todos los archivos asociados al PageFactory que contienen los scripts de java con la definición de los localizadores asociados a cada elemento web DEBEN de incluirse en la carpeta /src/test/java/”Nombre del proyecto”/pageFactory.

  

• Todas las parametrizaciones finales asociadas a la ejecución de las pruebas DEBENde estar definidas en el archivo test-data.properties e incluirse en la carpeta /src/test/resources.
   

  

• Todas las configuraciones adicionales para la definición de drivers para cada navegador, configuración de logs y runners para el lanzamiento de los archivos .features mediante cucumber se almacenan en la carpeta /src/test/java/”Nombre del proyecto”/config y /src/test/java/”Nombre del proyecto”/cucumber. Inicialmente ya están definidos de manera común a todos los proyectos y no debería ser necesaria su modificación.

Por último, la lógica asociada a la localización de elementos web mediante PageFactory se almacenan en la carpeta /src/test/java/”Nombre del proyecto”/elementFinder. Inicialmente ya están definidos de manera común a todos los proyectos y no debería ser necesaria su modificación.

DIR_13 Configuración de certificados https

Obligatorio En caso de que la URL objetivo de las pruebas funcionales automatizadas necesiten de un certificado https para el acceso, este DEBE de configurarse en el pom.xml del proyecto. Tal y como se describe a continuación, este certificado DEBE estar alojado en una carpeta accesible desde el proyecto una vez este se ejecute, con lo que, para ser ejecutado en Integración Continua debe de acordarse de manera previa al lanzamiento con el equipo gestor del entorno de ejecución:

DIR_14 Uso del hub de Selenium de Plataforma CI/CD

Obligatorio Los componentes que utilicen el framework de pruebas funcionales de la plataforma CI/CD DEBEN utilizar un driver remoto alojado en el hub de Selenium de la plataforma CI/CD Corporativa. Este tipo de driver está ya configurado en el framework y únicamente es necesario definir la URL asociada a ella en el archivo anteriormente comentado test-data.properties incluido en la carpeta /src/test/resources.