AI Puede Generar Pruebas para Ti, ¿Y Ahora Qué?

Hola a todos, y sí, estamos viviendo en un período muy emocionante, ¿verdad? Período emocionante y también preocupante, lo sé, pero al pensarlo, nos volvemos más y más productivos. Nos volvemos mucho, mucho mejores. Podemos construir cosas que podríamos haber hecho en semanas que queríamos hacer antes de 2023. Y ahora AI puede ayudarnos con casi todo e incluso puede ayudarnos a generar pruebas sin que lo pidamos.

Pero ahora surge otra pregunta. ¿Qué será? Bueno, ¿cómo vamos a escalarlo? ¿Cómo vamos a asegurarnos de que AI pueda ir más allá del concepto completo de generar pruebas y asegurarnos de que nuestro producto siga siendo de alta calidad y AI pueda seguir ayudándonos al máximo que pueda? Bueno, echemos un vistazo. Antes de eso, mi nombre es Maya. Soy Staff Software Engineer en Salesforce y me apasiona la accesibilidad de AI y el front-end. Estoy presentando un podcast llamado Build with Maya donde comparto mis ideas, experimentos y experiencia trabajando con AI y mi trayectoria en alta tecnología, ya sabes, trabajando con personas, habilidades blandas, etc.

Así que siéntete libre de suscribirte si quieres aprender más sobre AI y la carrera en alta tecnología. Suficientemente bueno. Así que ahora volvamos a nuestro tema. Bueno, sí, AI en hacer que la generación de pruebas se vuelva mucho más fácil, ¿verdad? Ahora mismo, si vas a Cloud Code, le pides que implemente un sitio web, implemente características, puede ir instantáneamente a agregar, lanzar algún contexto gratuito. Por ejemplo, puede ayudarte a generar pruebas de extremo a extremo, pruebas unitarias, y ya no estarás bloqueado por las pruebas al final de la implementación donde solo quieres marcar tu PR pero te olvidaste de las pruebas unitarias y ahora necesitas dedicar algo de tiempo para eso.

Pero eso también significa que se vuelve barato, tan barato generar pruebas. Sí, en realidad puedes olvidarte de eso, pero eso significa que cuanto más barata es la generación de pruebas, más barato puede ser tu código. La calidad de tu código también puede serlo, lo que significa que las malas pruebas ahora son muy baratas de aparecer. Veamos por qué quiero decir eso, ¿de acuerdo? Así que esta es la prueba. Esta es una prueba muy normal, prueba de integración, donde realmente probamos el proveedor, generamos la capacidad de imagen y validamos el resultado.

Esta prueba es una prueba válida porque valida la integración real del proveedor. Valida la respuesta real, y cuando la ejecutas con la configuración correcta, pasa localmente, ¿verdad? Pero, ¿significa eso que funciona? ¿Significa que realmente protege tu base de código? Bueno, mira la dependencia. Así que este tipo de prueba depende de tantas cosas imprevistas como la estabilidad de la red, latencia, límite de tasa, token, presupuesto y comportamiento del módulo porque diferentes módulos de generación de imágenes se comportan un poco diferente de los demás.

Puede generar algo menos, algo más, tal vez no genere nada en absoluto, o te quedes sin presupuesto de token, ¿verdad? Así que si colocas esta prueba en un CI CD para PR, si algo sucede, algo causa que falle, ahora aquí hay un par de preguntas. ¿Cómo sabemos si la falla es causada porque algo está mal en nuestra lógica de implementación? ¿O porque algo más sucedió en una de las dependencias que discutimos? Bueno, esto es exactamente por lo que lo llamo la trampa en la generación de pruebas porque la prueba generada es inválida, pero el lugar donde la AI la puso es absolutamente en el lugar equivocado.

Y porque está en el lugar equivocado, en este punto ya no es válida porque una vez que se ejecuta, no puedes controlar si falla por nuestra causa o si falla por algo que no conoces. Y eso nos lleva a otra cosa. Más pruebas no significa que tengamos más confianza aquí. Puedes tener 100 pruebas en tu base de código, puedes tener 100% de cobertura, cada línea está cubierta, eso no significa que tu código sea seguro porque la confianza no viene de la cobertura del código. Viene de saber de qué riesgo estamos tratando de protegernos, saber cómo verificarlo y cuándo debe ejecutarse la verificación.

