El Futuro es Hoy: Aprovechando la IA en las Pruebas de Software

¡Hola a todos! Mi nombre es Mesut Turkal. Soy un ingeniero de aseguramiento de calidad de software, y en esta sesión, quiero hablar sobre la integración del machine learning en nuestras actividades diarias de pruebas de software. El machine learning es hoy en día un tema muy candente, todo el mundo habla de ello, todo el mundo intenta sacar ventaja para mejorar su eficiencia. Entonces, ¿qué pasa con las actividades de aseguramiento de calidad, verdad? También podemos mejorar nuestra eficiencia, quizás podemos reducir algunas tareas manuales, y podemos de alguna manera sacar provecho del uso del machine learning en nuestras actividades en diferentes etapas. Entonces, esto es lo que haremos. Discutiremos la integración, o el aprovechamiento de las actividades de machine learning en diferentes etapas de las pruebas de software. Comenzaremos desde la primera etapa en el ciclo de vida, que es incluso analizar los requisitos y diseñar algunos casos de prueba, y luego discutiremos cómo podemos implementar el código de prueba también, porque la automation de pruebas es muy importante, y finalmente discutiremos algunas actividades de mantenimiento con la ayuda de las actividades de machine learning. Entonces, esto es lo que vamos a hacer. Primero que nada, vamos a revisar el contexto y por qué necesitamos mejorar nuestras actividades con la ayuda del machine learning. Y en la segunda parte de la presentación, esta es probablemente la parte más importante en la que pasaremos por todas las etapas en el ciclo de vida de las pruebas de software, y finalmente en la última parte compartiré un ejemplo práctico donde intenté usar el machine learning en mi proyecto personal y explicaré lo que hice y compartiré algunos resultados. Así que comencemos con la primera parte, la parte de introducción y las necesidades o el contexto de uso del machine learning en las pruebas de software. Necesitamos usar el machine learning para mejorar o apoyar nuestras actividades porque tenemos varios desafíos. Las pruebas de software ya no son fáciles. Las aplicaciones, los sistemas que estamos probando son demasiado complejos, demasiado complicados. Tenemos varias interfaces o interacciones y las aplicaciones que estamos probando están hablando, comunicándose con diferentes aplicaciones en diferentes plataformas, ¿verdad? Así que tenemos que probar o cubrir diferentes interfaces o integraciones. Esto significa que tenemos un amplio alcance para probar y, por supuesto, tenemos una restricción de tiempo. El tiempo es precioso. Es muy valioso. Y si nuestros casos de prueba están ralentizando los pipelines, entonces después de algún tiempo no será aceptable, ¿verdad? Porque los desarrolladores o los gerentes de producto comenzarán a quejarse de los casos de prueba, de los casos de prueba que se ejecutan lentamente, porque queremos solucionar nuestros fallos o los problemas lo más pronto posible. Queremos porque esta es una de las mejores entregas, una de las dimensiones de calidad en el contexto de la calidad. Pero para apoyar una entrega rápida, tenemos que hacer frente al tiempo. Tenemos que adaptar rápidamente nuestras soluciones. Tenemos que cubrir rápidamente un gran alcance e integraciones. Así que tenemos restricciones de tiempo, alcance, recursos, por supuesto, el presupuesto es un problema de recursos, quiero decir, costos y problemas de presupuesto. Así que desde muchas dimensiones diferentes, tenemos varios desafíos. Así que parece un poco difícil y duro hacer frente a este desafío. Pero quizás podemos encontrar alguna ayuda. Podemos obtener ayuda de alguien. Y ¿podrían las máquinas o los robots ser alguien que pueda ayudarnos? En realidad, pueden, porque incluso en nuestras rutinas diarias, en nuestra vida diaria, podemos ver en varias situaciones diferentes, ya nos están ayudando. Incluso si estamos viendo en algunas redes sociales

