En esta entrada del blog quería hablar de las pruebas automatizadas y como, tras más de 15 años desarrollando, analizando y coordinando las tareas de los equipos de producto de Indenova, hemos ido incrementando nuestros niveles de calidad, por ejemplo, mejorando nuestro proceso interno del ciclo de vida de software (políticas, instrucciones de trabajo, procesos, etc.), actualizando nuestros productos, con formación y con herramientas de apoyo (Sonarqube, Jenkins, Jmeter, Selenium, OwaspZap, etc).
Uno de los grandes problemas que se tiene cuando se desarrollan productos de cierta complejidad, es saber cuando iniciar de manera efectiva el ciclo de pruebas. Todos sabemos que esas pruebas deben de iniciarse lo antes posible, pero claro, si estas pruebas son manuales y requieren dedicación de técnicos de QA o de cualquier otro perfil, entonces no es algo que pueda hacerse sin controlar su coste, ya que son horas que repercuten en la rentabilidad del proyecto.
La necesidad de automatizar las pruebas funcionales ha estado siempre presente en nuestro proceso de mejora continua, es un objetivo de la dirección de Indenova el conseguir mejorar la expectativa que tienen los clientes en nuestras soluciones, conseguir que sean más confiables, con mejor rendimiento, usables y todos aquellos apartados que son requeridos en un producto.
A continuación voy a comentar brevemente como Indenova lo está resolviendo:
Indenova tiene la necesidad de testear de manera continua sus productos, versiones y entornos y la integración continua permite por cada cambio en las librerías comprobar lo siguiente:
- Compilar el artefacto y sus dependencias.
- Ejecutar test unitarios.
- Publicar en Sonarqube las métricas de calidad y validar el cumplimiento del Quality Gate.
- Validar APIs.
- etc.
A las anteriores acciones le añadimos el poder ejecutar las pruebas funcionales automáticas, sin tener que invertir horas de nuestro personal en dicha verificación.
Mediante un pipeline Jenkins, se orquestan las pruebas funcionales de los diferentes productos, que serán ejecutadas tras cada implantación o bajo petición.
Cada «stage» del pipeline ejecuta los test funcionales automáticos de los productos incluidos en el plan de liberación (pipeline) que pueden ser: Plataforma, eSignaBPM, OAC, MailProcessor, eSignaMSG, SedeElectronicaMobile, eSignaDigitalScan, eSignaRM ,PortaFirmas, eSignaECM, eSignaBatchServer, etc.
Los test funcionales se han automatizado utilizando Selenium, Gherkin y Cucumber:
Las pruebas funcionales han sido definidas en el lenguaje Gherkin para permitir que sean legibles por perfiles de negocio (personal no técnico) y se utiliza Cucumber para ejecutar de forma automatizada estas pruebas funcionales.
En aquellas pruebas que requieran ejecutar interfaz gráfica web Indenova utiliza Selenium y Appium para el caso de dispositivos móviles.
Ejemplo de Gherkin:
El esquema de ejecución de las pruebas automáticas es el siguiente, ejecutando el pipeline de pruebas las veces que se requiera:
Con este sistema se pretende conseguir los siguientes objetivos:
- Asegurar el desarrollo de los productos.
- Generar un enfoque de detección y prevención de defectos en el sistema.
- Identificar bugs durante el desarrollo y al desplegar en el ambiente de preproducción.
- Validar que se cumplan los requerimientos funcionales establecidos.
- Generar conocimiento y aprendizaje conjunto de buenas prácticas de desarrollo.
- Validar los procesos y reglas de negocio establecidas.
- Recopilar mediciones de calidad del producto y del proceso.
- Validar los requerimientos mínimos para el funcionamiento de la aplicación.
- Minimizar costes en el proyecto.
