The API Testing Checklist I Use for Every Endpoint

Hace tres años, vi cómo una API de producción fallaba espectacularmente a las 2 AM porque nadie probó qué sucede cuando envías un campo de fecha formateado como "32/13/2021". La cascada fue hermosa de la peor manera posible: 47,000 transacciones fallidas, clientes enojados inundando los canales de soporte y un CEO que quería respuestas que no tenía. Esa noche cambió para siempre mi enfoque sobre las pruebas de API.

Soy Sarah Chen, y he sido ingeniera de automatización de QA durante ocho años, los últimos cinco centrados exclusivamente en pruebas de API para plataformas fintech y de salud. He probado todo, desde puntos finales CRUD simples hasta APIs complejas de procesamiento de pagos que manejan millones de dólares diariamente. Lo que he aprendido es esto: la mayoría de las fallas de API no son casos exóticos, son problemas predecibles que una lista de verificación sistemática habría detectado.

La lista de verificación que comparto hoy es la exacta que uso para cada punto final que pruebo. Ha salvado a mi equipo de al menos una docena de incidentes en producción solo en el último año, y es lo suficientemente completa como para que los ingenieros junior puedan seguirla, mientras que es lo suficientemente detallada como para detectar problemas que los desarrolladores senior pasan por alto. Esto no es teoría, es un proceso probado en batalla refinado a través de cientos de implementaciones de API.

Autenticación y Autorización: La Capa Fundacional

Antes de probar cualquier otra cosa, verifico el perímetro de seguridad. Esto no se trata solo de comprobar si la autenticación funciona, se trata de sondear sistemáticamente cada escenario de autenticación y límite de autorización. He visto demasiadas APIs que funcionan perfectamente con credenciales válidas pero fallan catastróficamente o filtran datos cuando las credenciales faltan, están malformadas o pertenecen al usuario equivocado.

Primero, pruebo sin ningún token de autenticación. El punto final debería devolver un estado 401 No Autorizado, no un 500 Error Interno del Servidor, y definitivamente no datos reales. He encontrado APIs de producción que devolvían registros completos de usuarios cuando no se proporcionaba un token de autenticación porque el desarrollador asumió que el middleware de autenticación siempre se ejecutaría. No lo hizo.

A continuación, pruebo con un token expirado. Esto detecta una sorprendente cantidad de problemas porque la lógica de expiración del token a menudo vive en una parte diferente del código que la autenticación inicial. La respuesta debería ser un claro 401 con un mensaje que indique que el token ha expirado, no un genérico "no autorizado" que deja al cliente adivinando si debe refrescar o re-autenticarse.

Luego pruebo con un token malformado: cadenas aleatorias, tokens con caracteres eliminados, tokens de otros sistemas. La API debería manejar estos casos con elegancia sin exponer trazas de pila o detalles internos de errores. Una vez encontré una API que colapsaba todo el servicio cuando se le daba un token que contenía ciertos caracteres Unicode porque la biblioteca de análisis de JWT no manejaba correctamente la codificación.

Las pruebas de autorización son donde las cosas se ponen interesantes. Pruebo con tokens válidos pertenecientes a usuarios que no deberían tener acceso a los recursos. Para un punto final GET /users/123, autenticaré como el usuario 456 y trataré de acceder a los datos del 123. La respuesta debería ser 403 Prohibido, no 404 No Encontrado (que filtra información sobre la existencia del recurso) y definitivamente no 200 con los datos.

También pruebo el control de acceso basado en roles de manera sistemática. Si tu API tiene roles de administrador, gerente y usuario, pruebo cada punto final con cada rol. Mantengo una hoja de cálculo de matriz: las filas son puntos finales, las columnas son roles, las celdas contienen los códigos de estado esperados. Esto detecta errores de permiso antes de que lleguen a producción, donde se convierten en vulnerabilidades de seguridad.

Validación de Solicitudes: Pruebas de Límites de Entrada

La validación de entrada es donde la mayoría de las APIs muestran su verdadera calidad. Una API bien diseñada valida cada campo de entrada a fondo y devuelve mensajes de error claros y prácticos. Una mal diseñada acepta datos basura o se bloquea misteriosamente.

"La mayoría de las fallas de API no son casos exóticos, son problemas predecibles que una lista de verificación sistemática habría detectado."

Empiezo con pruebas de campos requeridos. Para cada campo requerido, envío una solicitud sin él. La API debería devolver 400 Solicitud Incorrecta con un mensaje que identifique claramente qué campo falta. He visto APIs que devuelven "error de validación" sin especificar qué falló, obligando a los desarrolladores a adivinar cuál de los 15 campos causó el problema.

Luego pruebo la validación de tipo de datos. Si un campo espera un entero, envío cadenas, flotantes, booleanos, nulos, arreglos y objetos. Cada uno debería devolver un 400 con un mensaje claro como "la edad debe ser un entero" no "formato de solicitud no válido". Una vez probé una API de comercio electrónico donde enviar una cadena para la cantidad provocó que el sistema creara órdenes para cero artículos, lo que rompió todo el proceso de cumplimiento.

La validación de longitud de cadena es crítica y a menudo pasada por alto. Pruebo con cadenas vacías, caracteres únicos, cadenas en la longitud máxima, cadenas con un carácter más que la máxima, y cadenas absurdamente largas (más de 10,000 caracteres). He colapsado bases de datos de producción enviando cadenas del tamaño de megabytes a campos que no estaban correctamente validados, causando agotamiento de memoria.

Para campos numéricos, pruebo valores de límite sistemáticamente: cero, números negativos, decimales cuando se esperan enteros, números mayores que el valor máximo del entero y valores especiales como Infinito o NaN. Una API de pagos que probé una vez aceptaba montos de pago negativos, lo que habría permitido a los usuarios acreditar sus cuentas arbitrariamente.

La validación de fechas y horas merece atención especial porque es consistentemente problemática. Pruebo con fechas inválidas (30 de febrero, mes 13), varios formatos (ISO 8601, marcas de tiempo Unix, cadenas legibles por humanos), fechas muy pasadas o futuras, y casos límite de zonas horarias. ¿El incidente de las 2 AM que mencioné al principio? Eso fue una falla de validación de fecha.

Para campos enum, pruebo con valores válidos, valores inválidos, variaciones de caso y nulo. Si la API acepta "activa" e "inactiva" como valores de estado, intentaré "ACTIVA", "Activa", "pendiente", cadena vacía y nulo. Cada uno debería ser aceptado (si no es sensible a mayúsculas y minúsculas) o rechazado con un mensaje claro que enumere las opciones válidas.

Validación de Respuestas: Asegurando la Integridad de los Datos

Probar lo que regresa es tan importante como probar lo que entra. He visto APIs que aceptan solicitudes perfectamente pero devuelven datos inconsistentes, incompletos o mal formateados que rompen las aplicaciones cliente.