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

Hola a todos, y sí, estamos viviendo en un período muy emocionante, ¿verdad? Emocionante y también preocupante, lo sé. Pero al pensarlo, nos volvemos cada vez más productivos. Nos volvemos mucho, mucho mejores. Podemos hacer cosas que podríamos haber hecho en semanas que queríamos hacer antes de 2023. Y ahora la IA puede ayudar con casi todo. Incluso puede ayudar a generar pruebas sin que lo pidamos.

Pero ahora surge otra pregunta. ¿Qué será? ¿Cómo vamos a escalarlo? ¿Cómo vamos a asegurarnos de que la IA pueda ir más allá del concepto completo de generar pruebas y asegurarnos de que nuestro producto siga siendo de alta calidad y que la IA pueda seguir ayudándonos al máximo que pueda? Bueno, echemos un vistazo.

Antes de eso, mi nombre es Maya. Soy ingeniera de software en Salesforce. Y me apasiona la accesibilidad de la IA y el frontend. Estoy presentando un podcast llamado Build with Maya donde comparto mis ideas, experimentos y experiencia trabajando con IA y mi trayectoria en alta tecnología, ya sabes, trabajando con visualizables, habilidades blandas, y demás. Así que siéntete libre de suscribirte si quieres aprender más sobre IA y la carrera en alta tecnología. Suficientemente bueno. Así que ahora volvamos a nuestra charla.

Sí, la IA está haciendo que la generación de pruebas sea mucho más fácil, ¿verdad? Ahora mismo, si vas a Qlarko, le pides que implemente un sitio web, implemente características, puede ir instantáneamente a añadir, lanzar algo de 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 tienes, solo quieres cargar tu PR, pero te olvidaste de las pruebas unitarias y ahora necesitas dedicar algo de tiempo para eso. Esto lo hace mucho, mucho más fluido, mucho más fácil. 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 ser, y lo que significa que las malas pruebas ahora son muy baratas de surgir.

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 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, te pasa localmente, ¿verdad? Pero, ¿significa eso que funciona? ¿Significa eso 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, la latencia, el límite de tasa, el token, el presupuesto y el 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 estás hablando de presupuesto, ¿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 que 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 lo que llamo la trampa en la generación de pruebas, porque la prueba generada es inválida, pero el lugar donde la IA la puso es absolutamente en el lugar equivocado. Y porque en el lugar equivocado, en este punto, ya no es válida, porque lo que ejecuta, no puedes controlar si falla por nosotros, o falla por algo que no sabes.

Y eso nos lleva a otra cosa. Más pruebas no significa que tengamos mejor confianza aquí. Puedes tener 100 pruebas en tu base de código. Puedes tener una cobertura del 100%. Cada línea está cubierta. No significa que tu código sea seguro, porque la confianza no viene por la cobertura de código. Viene por saber de qué riesgos estamos tratando de protegernos, saber cómo verificarlo y cuándo debe ejecutarse la verificación. Y por verificaciones, 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 CRCD, o si debemos ponerla en la pequeña prueba.

Así que eso nos lleva a una cosa. Por eso estamos aquí. Y eso significa que cuando hacemos la prueba de generación de IA, de repente no nos da más confianza. Nos da algo que dudas de cualidades ocultas que aún no conocemos. OK, así que echemos un vistazo a un ejemplo. Así que esta es una nueva función para mi publicación de blog, perdón para mi sitio web, donde tengo una página llamada lista de blogs, donde muestro la lista de todos mis artículos. Y quería añadir una búsqueda. OK, así que lo que hace es simplemente mostrarte una lista de unos pocos miles de blogs, blogs disponibles por etiqueta, por descripción, por título. Lo siento. Y también tiene un estado vacío, un estado sin resultados, y así sucesivamente. Y me concentro en asegurarme de que la búsqueda tiene que ser rápida. El resultado tiene que ser en tiempo real y sin resultados estériles. Y tiene que venir con accesibilidad. Y por supuesto, porque mi página crecerá y mi sitio web crecerá, también tiene que ser escalable para que no sea difícil mantenerlo en el futuro.

OK, suena muy simple y directo, ¿verdad? Así que echemos un vistazo a la validación, todas las pruebas potenciales que necesitamos para esta función. Así que tenemos un montón de cosas como la más importante. Necesitamos asegurarnos de que funciona filtrando, publicando, por título o etiqueta. Así que esta es la funcionalidad principal. Y luego tenemos la limpieza cuando la consulta está vacía, y la navegación por teclado, accesibilidad, que está excluida, y así sucesivamente. OK, ahora llegamos 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 consultas de pruebas ágiles, donde dividimos nuestras variables probadas en cuatro cuartos de consultas, el Q1, Q2, Q3, y Q4.

