Mi querido amigo y amiga de la calidad, la semana pasada les hablé sobre las diferencias entre Claude y ChatGPT para el trabajo de QA, y la respuesta de la comunidad fue muy buena. Ahora pensando en como continuar, quise escribir para mostrarte si le estas sacando todo el provecho.
Y eso me lleva exactamente al tema de hoy.
Porque una cosa es tener la herramienta, y otra muy distinta es saber hablarle bien. Y en el trabajo de QA, esa diferencia se nota mucho, especialmente cuando el objetivo es generar casos de prueba que realmente encuentren bugs, y no solo cubrir los escenarios que ya teníamos en mente desde el principio.
El error más común: pedirle a la IA que piense por ti
Cuando alguien usa IA para generar casos de prueba por primera vez, el prompt suele verse así:
“Genera casos de prueba para el módulo de login.”
Y la IA obedece. Produce una lista larga, ordenada, que parece completa. El problema es que esa lista es genérica. Cubre los escenarios obvios que cualquier tester con experiencia ya conoce de memoria.
No conoce tu sistema. No sabe que el campo de contraseña tiene un comportamiento extraño cuando el usuario copia y pega desde ciertos gestores de contraseñas. No sabe que en producción hay un caso especial para los usuarios que migraron desde la versión anterior. No recuerda que ese módulo tuvo tres bugs críticos el mes pasado.
Eso solo lo sabes tú. Y si no se lo cuentas, la IA no puede ayudarte a cubrirlo.
El prompt que cambia todo
Aquí es donde entra algo que aprendí probando estas herramientas en situaciones reales: la calidad del output depende directamente de la calidad del contexto que le das.
No es una regla exclusiva de los testers. Es una verdad que aplica a cualquier profesional que use inteligencia artificial. Y si quieres profundizar en esto desde cero, hay un libro que recomiendo mucho: AI for Absolute Beginners de Anne Hansen. Está en inglés, pero es de las lecturas más accesibles que he encontrado sobre el tema. Explica con mucha claridad cómo funciona esto de hablarle bien a una IA y vale la pena tenerlo como referencia.
La idea central es simple: mientras más contexto útil le das, más útil es la respuesta.
Entonces, en lugar de escribir:
“Genera casos de prueba para el login.”
Prueba algo como esto:
“Eres un QA engineer senior. El módulo de login permite autenticación con correo y contraseña, con autenticación de dos factores opcional. Los usuarios pueden tener roles de administrador, editor o lector. El sistema tiene un límite de tres intentos fallidos antes de bloquear la cuenta por 15 minutos. Genera casos de prueba incluyendo escenarios positivos, negativos y casos borde. Para cada caso, incluye la precondición, los pasos y el resultado esperado.”
La diferencia en la respuesta es inmediata y notable.
Cómo Claude te ayuda a construir ese contexto sin escribir un prompt largo
Aquí hay algo que mencioné la semana pasada y que me parece muy relevante para este tema.
Una de las ventajas que más valoro de Claude es que no espera a que tú construyas el prompt perfecto desde cero. En cambio, hace preguntas con opciones concretas para recopilar el contexto que necesita.
Por ejemplo, si le dices: “Quiero generar casos de prueba para mi proyecto”, Claude puede preguntarte: ¿Qué tipo de funcionalidad vas a probar? ¿Es una API, una interfaz web, un flujo de pagos, algo otro? Tú seleccionas una opción. Luego te pregunta por los roles de usuario. Luego por las restricciones del sistema. Y así va construyendo el contexto, pregunta por pregunta, sin que tengas que redactar un párrafo largo desde el principio.
El resultado es que llegas a un prompt completo de forma conversacional, sin esfuerzo extra, y la IA ya tiene todo lo que necesita para darte algo realmente útil.
Las preguntas que la IA no se hace sola
Hay algo que he aprendido a hacer y que me parece valioso: usar la IA para descubrir los escenarios que yo no estaba considerando.
Después de generar una lista inicial de casos de prueba, le hago preguntas como estas:
- ¿Qué escenarios no estoy cubriendo en esta lista?
- ¿Qué podría fallar si el usuario tiene una conexión inestable durante este proceso?
- ¿Qué ocurre si dos usuarios realizan esta acción al mismo tiempo?
- ¿Qué casos borde relacionados con fechas o zonas horarias debería considerar?
Cada una de esas preguntas puede revelar un ángulo que no había considerado. No porque la IA sea más inteligente que yo, sino porque actúa como un segundo par de ojos que no tiene mis mismos puntos ciegos.
Un flujo de trabajo concreto
Para que esto no quede solo en teoría, te comparto cómo lo aplico en la práctica:
Paso 1: Le doy contexto del sistema Le explico qué hace la funcionalidad, quiénes son los usuarios involucrados, qué restricciones existen y cuáles son las reglas de negocio más importantes. Si uso Claude, dejo que me guíe con preguntas para construir ese contexto juntos.
Paso 2: Le pido una primera lista Genero un borrador inicial de casos de prueba con el formato que usa mi equipo.
Paso 3: La cuestiono Le pregunto qué está faltando, qué riesgos no cubrimos, qué escenarios podría pasar por alto alguien que no conoce bien el negocio.
Paso 4: Reviso y ajusto con mi criterio Aquí es donde entra mi experiencia como tester. La IA no sabe si un caso de prueba es ejecutable en mi entorno. No sabe cuál tiene mayor prioridad según el contexto del sprint. Eso lo decido yo.
Paso 5: Documento el resultado El caso de prueba final es mío. La IA fue una herramienta en el proceso, no el autor del resultado.
Lo que la IA no puede hacer por ti
Quiero ser directo sobre algo, porque creo que es importante.
La IA no entiende el negocio. No tiene intuición sobre qué partes del sistema son más frágiles. No recuerda que ese módulo tuvo tres bugs críticos el mes pasado. No sabe que el cliente final es un usuario mayor que interactúa con el sistema de una forma que no está documentada en ningún requerimiento.
Todo eso vive en ti. En tu experiencia. En el conocimiento que has acumulado trabajando con ese producto y con ese equipo.
La IA es un amplificador. Te ayuda a llegar más lejos desde donde ya estás. Pero si no tienes criterio de QA, la IA no lo va a generar por ti.
Para cerrar
Una de las ideas que más me ha marcado en los últimos años es que nuestra labor como testers no es solo ejecutar pruebas, sino hacer las preguntas correctas antes de que el software llegue al usuario.
La inteligencia artificial puede ayudarnos a hacer más preguntas, desde más ángulos y en menos tiempo. Pero la decisión sobre cuáles de esas preguntas realmente importan sigue siendo nuestra.
Y eso, creo yo, es precisamente lo que hace que nuestro trabajo siga siendo valioso.
Si te interesa entender mejor cómo funcionan estas herramientas de IA y cómo hablarles de forma efectiva, te recomiendo el libro AI for Absolute Beginners de Anne Hansen. Está en inglés, pero es muy accesible y te dará una base sólida para usar la IA con más criterio en tu trabajo diario.
¿Ya probaste usar IA para generar o revisar casos de prueba? ¿Qué ha funcionado y qué no? Te leo en los comentarios. Y déjame saber si este tipo de contenido te está siendo útil para que sigamos explorando estos temas juntos.
