Plan de pruebas: cómo convertir una idea en casos comprobables
Un plan de pruebas no es un documento burocrático, sino una herramienta de trabajo que ayuda a no olvidar las comprobaciones importantes y acordar previamente los criterios de éxito. La herramienta «Plan de pruebas» acepta una descripción de texto de la idea y la plataforma, y luego genera una lista estructurada de casos: exitosos, fallidos y de frontera. En este artículo veremos cómo preparar adecuadamente los datos de entrada, qué escribir exactamente en el campo «Tu texto o idea» y «Plataforma o aplicación», cómo se ve un ejemplo realista para un formulario de restablecimiento de contraseña y cómo comprobar el resultado obtenido. También discutiremos las limitaciones de la herramienta, para que no espere lo imposible. El escenario de contraseña es ficticio y se presenta solo para ilustrar.
Abrir herramienta: Constructor de plan de pruebas ↗¿Qué es un plan de pruebas y para qué sirve
Un plan de pruebas es una lista de comprobaciones que hay que realizar para asegurarse de que una función funciona correctamente. A diferencia de una lista de verificación, incluye no solo escenarios exitosos, sino también fallidos y condiciones de frontera. Un caso exitoso describe cómo debe comportarse el sistema con datos correctos: por ejemplo, el usuario introduce una contraseña correcta y obtiene acceso. Un caso fallido comprueba la reacción ante un error: contraseña incorrecta, campo vacío, enlace caducado. Los casos de frontera se encuentran en el límite entre lo admitido e inadmisible: longitud mínima de contraseña, máximo de intentos, token más antiguo admitido.
¿Para qué sirve esto? Sin un plan pensado, el probador a menudo solo comprueba los escenarios evidentes, y los errores se ocultan justo en los límites. La herramienta ayuda a generar rápidamente tales casos basándose en una descripción de texto. Obtiene un borrador, que luego ajusta a su sistema. Esto ahorra tiempo en la fase de diseño de pruebas y reduce el riesgo de pasar por alto una comprobación importante.
Es importante entender: la herramienta no ejecuta pruebas ni comprueba código. Solo propone una estructura. Todo lo que genere hay que adaptarlo a los requisitos reales, el entorno y los datos.
Ejemplo de solicitud: «Formulario de restablecimiento de contraseña, que envía un enlace único por correo electrónico. Plataforma: aplicación web». Salida: lista de 10-15 casos con explicaciones.
Cómo preparar los datos de entrada para la herramienta
El primer campo — «Tu texto o idea» — acepta hasta 8000 caracteres. Aquí debe describir la función o proceso que desea probar. Cuanto más específico sea el descripción, más útil será el resultado. Indique qué hace la función, qué entradas tiene, qué salidas, qué limitaciones conocidas hay. Por ejemplo: «El usuario solicita restablecimiento de contraseña, introduce email, recibe un correo con enlace, hace clic en él y establece una nueva contraseña. El enlace funciona 15 minutos y puede usarse una sola vez». Evite frases generales como «hacerlo bien» — no darán puntos de anclaje a la herramienta.
El segundo campo — «Plataforma o aplicación» — hasta 1000 caracteres. Indique el tipo de plataforma: web, aplicación móvil, escritorio, API. Esto afecta la redacción de los casos: por ejemplo, para una aplicación móvil son importantes las interrupciones, y para API — códigos de respuesta. Si no se especifica la plataforma, la herramienta puede proponer comprobaciones demasiado generales.
No es necesario escribir un requisito técnico completo. Bastan 3-5 oraciones con detalles clave. Si tiene requisitos especiales (por ejemplo, «la contraseña debe tener como mínimo 8 caracteres»), inclúyalos — esto ayudará a generar casos de frontera precisos.
Buena entrada: «Restablecimiento de contraseña por email. El usuario introduce email, recibe enlace, hace clic y establece nueva contraseña. El enlace es único, funciona 15 minutos. La contraseña de 8 a 20 caracteres, debe contener letras y números. Plataforma: aplicación web, navegadores Chrome y Firefox».
Estructura del resultado: éxito, fallo, frontera
La herramienta forma tres grupos de casos. Los casos exitosos describen el comportamiento esperado con datos correctos. Por ejemplo: «El usuario introduce email registrado, recibe enlace, hace clic y establece nueva contraseña que cumpla los requisitos, y ve un mensaje de éxito». Estos casos ayudan a asegurar que el escenario principal funciona.
Los casos fallidos comprueban el manejo de errores. Ejemplos: «Introducido email no registrado — el sistema no debe revelar si el usuario existe, pero debe mostrar un mensaje neutral», «Enlace ya usado — al hacer clic se debe llevar a una página con error y opción de solicitar nuevo», «Introducida contraseña más corta de 8 caracteres — el formulario debe mostrar mensaje de error y no guardar contraseña». Estos casos son importantes para la usabilidad y seguridad.
Los casos de frontera se encuentran en los límites de lo admitido. Por ejemplo: «Contraseña exactamente de 8 caracteres — debe aceptarse», «Contraseña exactamente de 20 caracteres — debe aceptarse», «Enlace usado después de 14 minutos 59 segundos — debe funcionar», «Enlace usado después de 15 minutos 1 segundo — debe rechazarse». Estas comprobaciones a menudo descubren errores en la lógica de condiciones.
Fragmento de salida: «Caso de frontera: email con longitud máxima 254 caracteres — debe aceptarse si el dominio existe. Caso fallido: email sin símbolo @ — el formulario debe mostrar error de validación».
Ejemplo realista: restablecimiento de contraseña
Supongamos que está probando un formulario de restablecimiento de contraseña. Introduce la descripción: «El usuario introduce email, pulsa «Restablecer contraseña», recibe un correo con enlace. El enlace lleva a una página donde hay que introducir nueva contraseña dos veces. La contraseña de 8 a 20 caracteres, contiene letras y dígitos. El enlace funciona 15 minutos y es único. Plataforma: aplicación web». La herramienta puede generar un plan así.
Casos exitosos: 1) Email registrado, nueva contraseña correcta — contraseña cambiada, se muestra confirmación. 2) Enlace abierto en mismo navegador — formulario se muestra. 3) Contraseña introducida con letras en mayúsculas y minúsculas — aceptada. Fallidos: 1) Email no registrado — mensaje neutro, no se envió correo. 2) Enlace caducado — página con error y botón para solicitar nuevo. 3) Contraseñas no coinciden — mensaje de error. 4) Contraseña contiene solo letras — error. Frontera: 1) Contraseña exactamente 8 caracteres — aceptada. 2) Contraseña exactamente 20 caracteres — aceptada. 3) Contraseña 7 caracteres — rechazada. 4) Enlace usado después de 14:59 — funciona. 5) Después de 15:01 — no funciona. 6) Reutilización de enlace — rechazada.
Este ejemplo muestra cómo a partir de una descripción corta se obtienen 12-15 comprobaciones concretas. Puede copiar el resultado en un archivo de texto y usarlo como base para casos de prueba.
Solicitud: «Restablecimiento de contraseña por email. Enlace único, 15 minutos. Contraseña 8-20 caracteres, letras y dígitos. Aplicación web». Resultado: lista de 14 casos con explicaciones.
Cómo comprobar y mejorar el resultado
Después de generar, lea cuidadosamente cada caso. Asegúrese de que corresponde a su sistema. La herramienta puede proponer comprobaciones que no tiene su producto, o pasar por alto limitaciones específicas. Por ejemplo, si tiene captcha, agregue casos con ella. Si la contraseña debe contener símbolo especial y no lo mencionó en la descripción, la herramienta no podrá tenerlo en cuenta.
Verifique que los valores de frontera se indican con precisión. Si en la descripción dice «de 8 a 20», los fronterizos serán 8 y 20, así como 7 y 21. Asegúrese de que para cada caso se entiende el resultado esperado. Si la redacción es confusa, reescríbalo con sus palabras.
Complete el plan con casos relacionados con seguridad: por ejemplo, comprueba que el enlace no contiene la contraseña a la vista, que después del restablecimiento se cierran todas las sesiones activas del usuario. La herramienta puede no conocer todos los requisitos de seguridad, por lo que la responsabilidad final recae en usted.
Después de generar, añade un caso: «Después de restablecer la contraseña todas las sesiones activas del usuario deben cerrarse». Este requisito no estaba en la descripción original, pero es importante para la seguridad.
Limitaciones de la herramienta y errores típicos
La herramienta no es un probador y no conoce su base de código. No puede garantizar que todos los casos estén cubiertos. Su salida es un borrador que hay que adaptar. No se deben copiar ciegamente los casos en el seguimiento de errores sin verificar.
La herramienta no admite carga de documentos, no trabaja con imágenes y no genera audio. Es un asistente de texto. No comprueba código, no ejecuta pruebas y no se conecta a su sistema. Todas las limitaciones de longitud de campos se indican en la interfaz: 8000 caracteres para descripción y 1000 para plataforma.
Otro error — descripción demasiado general. Si escribe «probar formulario», el resultado será superficial. Cuantos más detalles dé, más precisos serán los casos. También no espere que la herramienta proponga comprobaciones no estándar que requieran conocimiento del dominio. Sus conocimientos expertos siguen siendo decisivos.
Mala entrada: «Formulario de entrada». Buena entrada: «Formulario de entrada con email y contraseña. Hay bloqueo después de 5 intentos fallidos. Contraseña de 8 caracteres. Plataforma: web».
La herramienta «Plan de pruebas» ayuda rápidamente a crear una lista estructurada de comprobaciones para tareas cotidianas. Ahorra tiempo en la fase de diseño de pruebas, pero no reemplaza el análisis ni al probador. Úsalo como generador de ideas y luego ajusta los casos a tu sistema. Recuerde las limitaciones: formato de texto, ausencia de integraciones y garantías. El escenario de contraseña es un ejemplo ficticio que muestra cómo a partir de una descripción corta se obtiene un plan útil. Comienza con una descripción clara de la función y la plataforma, comprueba el resultado y compleméntalo con las comprobaciones que falten. Este enfoque hará que las pruebas sean más sistemáticas y predecibles.
Abrir herramienta: Constructor de plan de pruebas ↗Las traducciones de la interfaz son asistidas por máquina y pueden necesitar refinamiento.