Plan de pruebas: cómo crear una tarea exacta para la herramienta

¿Por qué es necesario un input preciso

La herramienta no adivina el contexto. Si escribes «probar un formulario», el resultado será general: comprobación de campos, botones, mensajes de error. Pero sin indicar objetivo, plataforma y limitaciones, el plan seguirá siendo superficial. Cuanto más específico sea el input, más significativos serán los casos: la herramienta podrá sugerir comprobaciones relacionadas con riesgos reales, no solo «campo vacío» y «formato incorrecto».

El campo «Tu texto o idea» acepta hasta 8000 caracteres, el campo «Plataforma o aplicación» hasta 1000 caracteres. Esto es suficiente para describir una función, su propósito, escenarios clave y condiciones especiales. No es necesario escribir un requisito técnico completo — basta con una descripción condensada pero exacta.

Un buen input responde a las preguntas: qué probamos, por qué, en qué entorno, qué limitaciones y qué se considera éxito o fracaso. Si falta alguno de estos puntos, el plan puede resultar incompleto.

Malo: «formulario de restablecimiento de contraseña». Bueno: «Formulario web de restablecimiento de contraseña: el usuario ingresa email, recibe un correo con enlace de acción única, lo sigue y establece nuevo contraseña. Plataforma: web, escritorio y navegadores móviles. Limitaciones: el enlace funciona 15 minutos, reenvío no más de una vez por minuto».

Qué indicar en el input: contexto y objetivo

El contexto es el entorno en el que funciona la función. Indica la plataforma (web, aplicación móvil, escritorio), tipo de usuarios, integraciones con servicios externos. Por ejemplo, si el restablecimiento de contraseña envía un correo a través de un servicio externo, esto afecta la comprobación de retrasos y reenvíos.

El objetivo — qué exactamente quieres comprobar. Formelólo como resultado: «asegurarse de que el usuario pueda restablecer la contraseña sin ayuda del soporte», «comprobar que el enlace no funciona después de expirar». El objetivo ayuda a la herramienta a priorizar entre los casos.

No mezcles objetivo y forma de implementación. La herramienta no conoce tu base de código, por lo que frases como «comprobar que la función validateEmail devuelve true» son inútiles. Describe el comportamiento visible para el usuario o el sistema.

Contexto: «Aplicación móvil para pedir taxis, pantalla de confirmación de viaje». Objetivo: «Asegurarse de que el usuario pueda confirmar el viaje, cancelarlo antes de la llegada del conductor y recibir un mensaje correcto en caso de pérdida de red».

Formato y limitaciones: qué agregar

El formato del resultado se puede indicar en palabras: «necesarios bloques separados para casos exitosos, fallos y casos límite», «agregar pasos de reproducción», «indicar resultado esperado para cada caso». La herramienta no tiene configuraciones de salida, pero la indicación textual de formato influye en la estructura de la respuesta.

Las limitaciones son reglas que no se pueden violar. Por ejemplo: «la contraseña debe tener mínimo 8 caracteres, un número y una letra mayúscula», «enlace único», «máximo 5 intentos de entrada de código». Las limitaciones se convierten en casos límite: exactamente 8 caracteres, 7 caracteres, 9 caracteres, ausencia de número, reutilización de enlace.

Si no hay limitaciones, indícalo explícitamente: «no hay limitaciones especiales, salvo la validación estándar de email». De lo contrario, la herramienta puede inventar reglas inexistentes, y el plan contendrá comprobaciones innecesarias.

Limitaciones: «El código de confirmación consta de 6 dígitos, funciona 10 minutos, se permiten 3 intentos de entrada. Después de 3 intentos fallidos, el formulario se bloquea 5 minutos».

Ejemplo de tarea mala y buena

Tarea mala: «Probar el inicio de sesión». No hay plataforma, objetivo, limitaciones. La herramienta puede dar casos generales: login vacío, contraseña incorrecta, inicio de sesión exitoso. Pero no tendrá en cuenta el bloqueo después de varios intentos, recuperación de contraseña, inicio mediante redes sociales o comportamiento al expirar la sesión.

