Piensa Como un Tester: Qué Buscar en el Código Generado por IA

♪ Los desarrolladores escriben código para que las cosas funcionen. Yo escribo pruebas para demostrar que no lo hacen. Tenemos una relación muy complicada.

Hola a todos. Soy Wendy, ingeniera de automatización de QA, profesionalmente suspicaz por más de nueve años. Hoy, los invito a mi mundo. Pero primero, conozcamos a John. John es un gran desarrollador, inteligente, rápido, y ahora aún más rápido con AI.

AI hace todo el trabajo pesado. Él dirige. El mejor año de su vida como desarrollador. ¿Qué podría salir mal? El lunes por la mañana, John recibe un épico. Añadir soporte de código de cupón al flujo de pago. Hay un PRD. Hay un Figma. Alguien lo miró y dijo, está bien, dos puntos de historia, dos días, desarrollo y pruebas incluidas.

Abre su asistente de AI, describe la característica, y el código prácticamente se escribe solo. John dice, esto estará listo para el almuerzo. Ja, ¿quién necesita dos días? Alerta de spoiler, no estuvo listo para el almuerzo. Ahora, antes de continuar, el pago no es solo una característica. Es la razón por la que la empresa existe. Sin pago, no hay dinero, no hay empresa. Yo llamo a estos flujos pan y mantequilla. Las cosas que mantienen las luces encendidas. Las cosas que proteges por encima de todo lo demás. John lo sabe. Todos en el equipo lo saben. Lunes por la tarde, PR enviado. El camino feliz funciona perfectamente. Introduce un código de cupón válido.

El descuento se aplica. Hermoso. Ahora es mi turno. ¿Qué pasa cuando el cupón está expirado? Error. El descuento todavía se aplica. Un usuario real acaba de obtener un descuento en un pedido que no se suponía que debía tener. John lo arregla, lo vuelve a enviar. Esto continuó y continuó, por decir lo menos.

Dos puntos de historia, no. Más como cinco. Y subiendo. El sprint termina el jueves, es miércoles por la noche. No quieres ser el equipo que rompió el proceso de pago. No quieres ser el nombre en el épico que mató el sprint. Lo he visto. Nadie lo planea.

Siempre son las características que parecen las más simples. Los dos puntos de historia, las cosas, ya sabes, que se iban a terminar para el almuerzo. Esto no fue culpa de John. Solo estaba mirando el código a través del único lente que tenía. El lente del desarrollador. El lente del desarrollador hace una pregunta. ¿Esto resuelve el problema? Esa es una gran pregunta.

No debería ser la única. John ve exactamente lo que construyó. Pero el mismo código se ve muy diferente a través de diferentes lentes. Los desarrolladores construyen hacia un objetivo. Los testers miran el mismo camino y preguntan qué grieta se va a romper primero. Cuando AI genera código, construye hacia un objetivo, con confianza, sin vacilación. No se detiene a preguntar, pero ¿y si? Y en el pan y mantequilla, esa confianza sin precaución es muy peligrosa.

Mismo código, dos perspectivas completamente diferentes. Pero aquí está la cosa sobre las perspectivas. No se cancelan entre sí. Se equilibran entre sí. Desarrolladores y testers son una asociación. Somos dos lados de la misma cosa. Tú ves lo que funciona. Yo veo lo que se rompe. Juntos, vemos todo. AI hace que el desarrollo sea más rápido, pero AI no sabe lo que AI no sabe.

Cuando se trata de calidad, ese sigue siendo mi trabajo y quiero compartirlo contigo. Así que cuando tu código llega a mi escritorio, la conversación no es sobre bugs. Se trata de hacer algo bueno, aún mejor. Esta es la asociación que quiero para nosotros. Así que permíteme presentarte el QAI. Cuando John, lo que John necesitaba no era mejor código. Necesitaba la perspectiva de QA, integrada, automática allí, esperando ser activada. El QAI es una perspectiva que los desarrolladores no tienen naturalmente.

El que no pregunta, el que no pregunta, ¿esto funciona? Pero, ¿puede esto romperse de una manera que no podemos ver o controlar? Ya manejas tus suposiciones, pero las suposiciones de QA son diferentes. Esto proviene de años de ver cosas romperse después de que se envían. Casos extremos que usualmente solo los usuarios encuentran. Estados para los que nadie diseñó, fallos que solo aparecen en producción. Esto es lo que el QAI aporta.

Un conjunto completamente diferente de preguntas que tu código nunca había recibido. El QAI se puede desglosar en tres secciones. Una para gerentes de producto o proyecto, una para desarrolladores y una para testers para ayudarles con su proceso de construcción. Nuestro enfoque hoy es ayudarte como desarrollador. Así que vamos a ello.

