Al igual que los beneficios que se obtiene de los objetos en la programación de código (java, c++, etc), en el diseño de caso de prueba de webservices es fundamental que los casos sean lo suficientemente pequeños para poder identificar de forma rápida y eficiente en donde y cuando se produce el defecto.
Esto no significa que tengas únicamente pruebas muy pequeñas, la ventaja de realizarlo de esta forma es que nos permite familiarizarnos con las características y cualidades de nuestra SUT (System Under Test) mientras que a la vez uno puede construir bloques más grandes a partir de bloques más unitarios. Por ejemplo, usted tiene una API de una Biblioteca, cuenta con varios servicios entre ellos:
● login
● consultarLibrosAdeudados
● realizarAlquiler
Usted puede tener 3 casos de pruebas:
● Autenticación de Usuario
● Consulta de Libros Adeudados
● Alquiler de Libro
El primer caso de prueba contendrá solo el servicio de login, el segundo caso de prueba contendrá el servicio de login y el servicio de consultarLibrosAdeudados y el tercer caso de prueba contendrá el servicio de login y el servicio realizarAlquiler. Analizando los casos de pruebas determinamos que siempre es necesario de un login porque posiblemente la respuesta de este servicio nos devuelve un id de sesión que tendremos que utilizar en los demás servicios expuestos, otra característica que identificamos es que el caso 2 y el caso 3 no contiene los servicios consultarLibrosAdeudados y realizarAlquiler porque son completamente independiente entre ellos y nos permite identificar más rápidamente cual es el servicio que falla en cuestión.
Otra ventaja de tener casos de pruebas pequeños es que nos permite realizar casos de prueba negativos, es decir por cada uno de los casos de prueba que identificamos con anterioridad se abrirá una abanico de casos de prueba que terminan fallando, por ejemplo:
● Autenticación de Usuario
a. Usuario no existe
b. Contraseña Invalida
c. Timeout
● Consulta de Libros Adeudados
a. No posee libros adeudados
b. Alcanzo el máximo de libros adeudados
c. Timeout
● Alquiler de Libro
a. Usuario sin permiso para alquiler de libro
b. Cantidad de alquiler de libros superada
c. Adeuda Libros
Curso Online de Testing de WebServices
El curso online de “Testing de WebServices” tiene como propósito introducirnos en la manera de testear (no sólo probar) WebServices (WS). Un WS es una tecnología que sirve para intercambiar datos entre distintas aplicaciones (que pueden o no, ser del mismo lenguaje) y entre distintas plataformas.
[gdlr_button href=»https://testingbaires.com/cursos-y-novedades-4/testing-manual/testing-de-webservices/» target=»_self» size=»medium» background=»#000000″ color=»#ffffff»]Más info[/gdlr_button]
Dependiendo del proyecto que estemos probando estos casos se pueden transformar en miles de casos de prueba, pero ¿qué pasa si tenemos un bug entre esos miles de defectos? Lo ideal es que estos centenares o miles de defectos están agrupados en suites que permiten distinguir una funcionalidad, prioridad o requerimiento alguno, de manera que cuando esto se encuentra automatizado podamos identificar de manera organizada el defecto y realizar todas las pruebas que estar alrededor de esa funcionalidad para verificar si hay algo más.
Por último ¿qué tan pequeño deberían ser nuestros bloques de casos de prueba? eso va a depender de que es lo que estemos probando, no es lo mismo probar una API con servicios definidos para una biblioteca que los consume a probar una API que consume de otras API externas o internas, en este caso no es necesario probar esas APIs de punta a punta, con las pruebas necesarias que nosotros esperamos que esas APIS nos responda nos es suficiente, sin embargo la dificultad de tener API externa u otras que son consumidas internamente es conseguir la hábil forma de identificar cuando una API falla por causas del código propio a cuando no obtuvo correctamente la respuesta de otra API.
Estas y muchas otras características nos permite conseguir una automatización organizada en donde el tester puede identificar en una regresión de manera unívoca cual es el servicio y en qué situación falla dentro de una historia de usuario que puede contener de varios a decenas de casos de pruebas, fomentando de esta manera la integración continua.
Autor
Leonardo Espindola
LinkedIn