Ahora, en el tercer ejemplo, en términos de code generation, esta vez estoy siguiendo un camino diferente. Estoy comenzando con una consulta de Postman, y le pido que convierta esta consulta de Postman a diferentes lenguajes de programación, como, no solo Python, sino JavaScript, y algunos otros también. Entonces, primero, implemento mi consulta de Postman, y copio el valor de curl, y totalmente automatizado, ¿verdad? No pierdo tiempo. Todo es muy rápido, muy preciso, muy confiable. El código que se genera eventualmente es algo que puedo inyectar directamente en mi entorno de automation de pruebas. Continuando, hablando de la implementación de casos de prueba, cuando estamos haciendo la automation de la interfaz de usuario, el reconocimiento visual de los elementos es mucho más importante, ¿verdad? Porque tenemos que localizar los elementos en las páginas web, y cómo lo hacemos en las terminologías de automation de la interfaz de usuario, tenemos que localizar los elementos. De hecho, el código debería localizar los elementos. Normalmente, cómo lo hacemos es que usamos los atributos tradicionales de los elementos, o tal vez la ruta, o las clases, los ID de los elementos, pero todos sabemos que a veces son inestables. Podrían ser cambiados por el equipo de desarrollo. Pueden cambiar el diseño de la página, y a veces los localizadores se rompen. Entonces, ¿qué deberíamos hacer? Tal vez deberíamos, en lugar de usar esos atributos tradicionales o las clases, las rutas, ¿por qué no intentamos reconocer visualmente, como lo hacemos como seres humanos? Por ejemplo, cada vez que estamos escaneando la página web, con nuestros ojos, estamos tratando de ver dónde están los elementos, ¿verdad? ¿Dónde están los botones? En la esquina más a la izquierda, o en el medio de la página, ¿dónde está? Podemos verlo con nuestros ojos. Entonces, de la misma manera, podemos dejar que el código intente coincidir visualmente. Como, si lo entrenamos con varios iconos similares. Por ejemplo, en esta página, estoy compartiendo un repositorio abierto. Como es abierto, lo estoy compartiendo sin ninguna preocupación comercial. Puedes ir y comprobar. Hay varios iconos. Por ejemplo, en este caso, era un carrito de compras en línea. Si estás testing un sitio web en línea, entonces puedes entrenar de esta manera. Y cada vez que tengas un icono similar, no necesariamente 100% igual, pero uno similar, será reconocido como un carrito de compras. Y cada vez que hagas clic en él, puede ser reconocido allí, la ubicación. Y el código puede hacer clic en el elemento reconocido. Y podemos continuar con el resto de los pasos de la prueba. Continuando. Después, después de completar nuestra implementación, entonces podemos ejecutar el caso de prueba. Y lo que podemos hacer durante la ejecución de la prueba, podemos recopilar varias métricas. Por ejemplo, la duración de la ejecución. ¿Cuánto tiempo necesitamos para ejecutar para completar nuestra ejecución de la prueba? Por ejemplo, digamos que son 15 segundos por caso de prueba.

Y esto es la observación. Esto es el entrenamiento, ¿verdad? Y siempre que tengamos una nueva ejecución, si no toma 15 segundos, sino dos minutos, por ejemplo, no 15 segundos, no 20 segundos, sino dos minutos, es obviamente un valor atípico, ¿verdad? Entonces, en este caso, el algoritmo de machine learning puede advertirme, puede modificarme. Mi resultado esperado era alrededor de 15 segundos, porque esta fue mi observación anterior. Pero esta vez, tomó dos minutos. Por favor, ve y verifica si hay algo mal. Podría haber algunas respuestas que llegaron tarde por parte del sistema, o podría ser algo más. Entonces, todas estas observaciones se pueden hacer automáticamente. Y en lugar de ir a través de todas las ejecuciones, una por una, podemos ser notificados automáticamente sobre lo riesgoso, sobre la ejecución, que podría tener algunos valores atípicos o situaciones inesperadas.