La fase A se ejecuta, alineación de código. Si lo que construiste no coincide con lo acordado, nada más importa. Arreglas eso primero. Una vez hecho eso, la fase B toma el control. Escanea el código, cada uno buscando una manera completamente diferente en que las cosas podrían salir mal. Un comando lo activa todo, un informe regresa. Cada hallazgo en un solo lugar, organizado, procesable, listo para ser corregido antes de que tu PR incluso se suba. Sin cambiar entre herramientas, sin escaneos separados, sin buscar en diferentes salidas. Tú escribes el código, el QAI hace el resto.

El proceso siempre debe comenzar con la alineación de código. Es la puerta de entrada. Si lo que se construyó no coincide con lo que se acordó, todo lo demás es irrelevante. Tienes tu proceso para escribir tu código, pero ¿realmente construiste lo que acordaste? No solo el PRD, no solo los tickets, no solo el figment, cualquier documento, cualquier hilo, cualquier conversación en Slack donde se tomaron decisiones son todas diferentes fuentes de verdad. La alineación de código toma y compara lo que se acordó contra lo que se construyó y divide la vinculación en dos grupos. Lo que tú como desarrollador puedes arreglar ahora mismo y lo que necesita decisión de producto antes de tocar cualquier código. Si hay una contradicción, te detienes, las resuelves. Entonces y solo entonces las otras tres habilidades se activan.

Así es como se ve en la vida real. Producto olvidó especificar qué sucede cuando alguien aplica un código de cupón del 100%, un pedido gratis, $0 en el checkout. John escribió el código, el cupón se aplica, el pedido se procesa, $0 de cargo. Pero, ¿debería? ¿El sistema aún crea el pedido? ¿El inventario aún se reserva? ¿El cumplimiento aún envía? ¿El procesador de pagos sabe qué hacer con el $0? Nadie decidió nada de eso. El PRD no lo decía. Los tickets no lo decían. La alineación de código lo detectó, lo señaló, se detuvo, involucró al producto y los hizo participar antes de que pudiéramos avanzar más. Una vez que eso se resolvió, pasamos al siguiente.

Los fallos se vuelven peligrosos cuando tu código permanece en silencio. Cada lugar donde tu código falla sin decirle a nadie dentro o fuera no importa de dónde venga. Lo que importa es que nadie lo ve. Bloques de caché vacíos, errores tragados, API que se agota sin manejador, códigos de cupón que devuelven un 500 y tu código simplemente se queda ahí. Y si es código nuevo, trata cada llamada externa, cada operación asíncrona, cada transformación de datos como un posible fallo oculto hasta que se demuestre lo contrario. Sé más agresivo, no menos. Un 503 de nuestro servicio de cupones. Esto sucede raramente, tal vez una vez cada pocos cientos de llamadas, el código tenía un bloque catch, lo atrapó, registró, no mostró nada, simplemente devolvió. El usuario vio una respuesta en blanco, intentó de nuevo, siguió adelante, no compró. Sin dinero, sin alerta, sin ticket, sin idea. Lo encontramos tres meses después en una grabación de sesión, tres meses de personas abandonando silenciosamente el checkout en pan y mantequilla. El bloque catch estaba ahí, el fallo fue manejado, simplemente no era visible. Esa es la diferencia entre manejado y oculto. El código rápido necesita una lente de seguridad.

La IA construye rápido y confía en todo, cada entrada, cada respuesta, cada suposición sobre quién está al otro lado de esa pregunta. Esta habilidad toma esa misma IA y le enseña a ser sospechosa. Dos ángulos, dos preguntas. Primero, el top 10 de OWASP. Cada vulnerabilidad en esa lista existe porque el código confió en algo que debería haber verificado. Estamos ejecutando tu código contra los 10.

La brecha de confianza. Lo que tu frontend asume que el backend valida fue lo que el backend realmente valida. Esas dos cosas rara vez son iguales. Estamos verificando específicamente la brecha entre ellas. La brecha es donde se rompe tu pan y mantequilla. La brecha es donde el descuento del cupón se aplicó gratis, y en este caso, tiene una etiqueta de precio literal. La IA no piensa en ninguna de estas cosas por defecto. Esta habilidad sí lo hace.

No puedes ver fallos de accesibilidad a menos que experimentes un producto de manera diferente. Invisible para casi todos. Sin lector de pantalla. Nunca sabrás que la entrada no tiene etiqueta. Nunca sabrás que el botón no se puede alcanzar con tu teclado. Nunca lo sabrás. Nunca lo sabrás. Tu usuario que depende de la tecnología asistiva, ellos lo saben. Un campo de código invisible en tu pan y mantequilla no es solo un problema menor, es un checkout roto para todo un grupo de tus clientes y ha estado ahí desde el primer commit. La accesibilidad no es algo agradable de tener. Es un requisito y casi siempre es lo último que alguien verifica. Esto te ayudará a encontrar cada etiqueta faltante que tu código deja atrás. Cuatro habilidades, un objetivo. Son habilidades separadas porque son cuatro formas completamente diferentes en que tu código puede fallar. Un requisito faltante no es lo mismo que un error tragado. Un agujero de seguridad no es lo mismo que un lector de pantalla roto.

