SOLUCIÓN · QA, PRUEBAS Y MANTENIMIENTO DE SOFTWARE
Pruebas automatizadas de API y regresión antes de cada lanzamiento
Las pruebas automatizadas de API son scripts que envían peticiones a tus endpoints y verifican solos las respuestas —códigos, datos, errores, permisos y reglas de negocio— cada vez que cambia el código, para comprobar que lo que ya funcionaba sigue funcionando. Trabajé en desarrollo y QA en ZazPay, una fintech donde un error en una API afecta pagos reales, y con esa experiencia preparo pruebas que corren en cada cambio.
Lo que pasa hoy
En muchos equipos pequeños, las pruebas se hacen a mano antes de lanzar: alguien abre la aplicación o Postman y revisa los flujos principales. Funciona mientras el sistema es pequeño y hay tiempo. Con prisa, se revisa menos, se asume que «eso no lo tocamos» y los errores aparecen en producción, reportados por un usuario molesto o, peor, sin que nadie los reporte.
Las fallas más costosas suelen estar en los casos borde: datos inválidos, montos con decimales o negativos, fechas en otra zona horaria, permisos de un usuario que no debería ver cierta información, peticiones duplicadas por un doble clic o un reintento de red. Son justo los casos que una revisión manual con prisa omite, porque probar el camino feliz es lo natural.
Cada cambio puede romper algo lejano. Se ajusta el formato de una respuesta para la aplicación móvil y deja de funcionar la integración con un cliente que dependía del formato anterior; se corrige una validación y se rompe un flujo que nadie relacionaba. Sin pruebas de regresión, esos efectos se descubren tarde.
Las pruebas automatizadas no reemplazan el criterio humano ni las pruebas exploratorias, pero sí aseguran que lo que ya funcionaba se compruebe en cada cambio, sin depender de que alguien se acuerde. Y bloquean un despliegue antes de que llegue a producción, que es cuando un error es más barato de corregir.
Cómo lo resolvería
- 01
Identificar los flujos críticos
Empezamos por lo que más duele si falla: pagos y cobros, registro e inicio de sesión, permisos, cálculos de negocio e integraciones con terceros. No hace falta probar todo desde el primer día; hace falta proteger primero lo que cuesta dinero o confianza.
- 02
Pruebas de contrato, negocio y error
Escribo pruebas que verifican códigos de respuesta, estructura de los datos, validaciones y reglas de negocio, tanto en los casos de éxito como en los de error: datos inválidos, falta de permisos, recursos inexistentes y peticiones repetidas. Cada endpoint protegido debe rechazar a quien no tiene acceso.
- 03
Datos y entornos de prueba
Preparo datos de prueba reproducibles y, si hace falta, un entorno aislado con Docker para que las pruebas no toquen datos reales ni dependan del estado de una base compartida. Los servicios externos se simulan cuando no tienen un entorno de pruebas propio.
- 04
Integración continua
Las pruebas corren automáticamente en cada cambio con GitHub Actions u otra herramienta de CI que ya uses, y bloquean el despliegue si algo falla. El equipo se entera en minutos, no cuando llega el reporte de un cliente.
- 05
Reportes claros y estructura para crecer
Cuando una prueba falla, el reporte dice qué se esperaba, qué ocurrió y cómo reproducirlo. Dejo la estructura y la documentación para que tu equipo agregue pruebas nuevas cada vez que corrige un error, y así el mismo error no vuelva.
Ejemplo: endpoint de registro de pagos
- Prueba de un pago válido: responde con éxito y el registro queda guardado con el monto exacto.
- Prueba con monto negativo, cero o en formato incorrecto: responde con error de validación y no guarda nada.
- Prueba de petición duplicada con la misma clave de idempotencia: no se registra dos veces.
- Prueba sin token o con un usuario de otro comercio: el acceso se rechaza.
- Prueba con el servicio del banco simulado en falla: el pago queda pendiente, no confirmado.
- Todas corren en cada cambio y bloquean el despliegue si alguna falla.
Trabajo relacionado
Para profundizar
Preguntas frecuentes
¿Mi proyecto ya debe tener pruebas para empezar?
No. Puedo empezar desde cero con los flujos más críticos y dejar la estructura lista para que tu equipo agregue más pruebas. De hecho, es lo más común: muchos sistemas en producción no tienen ninguna prueba automatizada, y se empieza protegiendo lo que más importa.
¿Qué diferencia hay entre pruebas con Postman y pruebas con código?
Postman con Newman permite convertir colecciones de peticiones en pruebas que corren en CI, y es un buen inicio si tu equipo ya usa Postman. Las pruebas con código (Pytest, Jest) dan más control para preparar datos, simular servicios y probar lógica compleja. Elijo según tu equipo y tu stack; a veces conviven ambas.
¿Qué lenguajes y frameworks cubres?
Trabajo principalmente con APIs en Node.js/NestJS y Python. Las pruebas de API por HTTP funcionan sin importar en qué lenguaje esté hecho el backend, así que también puedo probar APIs hechas en PHP, Java u otros, aunque para corregir el código de esos sistemas te diré con honestidad si soy la persona indicada.
¿Las pruebas automatizadas sustituyen a un tester?
No del todo. Las pruebas automatizadas son muy buenas para comprobar que lo conocido sigue funcionando; las pruebas exploratorias de una persona encuentran lo que nadie había pensado. Lo ideal es combinar ambas: automatizar lo repetitivo para que el tiempo humano se dedique a explorar.
¿Qué define el alcance y el costo?
El número de endpoints críticos, la complejidad de las reglas de negocio, si hay que preparar datos o entornos de prueba, si hay servicios externos que simular y la integración con tu CI actual. Proteger los cinco o diez flujos más importantes es un proyecto acotado y ya cambia mucho el riesgo.
Esta solución forma parte del servicio de qa, pruebas y mantenimiento de software.
¿Lo platicamos?
Si tu caso se parece, cuéntame cómo trabajas hoy. Te digo qué parte conviene automatizar o construir primero.