Esto nos permite saber si una prueba débil es importante para cada sección y si la prueba debe ser automatizada o manual. OK, entonces en este caso, tenemos un montón de pruebas, asumiendo que Clarko o Gemini o Codex ya han generado la prueba para ti, lista para usar. Ahora, ¿cómo vas a saber a cuál de estos cuartos pertenecen estas pruebas definidas aquí? Porque cada cuarto importará para si lo pones en CI-CD o lo pones en pruebas de humo manuales o pruebas de interacción humana manuales.

OK, echemos un vistazo. Entonces, completar la publicación por etiqueta de título, entra en pruebas unitarias, porque esa es la implementación central donde realmente validas la lógica técnica. Q2 es la prueba de aceptación. Podemos ponerlo como claro cuando la consulta está vacía. Q3 es cuando probamos todo el comportamiento inesperado o el comportamiento del usuario y las interacciones del usuario. Así que no tenemos resultado, 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 el lector de pantalla para validar nuestro producto, nuestra característica. Y así sucesivamente.

Con este mapeo, ahora tenemos una imagen más clara de cómo nuestras pruebas encajan en cada categoría, cada cuarto, y cómo podemos validar nuestra característica mucho mejor y de manera más sistemática. Correcto. Pero ahora vienen las preguntas. ¿Cómo vamos a integrar la IA en estos cuartos de prueba? Porque realmente tienes que sentarte manualmente y validar cada prueba. Entonces, si la IA generó para ti 200 pruebas, ¿cómo vamos a escalarlas? ¿Cómo vamos a asegurarnos de que pueda encajar en cada una y si es lo suficientemente importante o deberíamos encajar en este cuadrante? Bueno, esa es la cuestión. Así que ahora estamos viendo un nuevo flujo de trabajo del módulo de pruebas. Lo primero es, digamos, en Q1 cuando es automático, todo es casi automático. Entonces, ¿en qué puede ayudar la IA? Bueno, esto es lo más directo. 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 muy realmente lógica, detalle técnico, limitación técnica, relacionado con la codificación.

Entonces, puede ser casos límite, ayudando a marcar, configurar el marco de pruebas unitarias, etcétera y así sucesivamente. Y los humanos, nosotros, como desarrolladores, desarrolladores humanos, lo dirigiremos para entender el comportamiento técnico para que pueda crear la prueba por sí mismo.

¿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. Acepta también pruebas de aceptación de negocio. Entonces, para esto, la IA puede absolutamente ayudarnos a dar algunos ejemplos de lo que se considera aceptado para que podamos entender más sobre nuestra característica, qué deberíamos escribir, 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 qué queremos hacer mejor. La IA no es quien quiere tener esta característica. Nosotros somos quienes queremos tener esta característica. Sabemos para qué queremos usar la característica y sabemos qué prioridad nos importa a nosotros.

La IA no lo sabe todo. Quizás P0 o P1 o P3. Pero podemos saber que tal vez el P3 es en realidad P1 en algún caso. 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 automatizado es un poco borroso. De todos modos, para Q3, es una prueba exploratoria donde hacemos todas estas pruebas, la usabilidad, interacciones de usuario. Entonces, para esto, la IA definitivamente puede ayudar con ideas o preguntas sobre la usabilidad, sobre interacciones de usuario para que nosotros, como humanos, proporcionemos el juicio y realmente conectemos con la realidad y decidamos 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, benchmark, cumplimiento, ideas de seguridad. Y nosotros tenemos toda la definición de cuál es el umbral, qué es el CRCD, dónde el CRCD entra, y dónde está el riesgo. Poseemos todo el riesgo. Poseemos el umbral. Poseemos la puerta de CRCD. Y por supuesto, la IA también puede ayudarnos a configurar el pipeline para accesibilidad, el benchmark para rendimiento, y así sucesivamente. Así es como deberíamos trabajar con la IA en las pruebas de trabajo en el tiempo actual.

Y eso nos lleva a otra cosa, que el flujo de trabajo tradicional donde trabajamos con IA de una manera en 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 hacerlo mejor y aprobar la prueba. Lo siento, aprobar el PR y seguir adelante. Bien. Ahora, para eso, cambiamos. Así que en lugar de solo cuatro pasos como este en la IA escribe pruebas, tenemos un flujo de trabajo diferente, un flujo de trabajo ligeramente más escalable donde recibimos documentos de características.

