Tu equipo ya ejecuta pruebas negativas. Los correos electrónicos no válidos se rechazan. Los campos obligatorios en blanco lanzan el error correcto. Los valores límite están cubiertos para cada entrada numérica. Y aun así, la bandeja de entrada de soporte se sigue llenando de cosas para las que nadie escribió un caso: dos pedidos idénticos realizados con 400 ms de diferencia por un doble clic, una canalización de analítica que se cae ante un emoji en un nombre visible, una comprobación de unicidad que trata john@acme.com y la misma dirección con un espacio final invisible como dos cuentas diferentes.
Ninguno de esos errores faltaba en el plan de pruebas por accidente. Faltaban porque el plan de pruebas se construyó a partir del documento de requisitos, que describe entradas, no personas. Este artículo trata sobre la segunda categoría: una heurística de cuatro perspectivas para sacar a la luz los casos que tu equipo no está generando hoy. Se sitúa junto a las pruebas funcionales más amplias como la capa que detecta lo que las especificaciones pasan por alto.
Qué son realmente las pruebas negativas (y dónde se detiene la mayoría de los equipos)
Las pruebas negativas son la práctica de introducir entradas no válidas, inesperadas o malformadas en un sistema y verificar que falle de forma controlada. Eso significa que no haya cierres inesperados, ni corrupción silenciosa, ni estado huérfano, y que aparezca un mensaje de error sobre el que el usuario pueda actuar. El concepto lleva dos décadas asentado, así que no lo volveremos a debatir.
El problema es lo que ocurre a continuación en la mayoría de las guías. Enumeran cinco categorías: tipo de dato no válido, valor límite, campo obligatorio en blanco, carácter especial e inyección SQL. Y ahí se detienen. Cualquier responsable de QA que lea este artículo superó esa lista de verificación en su primer mes de trabajo. Los errores que llegan a producción provienen de un lugar completamente distinto. IBM situó el coste medio mundial de una filtración en 4,44 millones de dólares y el ciclo de vida medio de una filtración en 241 días, y una gran parte de los incidentes de ese conjunto de datos se remontan a la gestión de sesiones, condiciones de carrera y brechas en las transiciones de estado que no se parecen en nada a una expresión regular olvidada.
Las pruebas negativas en las pruebas de software son más útiles cuando las tratas como una disciplina de diseño anclada al comportamiento del usuario. Ese cambio de enfoque es lo que te ofrece el resto de este artículo.
Cuatro tipos de usuario que tu plan de pruebas olvida
La heurística es sencilla: antes de dar el visto bueno a una historia de usuario, recórrela pensando en cuatro tipos de usuario que la especificación casi nunca describe. Cada perspectiva es una persona cuyo comportamiento tu camino feliz da por descartado. Cada una abre una categoría de errores que sobrevive a la lista de verificación estándar porque esos errores no tienen que ver con qué se introdujo. Tienen que ver con cómo, cuándo o en qué estado se introdujo.
Para cada perspectiva a continuación, nombramos el patrón de error de producción, damos entre tres y cinco casos concretos y señalamos el punto ciego específico de los requisitos que permitió que el error se ocultara.
Perspectiva 1: el usuario impaciente
El patrón: el usuario hace clic en Pagar, la red se atasca durante 300 ms, el usuario vuelve a hacer clic, el backend recibe dos POST idénticos y se le cobra dos veces al cliente. O el usuario envía un formulario, ve un indicador de carga, se aburre y pulsa actualizar. La pestaña se recarga, el formulario se vuelve a enviar y ahora hay dos tickets de soporte con identificadores secuenciales y contenido idéntico.
Estos son los casos de prueba negativos que vale la pena escribir para esta perspectiva:
- Hacer doble clic en el botón de envío dentro de una ventana de 500 ms y comprobar que existe exactamente un registro en el servidor.
- Actualizar la página en mitad del envío y comprobar que una clave de idempotencia impide la segunda escritura.
- Pulsar el botón de retroceso del navegador después de la pantalla de éxito, volver a enviar y comprobar que no se crea ningún duplicado.
- Abrir el mismo formulario en dos pestañas del navegador, enviar ambos en unos segundos y comprobar que el segundo se rechaza o se fusiona.
- Cortar la red en mitad de una solicitud, restaurarla, reintentar y comprobar que no sobrevive ningún estado parcial en ninguno de los dos lados.
El punto ciego: la especificación dice «el usuario envía el formulario» como si esa acción fuera atómica. El dedo de un usuario no es atómico, y tampoco lo es una conexión móvil en el metro.
Perspectiva 2: el usuario de copiar y pegar
Los usuarios copian de Word, Slack, Google Docs, PDF y los correos de otras personas. Cada una de esas fuentes inyecta caracteres que el usuario no puede ver. Las comillas tipográficas reemplazan a las comillas rectas. Una dirección de correo pegada llega con un espacio final porque la fuente tenía un salto de línea. Los emojis entran en un campo de nombre, se almacenan sin problema y luego rompen la canalización de analítica tres servicios más abajo porque la columna de destino es varchar y el emoji ocupa cuatro bytes.
Ejemplos prácticos de pruebas negativas en esta perspectiva:
- Espacios en blanco al inicio y al final en campos con restricciones de unicidad (correo electrónico, nombre de usuario, código de cupón).
- Uniones de ancho cero, marcas de derecha a izquierda y otros caracteres Unicode invisibles en campos que llegan a la búsqueda o a la coincidencia.
- Comillas tipográficas y rayas cortas pegadas desde Word o Outlook en campos de correo electrónico, contraseña o validados por expresión regular.
- Emojis en campos de nombre, título o descripción que se canalizan a SMS, exportación a PDF, descarga en CSV o un backend heredado.
- Texto copiado de HTML renderizado que arrastra fragmentos ocultos de
<span>o espacios de no separación.
El punto ciego: los requisitos enumeran los caracteres que un usuario tiene permitido escribir. Rara vez enumeran los caracteres que un usuario puede pegar sin darse cuenta. La sanitización de la entrada no es lo mismo que la normalización para cada sistema posterior que recibe el valor.
Perspectiva 3: el usuario viajero en el tiempo
Los relojes mienten. El reloj del cliente está desfasado 40 minutos porque el usuario nunca lo ajustó después de un viaje. El reloj del servidor es la referencia autorizada, pero la caché de la CDN no lo es. Un token de sesión caduca a medianoche UTC mientras el usuario está en mitad del pago. Las transiciones de horario de verano ejecutan las tareas programadas dos veces o ninguna. Un JWT que era válido cuando se cargó la página ha caducado para cuando el usuario hace clic en Guardar.
Casos que vale la pena construir:
- Desfasar el reloj del cliente en 10 minutos o más y comprobar que la validación del token se sigue resolviendo correctamente en el servidor.
- Dejar que una sesión caduque durante un formulario de varios pasos y comprobar que el borrador sobrevive a la reautenticación y devuelve al usuario al mismo paso.
- Enviar un token caducado en un reintento tras un fallo de red y comprobar que el reintento no crea una acción fantasma.
- Probar cualquier lógica programada o basada en el tiempo en las dos transiciones de horario de verano, primavera y otoño, en cada zona horaria que ocupen tus usuarios.
- Lanzar dos escrituras con la misma marca de tiempo pero con distintas cabeceras Last-Modified y comprobar que tu resolución de conflictos es determinista.
El punto ciego: la especificación asume un único reloj. En producción hay al menos tres: el cliente, el servidor de la aplicación y la base de datos, y no dejan de discrepar entre sí.
Perspectiva 4: el usuario confundido con el estado
Un usuario abre una pestaña de pago, se distrae durante dos días, vuelve, hace clic en Completar compra y paga por un producto que se retiró de la publicación hace 36 horas. Un administrador elimina un proyecto mientras un compañero está editándolo; el compañero hace clic en Guardar y recibe un error 500 en lugar de un claro «este proyecto ya no existe». Alguien acepta una invitación a un equipo que ya se había eliminado. Dos administradores aprueban la misma solicitud simultáneamente, y ambas aprobaciones se escriben en la base de datos.
Casos:
- Completar el tercer paso de un asistente después de que el objeto subyacente se eliminara en otra sesión.
- Pagar por un producto que se retiró de la publicación entre «Añadir al carrito» y «Pagar».
- Aceptar una invitación a un equipo después de que el equipo se disolviera.
- Aprobar una solicitud pendiente que otro administrador ya había aprobado 30 segundos antes.
- Enviar un formulario cuyas reglas de validación del lado del servidor cambiaron mientras la pestaña estaba abierta.
El punto ciego: los requisitos describen la máquina de estados feliz del objeto. Casi nunca describen qué ocurre cuando la vista del estado en caché del cliente y el estado real del servidor discrepan. Esa brecha es donde viven las condiciones de carrera, y es un punto de traspaso natural hacia las pruebas exploratorias, que están diseñadas para sondear exactamente estas transiciones ambiguas.
Pruebas negativas vs. pruebas de casos límite: la distinción que de verdad importa
Estas dos se confunden en casi todos los resultados de búsqueda, y la confusión hace que los equipos escriban las pruebas equivocadas. La versión corta: las pruebas negativas verifican el fallo controlado ante entradas no válidas o inesperadas. Las pruebas de casos límite verifican el comportamiento correcto en los límites extremos de una entrada válida.
Qué prueban
La respuesta del sistema ante entradas o acciones que no deberían funcionar
La respuesta del sistema en los límites de lo que sí debería funcionar
Origen del caso
Comportamiento del usuario que la especificación no describió
Los extremos matemáticos o lógicos de la especificación
Punto ciego típico
Personas que usan el producto de formas inesperadas
Entradas correctas con una escala o precisión inusual
Un doble clic que crea pedidos duplicados es un caso negativo. Un usuario con exactamente 65.535 artículos en un carrito es un caso límite. Se solapan en los valores límite, pero el instinto para generarlos es distinto. Las pruebas negativas preguntan: ¿qué no debería funcionar? Las pruebas de casos límite preguntan: ¿cuál es el extremo de lo que sí debería? Si quieres un tratamiento más profundo de la segunda pregunta, consulta el artículo relacionado del grupo, «Edge Case Testing: Where Requirements End and Reality Starts».
Ambas categorías también se quedan cortas ante la seguridad. La inyección SQL, el XSS y la elusión de autenticación aparecen en la bibliografía de las pruebas negativas por tradición, pero siguen una disciplina de modelado de amenazas distinta y corresponden a las pruebas de seguridad.
Cómo aplicar esta heurística en un sprint real
Las perspectivas solo dan resultado si forman parte del proceso de trabajo, no de un documento que nadie abre. Lo que funciona en la práctica:
Añade una pasada negativa de 15 minutos a cada historia de usuario antes de que pase a En curso. Una perspectiva por cada miembro del equipo. Cinco casos cada uno. Eso son veinte casos por historia que, de otro modo, nunca se escribirían. Registra cada error de producción frente a la perspectiva que lo habría detectado. Al cabo de un trimestre, tienes un mapa de calor: la perspectiva con más incidencias es aquella en la que tu plantilla de requisitos es más débil, y puedes actualizar la plantilla en lugar de depender de la memoria individual.
Combina las perspectivas con las cartas de exploración. Mientras que los casos estructurados usan las perspectivas como una lista de verificación, las sesiones exploratorias las usan como estímulos. El artículo relacionado del grupo, «Exploratory Testing Charters That Actually Find Bugs», profundiza en ese patrón.
Mantén la lista versionada por producto. Una app de tecnología financiera necesita una quinta perspectiva para el estado regulatorio (un usuario que actúa bajo condiciones de cumplimiento que la especificación no cubría). Un SaaS multiinquilino necesita una para la confusión de los límites organizativos (un usuario que actúa entre inquilinos que técnicamente puede ver pero que no debería poder modificar). Las cuatro perspectivas son un kit de inicio, no una taxonomía terminada.
El error para el que no escribiste un caso
Todo error de producción que sorprende al equipo tiene la misma forma por debajo. Alguien supuso que el usuario se comportaría como la especificación. La lista de verificación de cinco categorías protege el producto frente a las entradas. La heurística de cuatro perspectivas lo protege frente a los usuarios. No lo detectará todo, y nada lo hace, pero desplaza el descubrimiento de «cliente enfadado un domingo» a «reunión diaria del martes», que es la diferencia entre un incendio y una tarea.
Si quieres un segundo par de ojos que aplique estas perspectivas a tu producto antes de que tus usuarios encuentren las brechas por ti, contáctanos y organizaremos una llamada.
Descubre cómo Sitch, una app de emparejamiento con IA, logró la calidad sólida como una roca que necesitaba para expandirse por EE. UU. y asegurar 6,7 millones de dólares en financiación, reforzando el proceso de incorporación, los flujos de chat y los pagos antes de escalar a todo el país.
