Definición:
API Testing es el conjunto de pruebas funcionales y no funcionales enfocadas en interfaces de servicio (REST, GraphQL, SOAP, gRPC, eventos) para verificar contratos, comportamiento, seguridad, rendimiento y confiabilidad sin depender de la UI. Se ejecuta típicamente en niveles componente e integración, y sirve de base para un pipeline de entrega continua fiable.

Objetivos principales:

• Funcionalidad y contrato: Validar que cada operación cumpla el esquema/contrato (OpenAPI/AsyncAPI/WSDL) y reglas de negocio.
• Robustez y errores: Confirmar manejo correcto de códigos/estados, timeouts, reintentos e idempotencia.
• Datos y estado: Verificar consistencia, serialización, versionado y compatibilidad hacia atrás.
• No funcionales: Medir latencia, throughput, límites de tasa, consumo, seguridad (authn/authz, OWASP API), resiliencia (circuit-breaker) y fiabilidad (retries/backoff).
• Observabilidad: Trazabilidad (correlation IDs), logs y métricas para diagnóstico.

Técnicas y enfoques clave:

• Contract testing (p. ej., con OpenAPI/JSON Schema; consumer-driven contracts) para detectar breaking changes temprano.
• Pruebas funcionales: positivas, negativas, límites y combinaciones (data-driven).
• Secuencias/interacciones: workflows stateful (p. ej., crear-consultar-cancelar).
• Virtualización de servicios: mocks/stubs para dependencias no disponibles o inestables.
• Test de compatibilidad y versionado: coexistencia v1/v2, deprecations.
• Seguridad: autenticación/autorización (OAuth2/OIDC), entradas maliciosas, exposición de datos sensibles.
• Rendimiento: carga, estrés, spike, soak, SLAs/SLOs.
• Confiabilidad: fallos de red, latencia variable, resiliencia.

Planificación y control (alineado a CTAL-TM):

• Estrategia basada en riesgos: prioriza endpoints críticos por impacto/uso/amenazas.
• Cobertura: por endpoints/operaciones, códigos de estado, rutas felices y de error, parámetros obligatorios/opcionales, versiones.
• Criterios E/S: contrato “congelado”, datos de prueba listos, ambientes estables; salida basada en tasa de defectos, cobertura de operaciones y resultados de no funcionales.
• Métricas: % de operaciones cubiertas, defectos por tipo (contrato, seguridad, rendimiento), tiempo medio de diagnóstico (MTTD/MTTR), cumplimiento de SLA, estabilidad de builds (flakiness).
• Trazabilidad: requisitos ↔ contratos ↔ casos ↔ resultados ↔ defectos.

3) Aplicación práctica (mini-caso)

Contexto: microservicio de pagos (REST), endpoints: POST /payments, GET /payments/{id}, POST /refunds.

• Riesgos: fraude, pérdidas financieras, brechas PII, indisponibilidad.
• Plan:
  • Contract testing para detectar cambios de esquema en amount, currency, status.
  • Funcional: casos happy path y negativos (monto inválido, moneda no soportada, duplicado idempotente).
  • Seguridad: tokens caducos, scopes insuficientes, rate-limit.
  • Rendimiento: picos en viernes 18:00; metas: P95 < 200 ms, error rate < 0.5%.
  • Resiliencia: simular latencia de banco externo; validar reintentos con backoff.
  • Datos: anonimización en logs; datasets sintéticos representativos.
  • Métricas/KPIs: cobertura 90% operaciones críticas, 0 breaking changes en release, P95 cumplido, defectos sev-alta ≤ umbral.

4) Advertencias y buenas prácticas (en línea con ISTQB TM)

• No sustituyas API tests por UI: la detección temprana y la aislación de fallos ocurre en las interfaces.
• Versiona y gobierna contratos: sin gestión de cambios, los breaking changes impactan a múltiples consumidores.
• Evita flaky tests: controla dependencias con mocks/virtualización y datos deterministas.
• Observabilidad obligatoria: sin trazas y métricas, el MTTR se dispara.
• Incluye seguridad y límites en la cobertura; no te quedes solo en “200 OK”.
• Planifica por riesgo y uso real: prioriza las rutas más críticas en negocio y tráfico.