Cada uno de estos tiene su propio enfoque y preguntas para que salgan a la luz. Si combináramos esto en un solo escaneo, se perdería un montón de ellos. Estas cuatro habilidades son una base. Te ayudarán de inmediato pero el verdadero poder es lo que haces con ellas.

Cada equipo tiene un patrón. Cosas que aparecen con suficiente frecuencia que dejas de sorprenderte y de estar preparado. Déjame darte un ejemplo de mi equipo. En nuestra aplicación, navegar directamente a una URL específica rompe la página. Haz clic en un botón para llegar allí, se abre Fyde. He visto esto tantas veces que tengo una prueba para ello pero para cuando llega a mí, ya es un error.

Ese patrón ha entrado en mi habilidad. Ahora, los desarrolladores lo detectan antes de que siquiera me llegue. Esa sección específica de la empresa está vacía y esperando, llénala con el olfato de tu equipo. Sin ello, la IA es solo autocompletar. Rápida, confiada y completamente indiferente. Correcta o incorrecta, no importa. La efectividad sí. ¿Hace lo que acordaste? ¿Maneja lo que no se suponía que debía manejar? ¿Protege lo que se suponía que debía proteger?

John y yo trabajamos juntos para hacerlo lo más efectivo posible para nuestra base de código. Esto es lo que te permite hacer el QAI. Hazlo efectivo, hazlo tuyo.

Bien, toma dos. Esta vez con el QAI. Mismo lunes, mismo Epic, misma IA ayudándole a construir. Esta vez, después de que John escribe su código, usa el QAI. Corre la alineación del código, dos brechas listas para arreglar, una contradicción.

El PRD y el Figma no están de acuerdo. John no adivina. Lo envía a producto, obtiene una respuesta. La fase A ahora está clara, la fase B se activa. Falla oculta, lente de seguridad, accesibilidad, todo escanea el código. Los hallazgos regresan, John los corrige todos. Esto es incluso antes de que el PR esté hecho. Alerta de spoiler, se va a almorzar. Ahora es mi turno. Un error, no seis, no ocho, uno. John lo corrige, prueba de nuevo, todo en verde. El sprint termina el jueves, es miércoles por la tarde, John está adelantado. Me uno a él para almorzar. Quiero contarte cómo se siente eso desde mi lado.

Cuando tomo un PR que ha pasado por el QAI, ya sé que lo obvio ha sido manejado. Los cupones expirados, los errores silenciosos, las verificaciones de entradas sin etiquetar. Así que en lugar de pasar mi tiempo encontrando lo que debería haber sido detectado antes de que llegara a mí, puedo hacer lo que realmente amo. Encontrar los casos extremos que nadie pensó. Los que requieren experiencia para ver. Los que solo aparecen cuando tres cosas salen mal al mismo tiempo. Esa es la versión del trabajo que amo y quiero hacerlo todos los días. Y podrías darme eso cuando envíes código limpio.

Y podrías darme eso cuando envíes código limpio. Sé lo que algunos de ustedes están pensando. Eso suena como mucho más trabajo. No es más trabajo. Es trabajo en el momento adecuado. Los errores no desaparecieron, siempre estuvieron ahí. En casos extremos, nadie pensó en nombrar.

Lo que cambió es cuándo se encontraron. Los errores encontrados en el desarrollo cuestan horas. Los errores encontrados en QA cuestan días. Los errores encontrados en producción cuestan confianza. Los errores encontrados en producción en pan y mantequilla cuestan clientes. Añade horas, pero ahorra días. Comenzamos con un día de construcción, cuatro días de luchar contra errores, esperando en QA, esperando correcciones, esperando nuevas pruebas.

Y terminamos con un día y medio de construcción, una ronda de QA, y listo para el miércoles por la tarde. Mismo desarrollador, mismo QA, misma AI, mismo epic, diferentes resultados. Los desarrolladores escriben código para hacer que las cosas funcionen. Yo escribo pruebas para demostrar que no lo hacen. Pero hoy, te di algo mejor que pruebas. Te di la perspectiva de QA antes de que el código siquiera llegue a mí. Cuatro habilidades, dos fases, un informe.

AI te hace más rápido, el QAI hace que la velocidad sea segura. John todavía usa AI, todavía rápido, pero ahora envía cosas que funcionan, no solo cosas que parecen funcionar. La brecha entre funciona y funciona correctamente es donde viven los errores, donde mueren los plazos, y donde se rompe la confianza de tus usuarios. En los flujos que más importan, no puedes permitirte descubrirlo de la manera difícil. Nunca, ahora tienes el ojo para verlo. Piensa como un tester. Gracias, soy Wendy. Gracias por ver. Si quieres estar en contacto conmigo, por favor encuéntrame en LinkedIn.