Validar · Criterio KATA
QA funcional
Un enlace roto se ve. Un formulario que dice «enviado» sin enviar nada no se ve, y hace mucho más daño.
Cómo se ha elaborado esta guía
Qué estás leyendo
Describe cómo verifica KATA que las cosas funcionan. Criterio operativo propio, formado corrigiendo fallos reales.
Qué es criterio propio y qué es estándar externo
- Criterio propio: Los umbrales, el orden y la decisión de qué se considera superado son de KATA.
- Experiencia observada: Lo aprendido en proyectos propios. No se cuantifica ni se presenta como estadística.
- Estándar externo: Cuando se cita una norma o una guía de un tercero, se identifica su fuente oficial con entidad y fecha.
La metodología completa está en el Método KATA.
Respuesta directa
Se comprueba el efecto, no la apariencia. Que un botón exista no demuestra que lleve a algún sitio; que un formulario muestre un mensaje de éxito no demuestra que alguien haya recibido nada.
Nuestro criterio: si no se puede demostrar que entregó, no entrega.
Qué se comprueba, en orden de daño
1 · Formularios que no entregan
El fallo más caro y más silencioso. Se prueba enviando de verdad y comprobando la recepción, no el mensaje en pantalla.
2 · Éxito simulado
Un formulario que muestra confirmación sin haber recibido respuesta del servidor está mintiendo al visitante. En KATA no se publica: o entrega, o se retira.
3 · Enlaces rotos y vacíos
Se rastrea el sitio y se registra el código de respuesta de cada destino. Un
hrefvacío es un botón muerto disfrazado.4 · Destinos equivocados
Más difícil de detectar que uno roto: el enlace funciona, pero lleva a otro sitio. Se revisa que el texto y el destino coincidan.
5 · Estados y errores
Qué ocurre al enviar vacío, con datos inválidos o dos veces seguidas. Casi nadie lo prueba y es donde vive la mitad de los fallos.
El éxito simulado merece párrafo propio
Es habitual encontrar formularios que muestran «gracias, hemos recibido tu mensaje» sin que exista destino, o con el destino roto desde hace meses. Nadie se queja, porque quien envía cree que ha enviado.
Nuestro criterio operativo es tajante: la confirmación debe venir de una respuesta real del servidor, y hasta que exista, el formulario no se publica. Es preferible una dirección de correo visible que un formulario que aparenta funcionar.
Lo que hacemos con lo que no se puede probar todavía
- Se declara no probado, no «correcto».
- Se indica qué haría falta para probarlo: un entorno, un dato, una autorización.
- No se publica una funcionalidad cuyo camino completo nadie ha recorrido.
Dónde este criterio NO aplica
- Aplicaciones con lógica de negocio compleja: esto es la base, no la cobertura de pruebas.
- Sistemas con integraciones de terceros que no se pueden ejercitar en pruebas sin coste o sin efectos reales.
- Proyectos donde el cliente asume el QA funcional con su propio equipo y sus propias herramientas.
Preguntas frecuentes
¿Cuándo se hace este QA?
Antes de publicar y después de publicar. Antes, sobre el entorno de pruebas; después, sobre producción, porque el despliegue puede cambiar rutas, permisos o destinos.
Mi formulario lleva años funcionando. ¿Hace falta probarlo?
Sí, y con más motivo. Los formularios se rompen en silencio: cambia un proveedor de correo, caduca una clave, se llena un buzón. Nadie avisa, porque quien envía cree que ha enviado.
Siguiente decisión
Continúa con una pregunta concreta
Auditoría web integral
Qué podemos abordar contigo y cómo delimitamos el trabajo.
Auditoría web integral →
Ilustraciones conceptuales; no son fotografías de clientes.