Y por verificación me refiero a cuándo necesitamos comprobar si debemos poner la validación para la integración real del proveedor de imágenes en el CI CD o si debemos ponerla en la prueba de humo. Así que, eso nos lleva a una cosa. Por eso estamos aquí. Y eso significa que cuando hacemos la prueba de generación con AI, no nos da más confianza. Nos da algo oculto en la confianza, cualidades ocultas, dudas de las que aún no somos conscientes. Bien, así que echemos un vistazo a un ejemplo. Así que, esta es una nueva característica para mi blog, perdón, para mi sitio web donde tengo una página llamada lista de blogs donde muestro una lista de todos mis artículos y quería añadir una búsqueda. Entonces, lo que hace es simplemente mostrar una lista de los blogs, blogs disponibles por etiqueta, por descripción, por título. Perdón. Y también tiene estados vacíos, tiene estado de sin resultados y así sucesivamente.

Y me concentro en asegurarme de que la búsqueda sea rápida, los resultados deben ser en tiempo real y sin resultados obsoletos y debe venir con accesibilidad. Y por supuesto, porque mi página crecerá y mi sitio web crecerá, también debe ser escalable para que no sea difícil mantenerlo en el futuro. Bien, suena muy simple y directo, ¿verdad? Así que, echemos un vistazo a la validación o la prueba potencial que necesitamos para esta característica. Así que, tenemos un montón de cosas como la más importante y necesitamos asegurarnos de que funcione filtrando publicaciones por título o etiqueta. Así que, esta es la funcionalidad principal. Y luego tenemos el borrado cuando la consulta está vacía y la navegación por teclado, accesibilidad, que está excluida y así sucesivamente.

Bien, ahora pasemos a otra sección interesante. Si estás trabajando con pruebas, conoces la pirámide de pruebas unitarias, pruebas de integración y pruebas de extremo a extremo, ¿verdad? La pirámide clásica. También tenemos otra cosa llamada Agile testing quarens donde dividimos nuestra área de prueba en cuatro cuartos de quarens. El Q1, Q2, Q3 y Q4. Esto nos permite saber si una prueba débil es importante para una sección débil y si la prueba debe ser automatizada o manual.

Bien, así que en este caso, tenemos un montón de pruebas asumiendo que Clark o Gemini o Codex ya han generado las pruebas para que las uses. Ahora, ¿cómo vas a saber a cuál de estos tests pertenecen a qué quarens definidos aquí? Porque cada quaren importa para si lo pones en CI-CD o lo pones en prueba de simulación manual o prueba de interacción humana manual. Bien, echemos un vistazo. Entonces, filtrar publicaciones por etiqueta de título, vamos a la prueba unitaria porque esa es la implementación principal donde realmente validas la lógica técnica. Q2 es la prueba de aceptación. Podemos ponerlo como borrar cuando la consulta está vacía.

Q3 es cuando probamos todo el comportamiento inesperado o comportamiento del usuario e interacciones del usuario. Así que, tenemos como sin resultados, navegación por teclado, búsqueda responsiva y accesibilidad del lector de pantalla. Debería pertenecer a Q4 porque pertenece a herramientas. Estamos usando herramientas externas como lector de pantalla para validar nuestro producto, nuestra característica, y así sucesivamente. Con este mapeo, tenemos la – ahora tenemos imágenes más claras de cómo nuestras pruebas encajan en cada categoría, cada quaren, y cómo podemos validar nuestra característica mucho mejor y más sistemáticamente. Correcto.

