¿Por qué el seguimiento es un salvavidas para las pruebas de extremo a extremo de los sistemas distribuidos?

¡Hola a todos! Soy Burak de Tandra. Estoy muy emocionado de estar aquí con todos ustedes hoy, y espero que estén pasando un buen momento viendo a todos estos excelentes oradores aquí en la Cumbre de TestJS.

Hoy voy a hablar sobre cómo el seguimiento puede ayudarte a encontrar las causas raíz en tus fallas de prueba, fallas de prueba de extremo a extremo en tus sistemas distribuidos. Antes de entrar en eso, permítanme presentarme, y también presentarles a Tandra.

Soy Burak, y trabajo como gerente de producto aquí en Tandra. Además de mi carrera profesional, me pueden ver jugando tenis en la cancha, y Tandra construye herramientas modernas para desarrolladores e ingenieros de QA que desarrollan y entregan aplicaciones, aplicaciones modernas en la nube. Nuestro producto estrella, Foresight, te ayuda a monitorear y depurar tus flujos de trabajo de CI-CD y pruebas.

Hoy vamos a hablar sobre por qué fallan las pruebas de extremo a extremo, cómo depurarlas y cómo el seguimiento puede ayudarte a encontrar las causas raíz más fácilmente. ¿Por qué están fallando? ¿Por qué fallan las pruebas de extremo a extremo? Están tratando de verificar si todas las partes de tu sistema funcionan correctamente. En resumen, están verificando toda la aplicación de atrás hacia adelante. Puede haber varias razones de fallas, y una de ellas son los problemas de tiempo de espera. Si tienes varios servicios comunicándose entre sí, las respuestas no serán instantáneas, por lo que puede haber problemas relacionados con el tiempo.

Otra cosa es que una prueba puede depender de otra. Entonces, si una falla, puede haber diez fallas más desde esa primera falla. Otra, y la más importante, son las comunicaciones entre servicios. Dado que las pruebas de extremo a extremo pueden tener diferentes servicios esperando las respuestas entre sí, imagínalo como si tuvieras un sistema de pago esperando el retorno de un carrito de compras, por lo que puede haber una posible falla de un servicio diferente. Incluso si obtienes un error de servicio 500, no te dice qué sucedió realmente y dónde sucedió.

Cuando ocurre un error, puedes depurarlo revisando los registros, obviamente. Te brindan un resumen de toda la ejecución, y aunque las herramientas modernas y los ID resaltan el error exacto, puedes terminar perdido en miles de líneas para encontrar la razón exacta de la falla. Y también puedes verificar artefactos como capturas de pantalla y grabaciones de video. Estas pruebas de extremo a extremo contienen escenarios de prueba de extremo a extremo que incluyen la experiencia de los usuarios. Por lo tanto, puedes obtener ayuda de ese tipo de artefactos. Sin embargo, puede que no sea suficiente para ver qué sucedió detrás de las cortinas, como mencioné, especialmente si estás trabajando en microservicios. El seguimiento puede ayudarte a detectar ese tipo de fallas más fácilmente. El seguimiento es una práctica común de los desarrolladores para analizar y comprender toda la aplicación data y el flujo. Supongamos que algo sale mal en una aplicación monolítica, un desarrollador solo necesita revisar la traza de la pila, ya que toda la aplicación se ejecuta en una sola ejecución, se ejecuta en un solo proceso para averiguar qué sucedió realmente. Ahora, imagina esa situación con una aplicación distribuida, que potencialmente consta de múltiples funciones lambda, y hay algunos servicios externos, bases de datos externas, servicios de autenticación con los que tu aplicación necesita funcionar. No solo es fácil probar ese tipo de aplicaciones, sino que también estás tratando de encontrar la causa raíz de las fallas. Es realmente un problema desafiante, y ese tipo de escenarios necesita herramientas especiales. Y afortunadamente, Tundra Foresight es esa herramienta especial para ingenieros de QA y de compilación. Estás viendo el resultado de un caso de prueba único visualizado en el panel de control de Tundra Foresight. No solo te proporciona los registros, mensajes de error e historial de rendimiento, si tu caso de prueba incluye capturas de pantalla, también puedes verlas en el panel de control de Tundra Foresight. Y también, con la ayuda de nuestra novedosa tecnología de seguimiento distribuido, es fácil visualizar toda la aplicación en un solo mapa de seguimiento. Con la ayuda del seguimiento distribuido, puedes verificar el intercambio de mensajes entre diferentes tipos de servicios. Y si hago clic en el mapa de seguimiento, obtendré un mapa, en realidad un flujo que visualiza la ejecución de la prueba JEST completa. Estás viendo la ejecución de la prueba JEST. Y toda la prueba de extremo a extremo requiere alguna transacción entre servicios de AWS como API Gateway y Lambda. Y si te fijas, hay una flecha roja entre Lambda y DynamoDB aquí, estás viendo una flecha roja. Entonces, si hago clic en eso, obtendré un resumen de esas transacciones. Y después de navegar por el gráfico de seguimiento, encontraré el spam erróneo que obtendré con la ayuda de la depuración de viaje en el tiempo. Puedo ver que hay algún error, guardando un elemento en R en mi solicitud de mapa de adición, por lo que puedo detectar rápidamente la razón de la falla. En resumen, todo falla todo el tiempo, pero tenemos un tiempo limitado para encontrar ese tipo de errores. Entonces, las capacidades de seguimiento y de Tundra nos ayudan a encontrarlos fácilmente, nos ahorran tiempo, no necesitamos reproducir el flujo completo de la aplicación una y otra vez. Solo necesitas navegar por el flujo de la aplicación y encontrar las causas raíz de tus pruebas y solucionar errores y detectar cuellos de botella en tus pruebas. Así que gracias por escucharme, eso es todo por hoy. Si tienes alguna pregunta, no dudes en hacerla y estaré encantado de escuchar tus comentarios y responder tus preguntas. ¡Si quieres probarlo, ve a tundra.io!