5) Referencia documental

• Nivel 1 (Obligatorio): El ISTQB CTAL-TM v3.0 no ofrece una definición específica de “API Testing” ni un capítulo dedicado; el tema se aborda de forma transversal dentro de la planificación, control, medición y mejora de las pruebas (criterios, métricas, riesgos, coordinación entre niveles/tipos de prueba).
• Nivel 2 (Complementario): Para la definición y prácticas concretas aquí sintetizadas se apoya en literatura ágil y de calidad continua (p. ej., Agile Testing Condensed y Holistic Testing: Weave Quality into Your Product).

Contenido relacionado

---

Por fuera del contenido de la charla ofrecida por Gonzalo, te comparto algunos conceptos que ayudan a entender más aún este tema tan apasionante, extraído del programa de estudios del ISTQB CT-SEC

1. Integración Temprana y Shift-Left

La prueba de seguridad debe comenzar tan pronto como sea posible en el Ciclo de Vida del Desarrollo de Software (CVDS).

• Prueba a Nivel de Componente: El Ingeniero de Prueba de Seguridad (IPS) debe diseñar pruebas para APIs (Application Programming Interface) individuales (o interfaces similares). Esto incluye realizar pruebas aleatorias (fuzzing) a la API de un componente para encontrar vulnerabilidades.
• Análisis Estático (SAST): Utilizar herramientas de Prueba Estática de Seguridad de las Aplicaciones (PESA) al principio del CVDS, ya que solo requieren el código fuente y son rentables gracias a la automatización. Esto permite identificar código inseguro o configuraciones erróneas en las APIs antes de la ejecución.
• Enfoque DevSecOps: Integrar la seguridad en el pipeline de Integración Continua/Entrega Continua (CI/CD), con la PESA ejecutándose automáticamente cada vez que se produce un cambio en el código.

---

2. Diseño de Pruebas a Nivel de Interacción (Integración)

La prueba de APIs no es solo a nivel unitario, sino también para validar la seguridad de la comunicación.

• Prueba de Integración de Componentes: Las pruebas de seguridad deben centrarse en las APIs integradas para detectar dificultades de seguridad debidas a la falta de controles o al desconocimiento de dichas APIs.
• Validación de Flujos: Probar la seguridad de los flujos integrados configurados (ej. autorizados o no, y el nivel de confidencialidad, integridad y disponibilidad).
• Cobertura de API: La cobertura debe medirse como el Porcentaje de APIs utilizadas/probadas.

---

3. Técnicas de Seguridad Específicas

Las pruebas deben ir más allá de la funcionalidad, enfocándose en mecanismos de seguridad de la API.

• Autenticación y Autorización: Las técnicas de prueba de penetración deben incluir:
  • Probar la debilidad de la política de contraseñas.
  • Probar si los usuarios no autorizados pueden acceder a recursos (escalada de privilegios).
  • Inyección de solicitudes (ej. SQL) para eludir la autenticación.
• Cifrado: Las pruebas deben incluir la conformidad y la vulnerabilidad de las implementaciones del mecanismo de cifrado, comprobando la fortaleza (ej. longitud de las claves) y su correcta implementación, ya que los mecanismos criptográficos débiles son vulnerables.
• Análisis de Composición (SCA): Utilizar herramientas de Análisis de la Composición del Software para verificar las vulnerabilidades del código, incluidas las dependencias y los componentes de código abierto utilizados por la API, comparándolos con bases de datos como CVE.

---

4. Uso Estratégico de Herramientas

La selección de la herramienta adecuada es fundamental para la implementación eficaz del API Testing de seguridad.

• Herramientas Dinámicas (DAST): Las herramientas de Prueba Dinámica de Seguridad de las Aplicaciones (PDSA) deben escanear y simular ataques en tiempo real contra el sistema en ejecución, buscando vulnerabilidades como: validación de entradas, pruebas aleatorias (fuzzing), autenticación y autorización, y criptografía.

La selección de herramientas debe concentrarse en lo que se necesita verificar y evitar la dependencia de un único proveedor, escaneando periódicamente el mercado en busca de nuevas herramientas emergentes.