Courtesy_of_apigee.com

Testeo de APIs (API Testing) – Profundizando las pruebas


En el post Testeo de APIs (API Testing) vimos algunos lineamientos y herramientas para hacer pruebas sobre APIs. En esta oportunidad vamos a extender ese checklist mas allá de las consideraciones funcionales de la API.

API como Servicio

¿Qué tan  fácil es para otra aplicación servirse de la API? A diferencia de las aplicaciones web, de escritorio o aplicaciones móviles, las API no tiene una interfaz gráfica de usuario. Por esto las API son a menudo un servicio solo a ser utilizado por desarrolladores, por lo que la API tiene que ser diseñada de tal manera que se hace más fácil para los desarrolladores usarla. Veamos que puntos debemos contemplar para verificar la API como servicio.

  • Ejemplos ¿Hay algún ejemplo que los desarrolladores puedan mirar? ¿Existen casos de estudio? ¿Estos ejemplos están disponibles en los lenguajes mas utilizados por los desarrolladores? ¿Estos ejemplos funcionan? ¿Hay algo en los ejemplos que puede no funcionar para los desarrolladores?
  • Fácil de aprender ¿Es fácil para los desarrolladores utilizar lo que ya saben acerca de esta API? ¿Tiene sentido el lenguaje utilizado en la API? ¿Las diferentes versiones requieren entender todo otra vez?
  • Documentación ¿Tiene documentación de fácil acceso para los desarrolladores? ¿Está disponible para todas las versiones? ¿Tiene documentación que refleja la funcionalidad? ¿Es posible vincular la documentación con los ejemplos?
  • Facilidad de usar ¿Qué tan fácil es para los desarrolladores utilizar la API? ¿Cómo se construye la respuesta? ¿La información/estructura es consistente a través de todas las respuestas? ¿Es la API consistente con la documentación y los ejemplos?
  • Principle of Least Astonishment ¿Hay efectos secundarios al hacer la llamada a la API? ¿Existen restricciones que los desarrolladores deben tener en cuenta? ¿Hay secuencias mágicas, números mágicos o implementaciones ocultas en la API? ¿Se comportan como se documentan? ¿El uso de la API está en línea con el entendimiento o conocimiento existente del desarrollador? ¿La API sigue las convenciones existentes?
  • Intuición ¿Es posible que nosotros supongamos end points en base a nuestro conocimiento y al patrón existente? ¿Es posible adivinar los parámetros y las cadenas de consulta? ¿Es posible adivinar cuál sería el valor válido o no válido para un parámetro?
  • Consistencia ¿Es esta API consistente con la versión más antigua o el conocimiento existente de los desarrolladores? ¿Utiliza el mismo tipo de validaciones, códigos de respuesta y mensajes de error similares para todas las versiones de la API o es diferente? Dondequiera que sea diferente, ¿es debido a una razón legítima?

Mantenibilidad de la API

Hay dos aspectos de mantenimiento en el mundo de las pruebas API – Qué tan fácil es mantener la API como desarrollador y lo fácil que es para los consumidores a mantener sus aplicaciones construidas sobre esta API.

Vamos a explorar algunos de los factores que me parecen interesantes para las pruebas de capacidad de mantenimiento de APIs para los desarrolladores y consumidores de la misma

  • Diagnóstico ¿Cómo pueden los desarrolladores identificar si hay algún problema con la API? ¿Qué tipo de orientación está disponible para ellos? ¿Hay algún chequeo o estado para los desarrolladores? ¿Esta esto cubierto en la documentación? ¿Qué tan fácil es para los desarrolladores debuggear? ¿Qué tan fácil es para los desarrolladores de la API replicar bugs?
  • Versionado ¿Es posible para los desarrolladores utilizar una versión específica de la API? ¿Cómo  se verán afectados los desarrolladores por las futuras actualizaciones? ¿Los desarrolladores se verían obligados a actualizar sus aplicaciones? ¿Sería posible soportar múltiples versiones concurrentemente? ¿Cómo sabrán los desarrolladores si deben actualizar a una versión determinada de la API? ¿Qué pasa si usted decide no dar soporte a una versión dada?
  • Logging ¿Que queda registrado? ¿Quién será capaz de acceder a este registro? ¿Cómo van a acceder? ¿Cuál es el propósito del registro? ¿Durante cuánto tiempo los registros serán retenidos? ¿Contiene información sensible?
  • Accesibilidad ¿Qué aspectos de las API son visibles para los desarrolladores? ¿La accesibilidad es relajada o estricta? ¿Pueden los desarrolladores acceder a clases o métodos que no se suponen que usen? ¿Pueden los desarrolladores tener acceso directo al sistema, evitando la API?
  • Propósito ¿Cual es el propósito de esta API? ¿Sirve alguna funcionalidad significativa? ¿Esta API necesita ser llamada en secuencia? ¿Quién va a utilizar esta API y en qué circunstancias? ¿Qué van a conseguir llamando a este servicio? ¿Hay otras llamadas a la API que pueden servir al mismo propósito? ¿Hay otras maneras de lograr el mismo propósito?
  • Consumidor ¿Quién va a utilizar esta API? ¿Necesitamos saber si se llama desde móvil, web o tablet? ¿Podría acceder otra máquina o un programa automatizado? ¿Esperamos que los consumidores sigan un protocolo específico? ¿Deberían dar datos en JSON / XML? ¿Importa? ¿Con qué frecuencia se puede llamar? ¿Se espera nuestra respuesta? Si es así, ¿por cuánto tiempo?

Deja tu comentario!!!!


Te gustó el post? Quieres contribuir para que escriba más? Contribute with the Blog

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s