Pero ahora vienen las preguntas. ¿Cómo vamos a integrar la IA en estos quarens de prueba? Porque realmente tienes que sentarte allí y validar cada prueba. Entonces, si la IA generó para ti 200 pruebas, ¿cómo vamos a escalarlas? Correcto. ¿Cómo vamos a asegurarnos de que pueda encajar en cada uno – y si es lo suficientemente importante o debería encajar en este quarens? Bueno, esa es la cuestión. Así que, ahora estamos mirando un nuevo flujo de trabajo de módulo de prueba. Lo primero es, digamos en Q1, es cuando es automático, todo es automático. Entonces, ¿en qué puede ayudar la IA? Bueno, esto es lo más sencillo. Estas son las cosas que viste que la IA siempre generó para cada par. Pueden ayudar absolutamente con pruebas unitarias, pruebas de componentes, cualquier cosa que sea realmente lógica, detalle técnico, limitación técnica, relacionada con la codificación. Así que, puede ser casos límite, ayudando a marcar, configurar el marco de pruebas unitarias, etcétera. Y los humanos, nosotros, como desarrolladores humanos, dirigiremos para entender el comportamiento técnico para que pueda surgir con la prueba en sí. ¿Qué pasa con Q2? Q2 es una especie de híbrido entre automatizado y manual porque también tiene alguna parte de verificación técnica. También es aceptación para la prueba de aceptación de negocios. Entonces, para esto, la IA puede absolutamente ayudarnos a dar algunos ejemplos de lo que considera aceptación para que podamos entender más sobre nuestra característica, qué deberíamos escribir, o qué deberíamos esperar, o cuál es el criterio para que nuestra característica sea considerada aceptada. Y para los humanos, poseemos la intención del negocio porque sabemos lo que queremos hacer mejor. La IA no es quien quiere tener esta característica. Somos nosotros quienes queremos tener esta característica. Sabemos qué intención queremos usar la característica para, y sabemos qué prioridad nos importa. La IA no lo sabe todo. Puede ser P0, o P1, o P3, pero podemos saber que tal vez el P3 en realidad es P1 en algunos casos. Para Q3, generalmente es manual, pero puedo ver que hoy en día la brecha o el límite entre lo manual y Q3 y lo automatizado es un poco borroso. De todos modos, para Q3, es una prueba exploratoria donde hacemos todas estas pruebas de usabilidad, interacciones de usuario. Entonces, para esto, la IA definitivamente puede ayudar con ideas o preguntas sobre la usabilidad, sobre interacciones de usuario para nosotros, que el humano proporcione el juicio y realmente conecte con la realidad y decida qué tipo de escenario queremos probar manualmente. Y por último, para Q4, donde interactuamos con pruebas de construcción con herramientas, bueno, la IA definitivamente puede ayudarnos con el rendimiento, accesibilidad, referencia, cumplimiento, ideas de seguridad, y nosotros mantenemos la definición de cuál es el umbral, qué es el CRCD, dónde entra el CRCD, y dónde está el riesgo. Poseemos todo el riesgo. Poseemos el umbral. Poseemos la puerta CRCD, y por supuesto, la IA también puede ayudarnos a configurar la canalización para la accesibilidad, la referencia para el rendimiento, y así sucesivamente. Así es como deberíamos trabajar con la IA en los flujos de trabajo de prueba en el tiempo actual. Y eso nos lleva a otra cosa, que el flujo de trabajo tradicional donde trabajamos con la IA de una manera que la IA recibe los documentos de características, la IA lo implementa, la IA escribe pruebas, y nuestro trabajo es sentarnos allí y revisar el código y pedirle que se integre con él para mejorarlo y aprobar la prueba. Lo siento, aprobar el PR y seguir adelante.

Bien. Ahora, para eso, cambiamos. Entonces, en lugar de solo cuatro pasos como este en la escritura de pruebas de IA, tenemos un flujo de trabajo diferente, un flujo de trabajo ligeramente más escalable, donde recibimos documentos de características, IA recibe documentos de características. Poseemos el requisito y el contenido. Los documentos de características, por cierto, son la única especie de herramienta, lo que ahora llamamos descripción de requisitos del producto. Aquí es donde lo recibes de los gerentes de producto para saber cómo queremos construir una característica, ¿verdad? Y como cualquier cosa, necesitamos tener claro, conciso y lleno de información. Para que la IA pueda sugerir el escenario en el que realmente pertenece a los cuadrantes y analizar su información y uso, también podemos darle una plantilla de estrategia que contenga toda la información que necesita para procesar el documento de características y mapearlo en el formato correcto que queremos. Y nuestro trabajo es, podemos integrarnos con la IA o también podemos trabajar por nuestra cuenta para revisar la estrategia y decidir qué prioridades para cada una de las pruebas fueron generadas por IA y decidir cuáles son las prioridades para avanzar desde allí, cómo y cuándo implementarlo y qué implementar. Y estos pasos dos y tres están muy cerca uno del otro. Y el paso cuatro, solo entonces la IA comenzará a implementar. La IA nos ayudará a preparar la canalización, a ayudarnos a generar la prueba automatizada, cuándo debería ser automatizada, y ayudarnos a validar nuestro pensamiento y avanzar y proteger nuestro código. Entonces, este es el nuevo flujo de trabajo para trabajar con pruebas, y eso debería ser en lugar de solo generar texto.

