Pirámide de Testing: La Ruta hacia un Software Confiable

La pirámide de pruebas de software, también conocida como la pirámide de Cohn, es un framework que propone la agrupación de dichas pruebas en capas y la cantidad relativa que se debe crear por cada capa. Básicamente se trata de una guía que ayuda a crear pruebas más eficientes y se obtiene como resultado un software más confiable. Mike Cohn creó una estructura en forma de pirámide para permitir a los equipos que trabajan con metodologías ágiles organizar las pruebas. Así nacía el concepto de la “Pirámide de Cohn” y presenta la siguiente distribución:

 

Las pruebas unitarias están en la parte inferior y representan las pruebas más granulares, de las cuales debería haber una gran gama. La siguiente capa en la pirámide es la de servicio o pruebas de integración. Aquí es donde se comienza a probar cómo interactúan los diferentes componentes de software entre sí, ya sean integraciones internas o externas. La prueba de extremo a extremo (E2E) es la más compleja y prueba el software en su conjunto para asegurarse de que funciona como se espera de principio a fin.

 

  • Pruebas unitarias

Están centradas en la parte más pequeña del diseño del software. Se trata de probar una pequeña porción de código, típicamente una función/método o hasta una clase, para determinar si cumple su función correctamente. Las características de estas pruebas son simples y rápidas, por lo que se desea un gran porcentaje de ellas en esta capa. Cuando falla una prueba unitaria, los desarrolladores reciben una alerta y pueden determinar rápidamente cuáles son las consecuencias no deseadas de los cambios en su código.

 

  • Pruebas de integración

Las pruebas de integración se encuentran en el nivel medio de la pirámide de testing. Cuando las pruebas unitarias son muy granulares, en este nivel utilizamos pruebas que comienzan a verificar que los paquetes más grandes de código funcionan correctamente juntos.

Estas pruebas son más lentas de ejecutar que las pruebas unitarias y requieren que su software se implemente en un entorno de prueba, pero pueden detectar problemas más complicados que las pruebas unitarias pasan por alto. Son cruciales para probar el software implementado de manera eficiente en comparación con las pruebas de un extremo a otro.

Debido a que el alcance de las pruebas es más amplio, aumenta el tiempo para diagnosticar y solucionar problemas. Sin embargo, al igual que con las pruebas unitarias, las pruebas de integración se pueden repetir hasta que todas las pruebas sean exitosas.

 

  • Pruebas de un extremo a otro (E2E)

Las pruebas de un extremo a otro prueban toda la aplicación de software. Utilizan datos y un entorno de prueba para simular el funcionamiento de dicho software en el mundo real. Es el más caro de mantener y el más lento de ejecutar. Dado que las pruebas E2E prueban aplicaciones completamente ensambladas, también es la fase más difícil en la cual diagnosticar posibles errores.

Este tipo de pruebas no puede mantenerse sin ningún tipo de automatización, a menos que se haya diseñado previamente un test plan sólido que muestre detalladamente cómo se deben realizar dichas pruebas.

Pirámide de testing automatizada de Quabu

Cualquier pirámide de testing debería construirse sobre una base sólida de un análisis de código profundo, siguiendo el modelo de calidad del producto software definido por la ISO/IEC 25010. Dicho modelo se encuentra compuesto por las ocho características de calidad que se muestran en la siguiente figura:

 

 

Para conseguir esta calidad de producto, Quabu presenta una pirámide de testing automatizada con diferentes herramientas de software en sus respectivas capas:

 

  1. Pruebas unitarias: se automatizan a nivel de tarea (Jest).
  2. Pruebas de integración: se automatizan a nivel de historia de usuario (Postman).
  3. Pruebas E2E: se automatizan a nivel de características (CodeceptJS + Selenium).

 

Cabe destacar también el proceso de automatización que Quabu lleva a cabo para la ejecución de dichas pruebas y las herramientas que también intervienen:

 

  1. Definición de requerimientos y condiciones para las historias de usuario: Confluence.
  2. Definición e implementación de los diferentes test cases: Jira-XRAY.
  3. Repositorio para las pruebas automatizadas: Bitbucket.
  4. Ejecución de las pruebas automatizadas: Jenkins.
  5. Validación y reporting de los resultados obtenidos: XRAY.

Leave a Reply