Pruebas de extremo a extremo: Buenas prácticas y dificultades

Pruebas de extremo a extremo es un método de prueba que garantiza que el flujo de comportamiento de una aplicación, tal y como está diseñada de principio a fin, funciona como se espera. Suele tener en cuenta los escenarios empresariales más críticos y los más probables. El objetivo de realizar pruebas completas y exhaustivas de toda la interacción entre el producto y el usuario es asegurarse de que los procesos empresariales funcionan correctamente en todos los sistemas integrados.

Formular una estrategia adecuada de pruebas de extremo a extremo plantea muchos retos a las organizaciones. Especialmente si su objetivo es automatizar procesos empresariales tan complejos.

En este artículo, nos gustaría compartir con usted las reglas de oro para la gestión de sus costes de pruebas, mientras que la realización de los beneficios de las pruebas. También compartiremos los errores más comunes que debe evitar. Veámoslos con más detalle.

Mejores Prácticas para Pruebas E2E

Mantenga la perspectiva del usuario final.

A la hora de diseñar y crear casos de prueba, piensa como un usuario final. Céntrate en las características de la aplicación, más que en su implementación.

Es una buena práctica incluir sólo rutas de alto valor en su estrategia de pruebascentrada en el modo en que los usuarios finales recorrerán el sistema para alcanzar un objetivo empresarial. Algunos ejemplos son los usuarios que se registran en una plataforma de comercio electrónico, crean nuevos pedidos de venta o planifican la entrega a domicilio o en la oficina. Son escenarios de gran impacto que hay que incluir en las pruebas de extremo a extremo. Son relevantes para los usuarios finales y tienen un gran impacto en los objetivos empresariales (por ejemplo, ingresos, calidad, velocidad, etc.).

Una buena forma de captar la perspectiva del usuario es utilizar documentos como historias de usuario, pruebas de aceptación y escenarios BDD, si están disponibles. Ponte en la mentalidad de alguien que utiliza la aplicación por primera vez y responde a algunas preguntas:

• ¿Qué intenta conseguir el usuario?
• ¿Es fácil y sencillo encontrar lo que busca?
• ¿Puede el usuario alcanzar su objetivo en pocos pasos?

Por mucho que seamos grandes fans de las reglas de oro anteriores, reconocemos que esto no es una tarea fácil para un probador solo. Por eso creamos soluciones que también permiten a los usuarios empresariales crear flujos de pruebas registrando las acciones que realizan a diario. Los usuarios empresariales pueden aportar la perspectiva del usuario final y ahorrar mucho tiempo a sus equipos a la hora de crear escenarios empresariales significativos y relevantes.

Pruebas basadas en riesgos.

La Prueba Basada en Riesgo (RBT) es una herramienta crítica para categorizar sus procesos de negocio de extremo a extremo basados en la criticidad del negocio. Esto es útil de varias maneras. En primer lugar, puede segmentar la funcionalidad en prioridades por ejemplo, P1, P2, P3, P4. Esto permite crear planes y calendarios de pruebas centrados en la prioridad. Puede decidir en el ciclo 1 probar todas las prioridades, pero durante el ciclo 2 centrarse únicamente en los procesos de negocio P1 y P2. Además, puedes asegurarte de que, al entrar en un ciclo de pruebas con plazos ajustados, centras las pruebas de P1 a P2 y de P3 a P4. Así, si te quedas sin tiempo, puedes te aseguras de probar primero los procesos más críticos.

Para determinar una característica de alto riesgo, hay que considerar tanto la probabilidad de que se produzca un fallo como el impacto potencial que tendría en los usuarios finales. Una matriz de evaluación de riesgos es una herramienta útil para identificarlos.

Existen otras, pero los perfiles de riesgo más habituales se basan en estas dos preguntas:

• ¿Cuál es el impacto del fracaso? Por ejemplo, un riesgo alto sería afectar a la generación de ingresos o detener la producción.
• ¿Cuál es la probabilidad de fracaso? Por ejemplo, un alto riesgo sería un gran número de interfaces dentro del proceso o un alto nivel de personalización/complejidad.

