Los formularios convierten los datos del usuario en acciones del sistema: registros, pedidos, cambios de perfil o cargas de archivos. Por eso, probar un formulario exige más que introducir combinaciones de caracteres. Recorre el camino desde la entrada hasta los datos guardados y un resultado claro en pantalla.
Una buena validación ayuda a corregir errores y protege la integridad de los datos. Una validación deficiente frustra al usuario y permite solicitudes inválidas: puede rechazar un apellido legítimo en la UI y, a la vez, permitir que la API cree un registro sin el consentimiento obligatorio.
Primero, aclara las reglas
Documenta el contrato de cada campo: obligatoriedad, valores permitidos, intervalo de longitud, formato, normalización, dependencias y momento de validación. Identifica por separado las reglas de negocio, como unicidad, disponibilidad del plan, fechas válidas y restricciones por rol.
La normalización transforma la entrada en una forma acordada, por ejemplo, eliminando espacios al principio y al final. No la inventes en una prueba. Los espacios pueden importar en los nombres, y cambiar las mayúsculas o los caracteres Unicode de una contraseña puede cambiar el secreto. Plantea las reglas ambiguas como dudas sobre los requisitos, en lugar de declarar defectos basados en preferencias personales.
Separa las comprobaciones del cliente y del servidor
La validación del cliente proporciona una respuesta rápida antes de enviar una solicitud. La validación del servidor decide finalmente si la operación está permitida. Los atributos HTML y JavaScript del navegador pueden eludirse; el rechazo en la UI no demuestra que el backend proteja los datos.
Prueba la misma entrada inválida mediante el formulario y mediante una solicitud directa en un entorno de prueba. Exige el rechazo acordado del servidor, que no se cree ningún registro y una gestión correcta del error en la UI. El contrato de la API determina el estado HTTP exacto; no existe un estado universal para todos los formularios.
Selecciona los datos sistemáticamente
Utiliza clases de equivalencia: grupos de entradas que deberían comportarse igual. Para una longitud de 2–50, comprueba la entrada vacía, 1, 2, 50 y 51 caracteres, además de un valor habitual dentro del intervalo. Así obtienes una cobertura de límites que puedes justificar.
- →Números: mínimo, máximo, valores adyacentes, números negativos, fracciones y un separador inválido.
- →Fechas: fechas inexistentes, días bisiestos, límites de períodos y comportamiento requerido según configuración regional y zona horaria.
- →Texto: espacios, saltos de línea, texto cirílico, caracteres Unicode compuestos, pegado y valores largos.
- →Selecciones: ninguna selección, valores no disponibles y cambios en listas dependientes tras modificar el campo principal.
Aclara la unidad de longitud. Los caracteres visibles, puntos de código, unidades UTF-16 y bytes pueden tener recuentos distintos, especialmente con emoji.
Prueba la entrada como interacción
Los usuarios escriben, pegan, usan autocompletado, editan en medio de una cadena y borran selecciones. Una máscara telefónica que solo funciona al escribir secuencialmente puede corromper los valores pegados. Un calendario puede aceptar una fecha desde su selector y tratar de otra forma la entrada manual.
Comprueba también el envío mediante botón y Enter, la navegación con Tab, la conservación de valores tras errores y los teclados móviles apropiados. Los marcadores de posición pueden mostrar ejemplos, pero desaparecen al introducir datos; no sustituyen a las etiquetas persistentes de los campos.
Los errores deben facilitar la recuperación
Los mensajes deben explicar qué ocurrió y cómo corregirlo. Asócialos al campo adecuado, haz que se entiendan sin depender del color y mantenlos visibles el tiempo necesario para leerlos. Si hay varios errores, debe existir un camino claro hacia cada uno.
Comprueba el orden del foco, los nombres accesibles de los campos y el anuncio de errores por el lector de pantalla. Un mensaje general de «datos inválidos» puede resultar insuficiente para una dirección de entrega. En cambio, los mensajes de inicio de sesión que revelan si existe una cuenta pueden incumplir requisitos de seguridad. El contexto importa.
Comprobaciones asíncronas y condiciones de carrera
La disponibilidad de nombres de usuario, los cálculos de precios y las sugerencias de direcciones llegan después de las acciones del usuario. Introduce A, sustitúyelo rápidamente por B y retrasa la respuesta de A. La respuesta antigua no debe sobrescribir el resultado actual.
Durante el envío, muestra el estado acordado. Los clics repetidos, Enter y los reintentos de red no deben crear operaciones de negocio adicionales. Deshabilitar un botón reduce el riesgo, pero verifica la protección definitiva contra duplicados en la operación y en el servidor.
Ejemplo práctico: registro
Supongamos que el contrato exige correo electrónico y una contraseña de 12–64 caracteres, conservando sus espacios. La cuenta se crea cuando el servidor termina correctamente; perder la respuesta no implica que no exista ningún registro.
- 1.Introduce datos válidos y envía. Espera un nuevo registro y un siguiente paso claro, como confirmar el correo.
- 2.Prueba contraseñas de 11, 12, 64 y 65 caracteres mediante UI y API. Espera límites coherentes y ningún registro inválido.
- 3.Usa un correo existente. Espera el rechazo definido por el contrato y que se conserven los demás campos válidos, salvo cuando la política exija borrar secretos.
- 4.Simula un tiempo de espera agotado después del envío y repite. Espera un resultado definido sin una segunda cuenta ni una carga interminable.
- 5.Completa un envío fallido con teclado y lector de pantalla. El error debe poder localizarse y corregirse sin ratón.
Archivos y datos sensibles
En formularios de archivos, comprueba el tamaño y tipo definidos por el contrato, archivos vacíos, transferencias interrumpidas y cargas repetidas. El atributo accept orienta la selección, pero el servidor debe validar por su cuenta el contenido y los límites.
No incluyas contraseñas reales, tokens ni documentos personales en diagnósticos. Demuestra los defectos con datos de prueba preparados y solicitudes sin datos sensibles.
Errores habituales y lecciones
Entre los errores habituales están comprobar solo los campos obligatorios, considerar que una máscara demuestra validez e inspeccionar mensajes sin verificar el estado real de los datos. También son arriesgados los patrones restrictivos arbitrarios para correos o nombres sin un requisito del producto.
Las pruebas sistemáticas de formularios conectan contratos, límites, métodos de entrada, decisiones del servidor y recuperación de errores. Evalúa el recorrido completo del usuario, no el número de cadenas introducidas.
Lecturas adicionales
- →MDN: validación de formularios del lado del cliente
- →W3C WAI: comprobaciones sencillas, formularios y errores
- →OWASP: guía de pruebas de seguridad web
Una regla y una matriz concreta de entradas
Regla de formación: el apodo debe contener 3–12 letras ASCII. Los espacios se rechazan en lugar de eliminarlos silenciosamente; las letras Unicode quedan fuera de este ejercicio deliberadamente limitado. El formulario HTML preparado funciona solo en el cliente y no envía solicitudes. El entorno de prueba de la API valida por separado la misma regla del nombre.
Entrada Esperado
(vacío) Rechazar
ab Rechazar: longitud 2
abc Aceptar: longitud 3
abcdefghijkl Aceptar: longitud 12
abcdefghijklm Rechazar: longitud 13
abc Rechazar: espacio inicial
абв Rechazar: no ASCII según esta reglaPara los valores rechazados, verifica un error visible, aria-invalid=true y el foco en el campo inválido. El error se conecta a la entrada mediante aria-describedby. Para los valores aceptados, exige el estado de éxito y un error vacío. No generalices esta regla exclusivamente ASCII a nombres reales ni a productos internacionales.
Las comprobaciones del cliente mejoran la respuesta al usuario, pero pueden eludirse. Envía JSON inválido directamente a la API local de prueba y exige que también lo rechace. Las comprobaciones del formulario y de la API son dos pruebas distintas; esta demostración no pretende realizar un envío integral del navegador a la API.