Y la etapa final es el mantenimiento. Y la refactorización es una actividad, una opción que podemos hacer en la etapa de mantenimiento. Por ejemplo, revisar el código, o mejorar la refactorización del código. Entonces, si podemos enseñar de alguna manera a las máquinas a hacer revisiones de código, como si les enseñáramos las prácticas raíz, o incluso los anti patterns que debemos evitar, entonces pueden hacer las revisiones de código. Por ejemplo, siempre que tengo un número mágico codificado con dificultad dentro del código, y si enseño a las máquinas que no es un anti-patrón que quiero evitar, entonces puede, siempre que lo detecte, puede notificarme, encontré el anti-patrón aquí, por favor ve y revisa. Acelerará nuestros procesos porque de lo contrario lo que podríamos hacer, podríamos hacer solo revisiones por pares, y tomaría algún tiempo, verdad, enviaría mi código a un compañero de equipo, y él o ella revisará el código, proporcionará la retroalimentación. Revisaré de nuevo, tomará algún tiempo, irá de ida y vuelta, pero de esta manera ya podemos completar o incluso hacer la primera revisión con la ayuda de las máquinas. Y el auto-fallo es otra opción que podemos realizar, que es como siempre que un caso de prueba está fallando, podemos intentar entender la causa raíz automáticamente, y proporcionará algunas opciones para hacer la corrección para evitar este fallo. Y migrar, lo discutí en una de las diapositivas anteriores, como migrar de Cypress a Playwright o convertir de un marco a otro marco, todo eso se puede lograr entrenando nuestros modelos. Y finalmente, la última parte será un case study donde compartiré mis experiencias personales relacionadas con la gestión de bugs y explicaré cómo podemos incluso gestionar nuestros bugs o tickets en nuestros proyectos usando machine learning. Entonces, en este proyecto donde apliqué machine learning, tenía casi 900 tickets en nuestro sistema de seguimiento de problemas. Y en primer lugar, exporté estos tickets de la herramienta de gestión de proyectos a una hoja de cálculo de Excel, y tenía tres niveles de gravedad diferentes. Gravedad 1, 2, 3, ¿verdad? Y esos son diferentes niveles de criticidad, o niveles de prioridad. Entonces, lo que estoy tratando de hacer es clasificar esos bugs en diferentes niveles de gravedad. Entonces, lo que hice para este propósito es, en primer lugar, hice el preprocesamiento, como limpiar los data. Si necesito algún texto en las cadenas en las descripciones que se levantan dentro de los tickets, entonces los elimino, los elimino. O hago algunas formaciones, como eliminar la puntuación, o hacer que todas las palabras sean minúsculas. Entonces, hago este tipo de formaciones. Y luego hago la extracción de características. ¿Qué es la extracción de características? Como todos sabemos en la máquina learning, la descripción normal en inglés que escribo para describir mi problema, para describir mi bug, no puede ser entendida por las máquinas, ¿verdad? Porque este es nuestro idioma como humanos. Pero si queremos hablar, no a otro humano, sino a una PC, entonces no tengo que usar, o debería usar algunos otros idiomas, no inglés. Y es el lenguaje de la máquina. Y ¿cómo funciona? Tengo que convertir estas cadenas, estos valores de texto, en algunos números, básicamente ceros y unos. Esto es lo que una computadora entiende. Entonces, ¿cómo puedo hacer esta conversión? Puedo seguir diferentes enfoques. Pero lo que hice en el caso específico fue simplemente contar el número de frecuencias de palabras en cada oración. Y luego tendré los unos y ceros. Por ejemplo, si una palabra específica ocurre dos veces, tres veces en una oración, entonces la forma binaria de este número sería mi característica para esta muestra. Y después de tener las características, la siguiente etapa es hacer la clasificación en sí. Y finalmente, podemos recoger los resultados de estos modelos.

Permíteme compartir algunos resultados. En el primer ciclo, esta es la matriz de confusión que tenía. Y tenía alrededor del 73% de precisión. Luego intenté recoger la clase 2 y 3 juntas, y las etiquetas para eso eran 3 y 4. Fusioné esos dos solo para evitar sesgos, porque la clase 2 es la clase donde la mayoría de los bugs están etiquetados. Así que combiné 3 y 4. Lo que significa que la clase 2 para mí era importante detectar. Si tengo un ticket de problema de clase 2, entonces era un bloqueador de lanzamiento para mí, para decidir si la clase 2 o no es una decisión importante. Así que recopilo todas las demás en una clase. Y en este caso, tenía un 82% tal vez aún no es 100% suficiente para aprovechar en mis actividades porque era un problema difícil. Incluso para nosotros mismos, como humanos, a veces discutimos mucho sobre el triage de bugs, ¿verdad? Para mí, a veces es 72. Para alguien más, es un 73 o 4. Así que además de la clasificación, también podemos hacer el clustering. Y podemos gestionar nuestros bugs. Así que en resumen, podemos aprovechar machine learning en varias etapas diferentes, comenzando desde la generación de casos de prueba, y luego podemos hacer la code generation, la implementación, y finalmente las etapas de ejecución y mantenimiento también. Incluso desde nuestros bugs, tickers, podemos clasificarlos para hacer el triage de bugs, o tal vez agruparlos en diferentes grupos para gestionar fácilmente. Así que las palabras finales serían un tema muy candente, ¿las máquinas nos reemplazarán? ¿Perderemos nuestros trabajos debido a machine learning? Porque machine learning está llegando, todo el mundo está asustado, temeroso, hay una falta de claridad sobre lo que haremos en el futuro. Así que por ahora, por supuesto, no sé qué pasará en el futuro, pero por ahora, lo que diría es, si eres un gerente, si eres un CEO de una empresa, ¿qué harías? Contratarías a una persona sin una PC o una PC sin alguien que los opere. Por supuesto, lo que harías es contratar a una persona y darle una PC, ¿verdad? Así que harías una colaboración, harías uso de la colaboración entre esos dos. Entonces, ¿por qué estamos tratando de comparar, pero no solo tratando de hacer una colaboración? Así que estas serían las palabras finales, y muchas gracias por escucharme, y si tienes alguna pregunta, estaré encantado de intentar responderla. Supongo que tendremos un canal para eso, e incluso después del evento, estaré más que encantado de conectarme a través de las redes sociales que estoy compartiendo.