Proyecto Pruebas automatizadas

Semana 5: Pruebas E2E

Ya tenemos más claro cómo funcionan las pruebas de reconocimiento. Nos parece que son herramientas útiles para detectar “crashes”, excepciones y errores inesperados sin intervención humana. Entendemos que este tipo de pruebas requieren la disponibilidad de máquinas para su ejecución por varias horas y que se espera que se usen como complemento a pruebas funcionales. Sin embargo, consideramos que esto no es suficiente para evaluar la calidad de la ABP.

Por ejemplo, hemos utilizado pruebas manuales funcionales con un enfoque de E2E, es decir de “extremo a extremo”. Sin embargo, re-ejecutar los escenarios de pruebas de forma manual puede llevar a errores en la ejecución de la prueba y, lamentablemente, nuestros ingenieros suelen no documentarlos. Por lo tanto, como parte de su labor queremos que automatice las pruebas E2E. Con base en una revisión de blogs hemos encontrado que Cypress, Puppeteer y Playwright son herramientas apliamente utilizadas para hacer pruebas E2E basadas en scripts. Por otro lado, nuestros amigos de The Software Design Lab nos recomendaron usar su herramienta Kraken que permite hacer pruebas E2E, pero usando escenarios escritos en un estilo BDT (es decir, Behavior Driven Testing).

Resumen de las actividades

Creemos entonces que una buena forma de empezar sería implementando escenarios de prueba de las funcionalidades que su equipo seleccionó en su estrategia de pruebas. Para ello, les solicitamos que seleccionen mínimo 5 funcionalidades e implementen por lo menos 20 de los escenarios utilizando Kraken y algunas de las otras tres herramientas (Cypress, Puppeteer y Playwright). En otras palabras, los 20 escenarios de prueba deben ser implementados idénticamente tanto con Kraken como con la otra herramienta de su elección. Los escenarios deben utilizar todos los patrones vistos (Page Object, Given-When-Then), independientemente de la herramieta.

Para tal efecto, utilicen su repositorio de equipo (org Uniandes-MISW4103) para configurar las herramientas de automatización e implementar los escenarios de prueba. Los escenarios deben ser ejecutados en la ABP, utilizando la versión definida para el proyecto, con el fin de asegurar que las pruebas estén bien construidas.

Detalles de la entrega

La entrega debe ser realizada utilizando el repositorio de trabajo dado por el equipo docente (en caso de no poder acceder a la organización del curso, Uniandes-MISW4103, contacten al equipo docente). Su equipo debe crear un release en el repositorio (ver cómo crear un release) con los siguientes elementos:

(*) Los videos y documentos que incluyan en su entrega deben estar alojado en algún gestor de contenido (Google drive, OneDrive, Youtube, etc), deben ser públicos o deben permitir el acceso a cuentas de la Universidad de Los Andes (@uniandes.edu.co). Para el caso de documentos, estos deben estar en formato .pdf.

Criterios de evaluación

  1. “Fatalities”.

    Nota: el incumplimiento de cualquiera de los aspectos mencionados a continuación puede incurrir en una penalización sobre la calificación de la actividad.

    • El repositorio del equipo (org Uniandes-MISW4103) NO cuenta con un release, creado dentro del plazo establecido, en donde se incluyen todos los entregables de la actividad. [-15 puntos]
    • Los archivos README de las herramientas de automatización NO describen los pasos para la instalación y ejecución de los escenarios de prueba. [-20 puntos x herramienta]
    • Se incluyen archivos multimedia (videos, logs, imágenes, etc.), documentos no-planos (.pdf, .xlsx) o dependencias/librerías (node_modules) dentro del repositorio. [-20 puntos]

  2. Pruebas con la herramienta de automatización de su elección. [40 puntos]

    • Los 20 escenarios de prueba se encuentra en el repositorio del equipo (./e2e/*), y se ejecutan exitosamente. Cada prueba debe contar con el identificador asociado al escenario de prueba [20 puntos]
    • Los escenarios de prueba utilizan correctamente el patrón Page Object. [10 puntos]
    • Los escenarios de prueba utilizan correctamente el patrón Given-When-Then. [10 puntos]

  3. Pruebas con la herramienta de automatización Kraken. [40 puntos]

    • Los 20 escenarios de prueba se encuentra en el repositorio del equipo (./e2e/*), y se ejecutan exitosamente. Cada prueba debe contar con el identificador asociado al escenario de prueba [20 puntos]
    • Los escenarios de prueba utilizan correctamente el patrón Page Object. [10 puntos]
    • Los escenarios de prueba utilizan correctamente el patrón Given-When-Then. [10 puntos]

  4. Reporte de la Actividad. [20 puntos]

    El reporte de la actividad de su repositorio de equipo (./actividades/actividad-semana-5):

    • Se listan las funcionalidades seleccionadas para las pruebas E2E. Cada funcionalidad cuenta con un identificador único, un nombre, y una descripción. [5 puntos]
    • Se listan los escenarios pruebas E2E. Cada escenario cuenta con un identificador único, una descripción, y la funcionalidad asociada. [5 puntos]
    • El resumen de los pros y los contras de la herramienta de automatización seleccionada es coherente con la herramienta. [5 puntos]
    • El resumen de los pros y los contras de la herramienta Kraken es coherente con la herramienta. [5 puntos]

La evaluación tendrá en cuenta la inclusión de la totalidad de componentes solicitados y la calidad de cada uno de acuerdo con la rúbrica establecida.