Proceso de automatización de pruebas en entornos web
Con el objetivo de lograr una alta calidad de los sistemas desarrollados, haciéndolos más robustos frente a fallos y evitando que el producto final tenga errores tanto de requerimientos, como de diseño o funcionalidad, se realizan las pruebas de software, en donde se tienen planteadas distintas metodologías que ayudan al desarrollo de las mismas. En algunos casos, estas pruebas se pueden tornar algo dispendiosas, repetitivas y consumir mucho tiempo en casos como llenar un formulario en una página web que recibe muchos datos. Por esta razón lo ideal es implementar procesos de automatización de pruebas que permitan asegurar la calidad del servicio sin afectar los tiempos de entrega al usuario.
Desde Agile testing hacemos pruebas automatizadas por los siguiente:
- Ahorro de tiempo en procesos repetitivos y constantes que en algunos casos se vuelven tediosos al momento de ejecutar la prueba manualmente.
- Se puede alinear con sistemas de integración y despliegue continuo, de modo que cuando el software cambia, este se prueba automáticamente sin intervención manual haciendo que los ciclos de pruebas de regresión sean más cortos.
Estos procesos de automatización de pruebas ayudan a las empresas en la optimización del tiempo, porque la ejecución es automática, liberando tiempo a los testers para que hagan tareas de mayor valor.
Es importante mencionar que existen varios tipos de pruebas automatizadas:
- Pruebas unitarias y de componente
- Pruebas de integración.
- Pruebas de contrato
- Pruebas de interfaz de programación de aplicaciones
- Pruebas de interfaz gráfica de usuario.(End to End)
En este artículo nos enfocaremos en la última.
Pruebas End to End
Las pruebas End to End (E2E) son aquellas que validan de principio a fin una aplicación web y que permiten identificar fallas en la interfaz de usuario, además son más cercanas a escenarios reales de uso que realiza el usuario final, a continuación se mencionan algunas características del End-to-end Agile testing:
- Prueba todo el flujo del software desde el punto de vista del usuario final.
- Prueba el software desde la interfaz de usuario y no desde el código interno.
- Está enfocada en detectar posibles problemas que pudieran encontrar nuestros usuarios en su interacción con el flujo general del programa.
En este diagrama se muestra el paso a paso general que se realiza desde Quind Agile testing al momento de desarrollar un proyecto de testing funcional para las pruebas E2E web:
-
-
- Fig 1. Etapas para el Proceso Testing pruebas funcionales.
-
Etapa 1: Identificación y Planeación
Es una de las etapas más importantes, se debe proceder a identificar los puntos claves del software, revisar su funcionamiento y cómo se implementó. Para desarrollar la etapa de identificación se debe tener en cuenta los siguientes aspectos:
-
- Entendimiento del software desarrollado y la contextualización del negocio con el fin de tener una idea clara de la construcción y la funcionalidad que se debe realizar para ese proyecto específico
- Revisar cada aspecto funcional del software por medio de reuniones de entendimiento técnico con los arquitectos y desarrolladores explicando la complejidad técnica del sistema.
- Planear revisiones periódicas del proceso
Etapa 2: Escenarios de prueba y implementación
Mediante reuniones de diseño de pruebas se identifican específicamente los puntos a probar, se pueden requerir múltiples reuniones con el cliente ya que en la mayoría de los proyectos se presentan evoluciones en algún momento del proceso y pueden cambiar el alcance.
Para la construcción del plan de pruebas, se tendrán en cuenta los siguientes puntos:
- Alcance de la prueba: este tópico demuestra hasta donde se llegará la prueba y que no estará incluido en la ejecución del proyecto.
- Ambiente de prueba: los elementos suficientes para realizar las pruebas.
- Cobertura en pruebas: es un punto donde se analizará hasta dónde pueden llegar los escenarios que se podrán automatizar.
Una vez se haya obtenido un contexto más claro del funcionamiento y por ende los puntos a probar del software, el ingeniero automatizador de pruebas deberá configurar y realizar los scripts de ejecución que permitan implementar los escenarios de pruebas óptimos para un entorno de testing con el fin de validar las funcionalidades.
En primer lugar en las pruebas automatizadas, se tiene un entorno de pruebas local, el cual tiene un alcance inicial al momento del diseño y construcción de las mismas, Una vez las pruebas automatizadas están construidas, estas se integran en el pipeline (ciclo DevOps) de despliegue en el ambiente de pruebas.
Para la automatización y ejecución de las pruebas se utilizan diferentes tecnologías, entre ellas las más destacadas son:
- Framework Selenium
- Framework Cypress
- Gherkin-Cucumber
Sin embargo desde Quind exploramos, aprendemos, co-creamos y adaptamos tecnologías acuerdo a las necesidades de negocio.
Etapa 3: Implementación de escenarios de prueba
La idea principal es que tanto la capa de negocio y tecnología tengan un total acercamiento frente a la necesidad del proyecto mediante un lenguaje de negocio, en nuestro caso usamos Gherkin.
Las pruebas funcionales automáticamente validan los requerimientos y requisitos que se plantearon al inicio del proyecto es por eso que es necesario implementar los escenarios de prueba en un lenguaje de negocio semiformal en el cual los miembros de: equipo de desarrollo, equipo de personal no técnico, equipo de Quality Assurance(QA) tengan un lenguaje específico de dominio legible.
Nosotros usamos el siguiente patrón para escribir pruebas automatizadas end to end: Feature-Given-When-Then:
Feature: Escenario a probar.
Given: (Dado), se especifica como tal escenario y las precondiciones.
When: (Cuando), se define las condiciones de las acciones a ejecutar en el proceso.
Then: (Entonces), cuál es el resultado esperado, o en su caso como se define en software; las aserciones esperadas.
Conclusión:
El proceso descrito habilita un esquema de Agile Testing que garantiza la calidad del software construido sin afectar los tiempos de entrega. Te invitamos a probarlo y hacer continuous testing dentro de tu empresa.
Conoce más sobre pruebas automatizadas aquí
Referencias
[1].Cucumber. Retrieved 10 December 2021, from https://martinfowler.com/bliki/GivenWhenThen.html
[3]Modelo caja negra. Retrieved 10 December 2021, from https://howtotesting.com/testing-funcional/pruebas-de-caja-negra/
[4] Black Box testing. Retrieved 10 December 2021, from https://softwaretestingfundamentals.com/black-box-testing/
[5].Experiences with Selenium and Cypress. Retrieved 10 December 2021, from https://medium.com/@arnonaxelrod/my-experience-moving-from-selenium-to-cypress-2a23072993e5
[6] Selenium with java Retrieved 10 December 2021, from https://www.browserstack.com/guide/selenium-with-java-for-automated-test
[7] WorkFlow Selenium Retrieved 10 December 2021, from https://www.tutorialselenium.com/tutorial-selenium-webdriver/
[8] WorkFlow Cypress Retrieved 20 December 2021, from https://www.edgewordstraining.co.uk/cypress-vs-selenium/
[9] Installing Cypress Retrieved 20 December 2021, from https://docs.cypress.io/guides/getting-started/installing-cypress