La IA recibe documentos de características. Poseemos el requisito y el contexto. Los documentos de características, por cierto, son el único tipo de verdad que ahora llamamos descripción de requisitos del producto. Aquí es donde lo recibes de los gerentes de producto para saber cómo vamos a construir una característica, ¿verdad? Y como cualquier cosa, necesitamos que sea claro, conciso y lleno de información. Para que la IA pueda sugerir el escenario y a qué cuadrantes realmente pertenece y analizar la información y usarla, también podemos darle una plantilla de estrategia que contenga toda la información necesaria para que procese el documento de características y lo mapee en el formato correcto que queremos. Y cuando 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 generadas por la IA y decidir cuáles son las prioridades para avanzar desde allí, cómo y cuándo implementarlo, y qué implementar.

Y este paso dos y el paso tres están muy cerca uno del otro. Y el paso cuatro, el último paso, solo entonces la IA comenzará a implementar. La IA nos ayudará a preparar el pipeline, a ayudarnos a generar las pruebas automatizadas cuando deba ser automatizado, y ayudarnos a validar nuestra tarea y avanzar y proteger nuestro código. Entonces, este es el nuevo flujo de trabajo para trabajar con pruebas que debería ser en lugar de solo generar texto.

Con eso, echemos un vistazo a cómo estoy implementando con mi búsqueda de publicaciones de blog. Así que en este, le di el documento de solicitud de características donde tengo el requisito funcional. Como ves aquí, incluso tengo accesibilidad de requisitos no funcionales con el criterio de aceptación clave y así sucesivamente. Construí una habilidad llamada generar plan de pruebas, donde le doy la plantilla de cómo debería verse la plantilla, qué se acepta, cuál es la definición de ella, P1, P2 y P3, algo así. Y en Clarko, pedí generar el plan de pruebas para esta característica basado en los archivos, los documentos de características. Y aquí vamos. Tenemos el plan de pruebas, todo dividido en un cuadrante. Y luego también tenemos cada uno de los cuadrantes, tenemos algunos escenarios. 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 entendemos? 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 ágil de pruebas, donde realmente podemos controlar para qué debería implementarse, qué prueba es más importante para nosotros y qué prueba en la que la IA debería centrarse y que deberíamos revisar. Y no perderemos el control donde todavía tendremos PR con 100 pruebas o muchas líneas de código para pruebas que nos hacen muy difícil concentrarnos. Y ahora viene la siguiente pregunta. ¿Cómo vamos a escalar desde esta habilidad individual a este flujo de trabajo en equipo? Así que en el flujo de trabajo en equipo, primero y ante todo, necesitamos crear un estándar. Todo lo demás, codificación, estilo, estilo de trabajo, todo tiene un estándar a nivel de equipo. Entonces, ¿por qué sugeriría hacer una plantilla de estrategia de la misma manera que lo hacemos en nuestro equipo? Una plantilla de estrategia para que todos la compartan con todos en el equipo donde las personas puedan realmente tomarla e integrarla en el flujo de trabajo y modificarla según su preferencia y trabajar con su propia IA para ejecutar basado en estas plantillas de estrategia de configuración. Y luego podemos mejorar desde allí. Y por supuesto, para cada uno de los red ball, también tenemos que tener una regla de pruebas. Tenemos una definición de hecho.

Lo tenemos todo. Es como una guía estándar donde consideramos qué se acepta, cuál es la alineación estándar, qué consistencias son consistentes para que podamos trabajar en equipo con 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 salga mal de control.

Y por último, piensa como si trabajáramos con otro humano. Estamos trabajando con IA cuando ahora tenemos otro miembro del equipo llamado IA, como sea 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 esta lista de verificación no es lo suficientemente buena, si la plantilla de estrategia se puede mejorar. Y luego podemos ver las métricas. Y a partir de ahí podemos mejorar nuestro aprendizaje, nuestro proceso, nuestro flujo de trabajo de una manera mucho mejor y escalar más. Y este es el sexto paso para asegurarnos de que tenemos un buen modelo de prueba, flujo de trabajo a nivel de equipo.

Y con eso, recuerda, una mejor confianza proviene de la estrategia y no solo de agregar más pruebas. Una cobertura de código del 100% no significa que tu código sea 100% seguro. ¿Y cómo nos aseguramos de eso? Tenemos que usar la salud para escribir el escenario, no el escenario de prueba primero, sabiendo que tienes que entender por ti mismo qué características estás construyendo, qué fallas pueden ser, qué fallas quieres detectar primero para asegurarte de que no llegará al cliente antes de que lo implementes, antes, cuando implementes la característica. Y por último, no todas las pruebas generadas pertenecen a un CICD. Déjame ver, una prueba que puede ser válida, pero no pertenecerá a un CICD, la convertirá en una prueba no válida y hará que nuestro esfuerzo se desperdicie y hará que nuestro flujo de trabajo no funcione como se esperaba y ya no seamos productivos.