Así que con eso, echemos un vistazo a cómo estoy implementado con la búsqueda de mi blog. Bien. Así que en este, le doy el documento de solicitud de características donde tengo el requisito funcional. Como ves aquí, incluso tengo accesibilidad de requisito no funcional con el criterio de aceptación clave y así sucesivamente. Construí una habilidad llamada generar plan de prueba, donde le doy la plantilla de cómo debería verse el plan de prueba, qué se acepta, cuál es la definición de ello, P1, P2 y P3, algo así. Y en código Clojure, le pedí que generara el plan de prueba para esta característica basado en los archivos, los documentos de características. Y aquí vamos. Tenemos el plan de prueba, que todo está dividido en un cuadrante. Y luego también tenemos cada uno de los cuadrantes, tenemos algún escenario. La prueba pertenece al escenario, y cuál es la prioridad de la prueba, y cuál es la prueba clave que deberíamos priorizar primero, según lo que entiende. Y eso es todo. Eso es todo lo que necesitamos para comenzar. A partir de este momento, tenemos un sistema para nuestro flujo de trabajo de pruebas ágiles donde realmente podemos controlar para qué debería implementarse, qué prueba es más importante para nosotros, y qué prueba deberíamos enfocarnos y revisar. Y no perderemos el control donde todavía apareceremos con cien pruebas o muchas líneas de código para pruebas que hacen que sea muy difícil concentrarse.

Y ahora viene la siguiente pregunta. ¿Cómo vamos a escalar desde esta habilidad individual a este flujo de trabajo en equipo? Entonces, en el flujo de trabajo en equipo, lo primero y más importante, necesitamos crear un estándar como todo lo demás. Codificación, estilo, estilo de trabajo, todo tiene un estándar a nivel de equipo. Así que lo que sugeriría es hacer una plantilla de estrategia, de la misma manera que hacemos en nuestro equipo, una plantilla de estrategia para que todos compartan con todos en el equipo donde las personas realmente puedan tomarla e integrarla en su flujo de trabajo y modificarla según su preferencia y trabajar con su propia IA para ejecutar basado en esta plantilla de estrategia, y luego podemos mejorar desde allí.

Y, por supuesto, para cada uno de los Red Bull, también tenemos que tener una regla de pruebas. Tenemos una definición de hecho. Tenemos todo. Es como una guía estándar donde consideramos qué es aceptado, cuál es la alineación estándar, qué es la consistencia para que podamos trabajar como equipo con la IA como miembro del equipo. Y para cualquiera que revise, debe tener una lista de verificación de revisión, unas puertas de CI CD donde protegemos nuestra base de código como de costumbre, incluso ahora más que antes porque tenemos código de IA y no queremos que se descontrole. Y por último, solo piensa en cómo trabajamos con otros humanos. Estamos trabajando con IA. Ahora tenemos otro miembro del equipo llamado IA, como quiera que lo llames. Y luego tenemos que hacer las métricas y los bucles de aprendizaje después de hacer todo esto para saber si estos verificadores no son lo suficientemente buenos, si la plantilla de estrategia puede mejorarse. Y luego podemos ver las métricas y desde allí podemos mejorar nuestro aprendizaje, nuestro proceso, nuestro flujo de trabajo mucho mejor y escalar más. Y este es el sexto paso para asegurarnos de que tenemos un buen flujo de trabajo de modelo de pruebas a nivel de equipo. Y con eso, recuerda que una mejor confianza proviene de la estrategia y no solo de agregar más pruebas. El 100% de cobertura de código no significa que tu código sea 100% seguro.

¿Y cómo nos aseguramos de eso? Tenemos que usar salud para escribir el escenario, no el escenario de prueba primero. Sabiendo que tienes que entenderte a ti mismo, qué características estás construyendo, qué fallos pueden ocurrir, qué fallos quieres detectar primero para asegurarte de que no llegarán al cliente antes de que tú llegues al cliente cuando implementes la característica. Y por último, no todas las pruebas generadas pertenecen a un CI-CD. Déjame ver. Una prueba que puede ser válida pero no pertenecerá a un CI-CD, la convertirá en una prueba no válida y hará que nuestro esfuerzo sea en vano y que nuestro flujo de trabajo no funcione como se esperaba y ya no seamos productivos.

Y con eso, gracias por asistir a mi charla. Espero que esta sesión te haya brindado algunas ideas y no dudes en hacerme cualquier pregunta en mis redes sociales, conéctate conmigo en cualquier caso. Nos encantaría escuchar tus comentarios y saber qué piensas. Gracias.