¡Bienvenidos a la Wiki de pruebas automatizadas E2E para la aplicación Ghost! En esta wiki encontrarás información detallada sobre las pruebas automatizadas realizadas en la aplicación Ghost, utilizando dos herramientas populares de pruebas E2E: Cypress y Kraken. En total, se llevaron a cabo 50 escenarios de prueba, 30 utilizando Cypress y 20 utilizando Kraken, para asegurar que la aplicación Ghost funcione de manera óptima y libre de errores. De los 20 escenarios realizados con Cypress inicialmente, 10 fueron modificados para la versión de Ghost 4.44.0 y posteriormente para realizar Visual Regression Testing entre versiones.

• Video de la estrategia
• Documento
• Inventario de Pruebas

• Son pruebas económicas y rápidas.
• Puede detectar errores que pasarían desapercibidos en otras pruebas.
• Puede generar varias entradas y escenarios de uso.
• No se requiere una planificación exhaustiva para probar.

• No da resultados muy dicientes en cuanto a su funcionamiento se refiere.
• Solo detecta errores superficiales y no profundiza en ellos.
• No puede reemplazarse por pruebas detalladas y bien definidas.
• Alta cantidad de eventos inválidos o inexistentes.
• Bajo nivel de cobertura de la aplicación analizada.

• Facilidad en la instalación.
• Ejecución en varios navegadores.
• Facilidad en la extracción de la información.
• Automatizar pruebas repetitivas.
• Facilidad en el descubrimiento de nuevas vistas.

• Consumo de memoria y recursos del sistema.
• Ejecución lenta de las herramientas.

• No hay necesidad de instalar dependencias adicionales, las pruebas se pueden hacer directamente en un navegador web.
• Tracking de cada paso de las pruebas por medio de pantallazos
• Grande cantidad de métodos para buscar y seleccionar elementos HTML
• Fácil de usar e implementar
• Buena visibilidad de las pruebas, sus pasos y sus estados

• Difícil trabajar con herramientas que utilicen frecuentemente funciones asíncronas que necesiten de awaits
• Curva de aprendizaje mediana
• No hay soporte para Given, When, Then sin herramientas externas. (Solo se pueden realizar comentarios)

• Fácil de trabajar usando el patrón Given, When, Then
• Facilidad de ejecución de pruebas en paralelo
• Tracking detallado de la ejecución de escenarios mediante reportes

• Documentación limitada
• Tiene problemas para correr más de un escenario secuencialmente
• Demasiadas dependencias necesitadas, incluso varias que no se utilizan si solo haces testing de aplicaciones web
• Curva de aprendizaje lenta
• Menos opciones para operar sobre HTML que cypress. No reconoce ciertos elementos que cypress sí.

• Identifica de manera rápida y precisa si ha habido cambios en la apariencia visual de la aplicación.
• Puede comparar imágenes de diferentes tamaños y formatos, lo que permite trabajar con diversas capturas de pantalla.
• Ofrece la posibilidad de establecer umbrales de diferencia, lo que ayuda a reducir los falsos positivos.
• Permite generar imágenes de diferencias para comprender visualmente los cambios en la aplicación.
• Es compatible con varias herramientas de automatización de pruebas, como Cypress y Puppeteer.

• Sensibilidad a cambios menores.
• Solo puede comparar dos imágenes a la vez, lo que puede ser una limitación si se desea comparar varias imágenes con un patrón común.
• La calidad de la imagen puede afectar la precisión de la comparación.
• Requiere ser integrada en el código de prueba automatizado.
• Falta de documentación.

• Fácil de usar y configurar, lo que hace que la automatización de pruebas de regresión visual.
• Generación de informes de las pruebas realizadas.
• Compatibilidad con múltiples navegadores y dispositivos.
• Integración con herramientas de automatización como Cucumber.
• Enmascaramiento que permite a los usuarios excluir elementos específicos de la comparación de imágenes.
• Es escalable y puede utilizarse para pruebas de regresión visual en proyectos pequeños y grandes.

• Requiere cierta curva de aprendizaje al utilizarla por primera vez.
• Configuración inicial puede ser un poco complicada, especialmente si se tienen proyectos grandes o complejos.
• Crea una gran cantidad de archivos de imagen, lo que puede ocupar mucho espacio en el disco duro y aumentar el tiempo de ejecución de las pruebas.
• Posible necesidad de herramientas adicionales para poder ver las diferencias entre las imágenes.
• El proceso de comparación de imágenes puede ser lento en proyectos grandes con muchas páginas y/o elementos visuales complejos.

Para el ejercicio de la semana 7 se plantearon 120 casos de prueba que vienen de 40 escenarios previamente diseñados los cuales fueron realizados con la herramienta de automatización Cypress. Para la mayoría de los escenarios se trabajaron las tres técnicas de generación de datos: A-priori, Pseudo Random y Random, a continuación se detalla la distribución de escenarios utilizados:

Para la generación de datos a-priori, se utilizó la creación de conjuntos de datos previamente construidos para los diferentes escenarios de prueba que se iban a realizar con esta técnica. Estos datos pregenerados se encuentran en la carpeta src/cypressTests/cypress/e2e/dataGeneration/aprioriData. Los datos específicos de cada caso se encuentran en el archivo de su sección respectiva.
Los casos específicos realizados con esta técnica son los siguientes:

Para la generación de datos pseudo aleatorios, se utilizó la herramienta Mockaroo donde se crearon esquemas y endpoints de la API para cada uno de los casos de prueba trabajados con esta técnica. El API de Mockaroo permite generar datos realistas, lo que ahorra tiempo y esfuerzo en la creación manual de conjuntos de datos de prueba. Además, es flexible y se integra fácilmente en flujos de trabajo. También ofrece opciones de personalización para adaptarse a los requisitos específicos de cada escenario, con lo cual nos permite establecer las reglas de cada caso para que cumpla con lo requerido por el contexto.

Nuestro equipo creó un proyecto de Mockaroo donde se guardaron todos los esquemas y endpoints utilizados para cada uno de los casos, el proyecto se ve de la siguiente manera en la página de mockaroo:

Un ejemplo de cómo se ve uno de los muchos esquemas trabajados en esta técnica de pruebas se ve de la siguiente manera:

NOTA IMPORTANTE: El key de Mockaroo tiene un límite de 200 usos diarios, es posible que si intentan ejecutar todas las pruebas al tiempo se bloquee el API de Mockaroo, impidiendo generar más datos y fallando así las pruebas.

Los casos de prueba que trabajaron un pool de datos pseudo aleatorio fueron:

Para la generación de datos aleatorios, se utilizó datos de faker, provistas propiamente por faker.js. Faker permite simular datos realistas y variados. Los datos generados con Faker son aleatorios pero siguen patrones y formatos coherentes, lo que facilita la creación de casos de prueba. Además, Faker proporciona una amplia gama de opciones para generar datos en diferentes idiomas, regiones y categorías. Sin embargo, cabe resaltar que a pesar de que los datos sigan patrones coherentes, puede llegar a darse la posibilidad que se genere un dato inválido ya que no tenemos mayor control (adicional a la categoría) sobre los datos producidos. Los casos que trabajaron la técnica de generación de datos aleatoria fueron: