Y una de las cosas que escucho con frecuencia es que apuntan a acortar los ciclos de lanzamiento. Ahora, eso podría ser debido a N número de razones. Eso podría ser debido a, ya sabes, innovation donde quieren implementar nuevas características o tal vez solo quieren corregir los errores para mejorar la experiencia para los clientes o tal vez simplemente refactorizar el código para una mayor estabilidad de su aplicación en general.
Ahora, todos sabemos que estas herramientas de automation han existido. Y aunque los usuarios y clientes con los que he estado hablando han implementado una suite de pruebas de extremo a extremo, todavía existe un problema más grande, y es la infraestructura de pruebas en la que se ejecutan las pruebas. Y desafortunadamente, esta infraestructura en la que se ejecutan las pruebas, si no está realmente a la altura, aumenta significativamente el tiempo de ejecución de las pruebas.
Ahora, hablemos de la infraestructura en sí. Hablando de la infraestructura interna, si estás en ella, en primer lugar, lleva mucho tiempo construir y mantener esta infraestructura. Y si no está realmente a la altura y personalizada según las necesidades del equipo de QA, se vuelve muy difícil escalarla. Y también esto agrega mucho costo para mantener todo este esfuerzo. Y el segundo aspecto es el alto tiempo de ejecución de las pruebas. Ahora, es muy, muy importante, especialmente para los equipos modernos de QA y desarrollo que se centran en aumentar sus velocidades de lanzamiento y enviar código más rápido. El alto tiempo de ejecución de las pruebas es uno de los mayores obstáculos que escuchamos con frecuencia. Y nuevamente, como dije, no es el problema de la suite de automatización de extremo a extremo, sino es la velocidad de lanzamiento a la que apuntan. Y uno de los obstáculos nuevamente, es debido a las horas y horas que lleva ejecutar tu suite de pruebas.
Ahora, si observas este gráfico a la derecha, al comenzar tu suite de pruebas, normalmente solo toma segundos ejecutarla. Y a medida que escalas tu suite de pruebas, como sabes que tu suite de pruebas, el tiempo de ejecución está relacionado proporcionalmente con el código que envías. Entonces, cuanto más código envíes, más scripts de prueba se escriben y tus casos de prueba crecen. Ahora, a medida que avanzas hacia la suite enterprise, donde tienes miles de pruebas, tu tiempo de ejecución pasa de minutos a horas para completarse. Y ese es un problema más grande para resolver porque tus desarrolladores están esperando recibir la retroalimentación del código que han escrito. Ahora, es posible que hayas notado que aquí estamos esperando que las pruebas se completen, y nuevamente, con la infraestructura deficiente en la que estamos ejecutando las pruebas, estamos afectando la productividad tanto de los equipos de QA como de desarrollo.
Ahora, el tercer problema son las pruebas inestables a gran escala. Ahora, las pruebas inestables pueden ser debido a una serie de razones. Especialmente cuando estás ejecutando tus pruebas en una infraestructura, puede haber muchos problemas relacionados con el consumo de CPU. Puede haber un alto consumo de recursos en la máquina en la que estás ejecutando una prueba, lo que conduce a resultados inestables. Ahora, este es un problema mucho más grande para resolver. Y uno de los aspectos clave es que si ves, si correlacionas tu alto tiempo de ejecución de pruebas con tu ciclo de lanzamiento, puedes ver directamente que el alto tiempo de ejecución de las pruebas está llevando a ciclos de lanzamiento retrasados. Entonces, el tiempo de retroalimentación que tardas en volver al desarrollador también se está alargando. Ahora, todos sabemos que este problema existe. Ahí es exactamente donde entra en juego Lambda Test. Estamos construyendo una plataforma de calidad continua en la cloud donde puedes probar con confianza en tu infraestructura y escalar tus pruebas también.
Comments