Piensa en Amazon.com o Booking.com. ¿Cuál sería el impacto de que sus sistemas no funcionaran, aunque fuera durante unos minutos? ¿Y que clientes de todo el mundo no pudieran generar negocio en ninguna de las dos plataformas?

Mantener el orden correcto.

El objetivo principal de un proceso adecuado de Garantía de Calidad es identificar los errores de aplicación en la fase más temprana en el ciclo de vida de entrega del software, donde el coste de resolución es menor. Por lo tanto, invertir esfuerzos en las pruebas unitarias y de integración es primordial para mantener un proceso de entrega de software sólido y fiable.

Las pruebas E2E no son menos importantes para este enfoque. Ayuda a identificar errores relacionados con el proceso de negocio, que son difíciles de encontrar en las primeras fases del proceso de entrega. Así pues, ejecutar primero las pruebas unitarias y de integración. A continuación, durante las pruebas de extremo a extremo, ejecute sus pruebas de humo críticas primero para garantizar que las aplicaciones integradas se comunican como se espera, seguido de comprobaciones de sanidad y otros casos de prueba de alto riesgo..

Cuando falla una sola prueba unitaria, es bastante fácil averiguar dónde se ha producido el defecto. A medida que las pruebas crecen en complejidad y tocan más componentes de una aplicación, el aumento de puntos potenciales de fallo hace que sean más difíciles de depurar cuando se produce un fallo.

La estructura, la organización y una buena comprensión de la lógica empresarial son fundamentales en las pruebas de extremo a extremo.

Gestione su entorno de pruebas y sus datos de prueba.

Haz que el proceso de configuración de tu entorno de pruebas sea lo más eficiente y coherente posible. Asegurarse de que los equipos de despliegue tienen requisitos claros para sus entornos de prueba es fundamental para el éxito. No hay nada más desmotivador para un equipo de pruebas que llegar a la mitad de un ciclo de pruebas y descubrir que un componente integrado no está conectado o tiene datos diferentes. Ejecutar una prueba de humo puede garantizar la comprobación de que todos los componentes integrados del sistema están en funcionamiento.

Si es posible, mantener los entornos de ensayo lo más cerca posible de la producción. Para ello, considere la posibilidad de realizar copias de seguridad de imágenes del entorno de producción. Y busque la infraestructura como código o la automatización de su infraestructura para ahorrar tiempo y reducir el error humano.

Una vez finalizadas las pruebas, refrescar los datos de la prueba (y posiblemente incluso tomar una instantánea) es una buena manera de asegurarse de que el entorno se puede restaurar fácilmente a su estado original. Esto asegura que realizar otra ronda de pruebas sea mucho más fácil para todos.

Específicamente con SAP, ha unido fuerzas con Qlik Gold Client para proporcionar un entorno SAP de no producción totalmente probado y documentado con datos codificados y anonimizados en horas en lugar de meses.. Esto es útil para la gestión de datos de prueba bajo demanda y la corrección de incidencias de producción. Para los casos de uso, echa un vistazo a la solución que construimos juntos.

Escollos

Veamos también los errores más comunes que puede cometer al ejecutar su estrategia E2E.

No ignores las pruebas defectuosas.

La mayoría de las veces, las pruebas de extremo a extremo fallan porque el entorno y los datos de prueba no están sincronizados entre sí, en lugar de por un error en el propio proceso de negocio. Los fallos más habituales pueden producirse cuando han cambiado los periodos financieros o se han producido movimientos de existencias, pero la prueba no lo ha tenido en cuenta.

Esto puede dar lugar a «pruebas defectuosas» de las que, si no se tiene cuidado, la gente empezará a desconfiar. Y si siguen fallando por lo que parecen ser razones aleatorias, los desarrolladores verán esas pruebas como molestas en lugar de útiles. Una prueba defectuosa puede dañar la reputación de tus actividades. No lo olvide.