Tarea buena: «Aplicación web, inicio con email y contraseña. Objetivo: comprobar inicio exitoso, errores con datos incorrectos y bloqueo después de 5 intentos fallidos. Limitaciones: contraseña de 8 a 32 caracteres, bloqueo por 15 minutos, sesión expira tras 30 minutos de inactividad. Plataforma: navegadores de escritorio Chrome y Firefox. Se necesitan casos exitosos, fallos y límite con pasos de reproducción».

La diferencia es evidente: en el segundo caso la herramienta recibe suficientes datos para sugerir comprobaciones sobre longitud de contraseña, número de intentos, tiempo de bloqueo y expiración de sesión. Esto no garantiza la completitud, pero hace el plan específico y aplicable.

Buen input para la herramienta: «Formulario web de restablecimiento de contraseña. El usuario ingresa email, recibe un correo con enlace de acción única, lo sigue y establece nuevo contraseña. Plataforma: web, escritorio y navegadores móviles. Limitaciones: el enlace funciona 15 minutos, reenvío no más de una vez por minuto, nueva contraseña de 8 caracteres. Se necesitan casos exitosos, fallos y límite».

Cómo verificar el plan generado

Después de generar, lee el plan y verifica si cubre tres categorías: casos exitosos (la función funciona como se pretendió), fallos (errores, fallos, datos incorrectos) y casos límite (valores en los bordes del permitido). Si alguna categoría falta o se representa con un solo punto, mejora el input y vuelve a generar.

Compara los casos con tus limitaciones. Si en el plan hay una comprobación de 7 caracteres de contraseña, pero la mínima son 8, es un caso límite. Si hay una comprobación de 100 caracteres, pero el máximo son 32, también es un borde. Asegúrate de que tales casos no contradigan tus reglas.

Verifica los pasos de reproducción: deben ser ejecutables sin suposiciones. Si un paso suena como «ingresar datos correctos», es demasiado vago. Un buen plan especifica qué datos exactamente y en qué orden. Recuerda que el modelo puede equivocarse, por lo que la decisión final sobre la inclusión de casos la tomas tú.

Comprobación: en el plan para restablecimiento de contraseña hay el caso «pasar al enlace después de 15 minutos». Es un caso límite que corresponde a la limitación. Si hubiera un caso «enlace funciona 24 horas», contradiría el input.

Limitaciones de la herramienta y errores típicos

La herramienta trabaja solo con texto: no ejecuta pruebas, no se conecta a tu aplicación y no verifica el comportamiento real. El resultado es un borrador de plan que hay adaptar a tu proyecto. No reemplaza la prueba exploratoria y no garantiza la detección de todos los defectos.

Error típico — saturar el input con detalles técnicos que no afectan el comportamiento. Por ejemplo, indicar versión de framework o estructura de base de datos no ayudará a la herramienta a sugerir mejores casos. Mejor enfocarse en escenarios de usuario y reglas.

Otro error — esperar que la herramienta misma invente limitaciones. Si no indicas que el enlace es único, puede sugerir una comprobación de reingreso, pero no sabrá que debe ser un error. Siempre enumera explícitamente las reglas clave.

Recuerda los límites: campo de entrada hasta 8000 caracteres, campo de plataforma hasta 1000 caracteres. Si la descripción es demasiado larga, sírvela a la esencia. La herramienta no guarda historial ni realiza procesamiento por lotes, por lo que cada solicitud hay que formular por separado.

Error: «Probar todo». El resultado será general. Corrección: «Probar el o en una tienda en línea: selección de producto, carrito, ingreso de dirección, pago con tarjeta. Limitaciones: monto mínimo 500 pesos, entrega solo a Rusia. Se necesitan casos para pago exitoso, rechazo del banco y dirección incorrecta».