Aísla las pruebas defectuosas, averigua qué está causando los problemas y, si es posible, diseña las soluciones en el caso de prueba. Una buena prueba de extremo a extremo configurará los datos que necesita, los utilizará y, cuando sea posible, los limpiará al final. Así se minimizan las posibilidades de que el fallo esté relacionado con los datos y los entornos.

Si está automatizando sus pruebas E2E, evite la pesadilla del mantenimiento del selector.

Aunque se trata de un consejo muy específico para las empresas que optan por automatizar su estrategia de pruebas de extremo a extremo, hemos decidido incluirlo, ya que puede ahorrarle mucho tiempo en el mantenimiento de sus escenarios de prueba.

Si está automatizando una aplicación web, necesitará aprovechar selectores estables para localizar los elementos de interfaz de usuario en la página. Seleccionando un selector estable te aseguras de que tu prueba no va a fallar en cada lanzamiento porque tu script no fue capaz de identificar el objeto correcto.

Hay varias formas de localizar un elemento de interfaz de usuario, pero no todas son lo suficientemente robustas. Este es el caso de los selectores CSS: las clases son susceptibles de cambiar, lo que significa más pruebas fallando por ello. Puedes usar selectores ID: raramente cambian, pero a veces lo hacen.

La mejor opción es crear un data-test=»valor_único» atributo. Se trata de un atributo que se añade al elemento de destino y que sólo se utiliza con fines de prueba. Mientras el valor sea único, la prueba será capaz de encontrarlo. Además, la mayoría de los desarrolladores/UX saben que no pueden manipularlo.

Las pruebas no deberían depender unas de otras.

Cada prueba debe ejecutarse de forma completamente independiente, y su resultado no debe depender del resultado de una prueba anterior. Además, si estás probando una aplicación web, asegúrate de que cada prueba comienza en una ventana nueva del navegador con todas las cookies borradas.

Lo que quieres es evitar el efecto dominó en el que un único fallo causaría demasiado ruido redundante en tu ecosistema de pruebas. Analiza tus pruebas y deshazte de las dependencias.

He aquí un ejemplo muy simplista:

• Prueba 1: el usuario se conecta
• Prueba 2: el usuario inicia sesión y crea una nueva oportunidad
• Prueba 3: el usuario asigna la oportunidad a un propietario

Podrías pensar que, ejecutando estas pruebas una detrás de otra, ahorrarías algo de tiempo. Sin embargo, si las pruebas 1 ó 2 fallan, las siguientes también fallarán. Básicamente has creado una cascada de pruebas fallidas.

Por lo tanto, asegúrate de evitar dependencias y de empezar en una nueva ventana del navegador.

Vuelve a ejecutar las pruebas antes de plantear una incidencia.

Como hemos mencionado antes, las pruebas E2E son complejas y tienen más probabilidades de fallar por razones indeterminadas. Si una prueba falla de forma impredecible de vez en cuando y se te han acabado las ideas para mejorar la fiabilidad, prueba a ejecutarla de nuevo. Y otra, y otra. Le sugerimos que lo haga tres veces, por si acaso, antes de plantear un problema.

No esperes que no necesite mantenimiento.

Realizar pruebas de extremo a extremo es un trabajo complejo. No esperes que no requiera mantenimiento. Cuanto más compleja sea tu aplicación con funciones añadidas, más mantenimiento necesitarás.

Conclusión

Ejecutar pruebas E2E puede ser un reto, pero todo comienza con un buen sistema de diseño de pruebas. Mantenga la perspectiva del usuario final y priorice los escenarios de mayor riesgo.

Cuida la calidad de tu entorno de pruebas y de tus datos de prueba. Ejecuta primero las pruebas unitarias y de integración. Asegúrate de que tus pruebas son lo suficientemente estables y deshazte de las pruebas defectuosas.

Unas reglas sencillas y las mejores prácticas harán que tu estrategia tenga éxito.