X
BLOG

Revolucione el desarrollo ágil agregando IA a las pruebas de API

Revolucione el desarrollo ágil agregando IA a las pruebas de API Tiempo de leer: 11 minutos
En la última versión de Parasoft SOAtest, brindamos inteligencia artificial a nuestros clientes para ayudarlos a comenzar y escalar con una estrategia de prueba de API efectiva.

Parasoft siempre ha tenido una misión principal: simplificar la automatización de pruebas, y esto es evidente en todo el conjunto de herramientas de Parasoft, desde el análisis estático hasta la simulación del entorno con virtualización de servicios. Pero la idea de lo simple nunca ha estado más presente que en la versión más reciente de SOAtest. En esta versión, eliminamos las complejidades asociadas con las pruebas de API mediante la creación de una solución simple y elegante para ayudar a las organizaciones no solo a comenzar con las pruebas de API, sino también a sentar las bases para una estrategia de prueba de API escalable y mantenible que respalde el desarrollo ágil.

Hacer que las pruebas de API sean "fáciles"

Nuestra directora ejecutiva, Elizabeth Kolawa, tenía una pauta simple mientras discutíamos el desarrollo de esta nueva idea de automatización de pruebas. Ella dijo, "hazlo facil." Esa simple declaración se convirtió en un análisis profundo de los desafíos actuales asociados con las pruebas en la era moderna y condujo a una conclusión clave:

Las herramientas de la industria de pruebas de software no se han centrado en la simplicidad para el mundo ágil.

Agile es principalmente una actividad centrada en el desarrollo. En sus términos más básicos, ágil es una metodología de desarrollo de software en la que las actividades típicas de SDLC que tradicionalmente se extenderían durante la duración de un proyecto se dividen en partes mucho más pequeñas llamadas sprints. Por lo general, un Sprint dura de 2 a 3 semanas y, en un Sprint, las actividades de desarrollo se centran en nuevas funciones y mejoras.

Un sprint se parece a esto:

Un sprint comienza con la fase de diseño y creación, donde la nueva funcionalidad se divide en historias de usuario, se define el alcance y luego el desarrollo comienza a construir algo de inmediato. Al final del sprint, puede haber o no actividades de liberación, pero pase lo que pase, se obtiene retroalimentación y luego comienza otro sprint y el proceso se repite una y otra vez.

Agile permite que las organizaciones se conviertan en un centavo porque los comentarios recopilados durante cada sprint se pueden aplicar al siguiente sprint y ayudar a guiar, dar forma y enfocar el proyecto. Esto funciona muy bien para el desarrollo, pero si observa la parte de prueba del sprint, comienza a complicarse.

Test no tiene acceso para probar las nuevas funciones y mejoras hasta bien entrado el Sprint, y por razones lógicas. El equipo de pruebas debe esperar hasta que el equipo de desarrollo haya creado la funcionalidad completa, por lo que las pruebas siempre están un poco por detrás del desarrollo desde el principio.

Por qué las pruebas no pueden seguir el ritmo del desarrollo

Este problema solo se intensifica a medida que continúa el sprint y los evaluadores confían en las pruebas de IU (interactuando manualmente con la interfaz de usuario). La prueba de la interfaz de usuario es la práctica de prueba más común porque es fácil de usar: es fácil asociar acciones en la interfaz de usuario con la historia del usuario, es fácil de escalar en un gran número de probadores y debido a funcionalidad de grabación y reproducción, es fácil realizar una ronda inicial de automatización.

Pero hay muchos problemas con las pruebas de IU:

  • Hay costos ocultos que se derivan de la ineficiencia de las pruebas de IU. El desafío más fundamental con las pruebas de IU es la cantidad de tiempo que tarda el desarrollo en corregir los defectos cuando se realiza una prueba de IU como reproducción. Por lo general, cuando un evaluador comienza el proceso de descubrimiento de defectos, comienza con pruebas exploratorias (buscando metódicamente la aplicación en busca de un comportamiento inesperado). Cuando encuentran un defecto, necesitan reproducirlo para su desarrollo, lo que implica escribir "pasos para reproducir". Cuando el desarrollador recibe estas instrucciones, necesita encontrar la versión de la aplicación que está usando la prueba, ponerla en marcha y seguir los pasos para ejercitar la interfaz de usuario. Si el defecto se reproduce, deben asociar ese defecto con el código subyacente para determinar la causa raíz. El desarrollo comienza a trabajar en una solución que requiere que desmantelen la aplicación, corrijan el defecto y luego reconstruyan la aplicación antes de que QA pueda comenzar a probar nuevamente. Esto retrasa aún más el proceso de entrega de software y ralentiza todo el proceso.
  • Las pruebas de IU no prueban una aplicación de forma exhaustiva. Las pruebas en la capa de interfaz de usuario validan el flujo de proceso de una aplicación de un extremo a otro, pero no necesariamente prueban toda la amplitud de los componentes internos del sistema. A menudo, cuando se introduce una nueva funcionalidad en una aplicación, es necesario cambiar o actualizar las interfaces existentes. Es posible que no se pueda acceder a algunos de estos componentes cuando se utiliza la nueva funcionalidad, pero presentan riesgos importantes para la organización si no se prueban.
  • Test no tiene acceso al código, por lo que les resulta difícil asignar las acciones que realizan en la interfaz de usuario a la fuente subyacente. Como resultado, las pruebas que se crean no proporcionan una cobertura completa de la API. Muy a menudo se pierden cosas. Cuando llega el momento de ejecutar el ciclo de regresión completo, es posible que se descubran defectos críticos. A menudo, esta detección de defectos de ciclo tardío conduce a retrasos significativos en el lanzamiento y aumenta el costo total de las pruebas.
  • Es difícil mantener la automatización de la interfaz de usuario. Una de las principales razones por las que las pruebas tienen dificultades para seguir el ritmo del desarrollo es porque se dedica demasiado tiempo a la gestión de pruebas de IU dañadas. De hecho, hasta el 80% del tiempo de prueba se dedica a ejecutar manualmente las pruebas de la interfaz de usuario o corregir las pruebas automatizadas de la interfaz de usuario que se han roto como resultado del cambio de aplicación.

Cada uno de los factores anteriores puede provocar retrasos significativos en un sprint, pero cuando se tiene en cuenta cómo funciona un ciclo de proyecto tradicional, se trata de una serie de estos sprints seguidos de un ciclo de endurecimiento o regresión.

En cada paso del camino, las pruebas tienen dificultades para seguir el ritmo del desarrollo, pero debido a las técnicas de prueba que se utilizan tradicionalmente, nunca pueden obtener las pruebas completas y completas que desean.

Se ve algo como esto:

Por lo general, podrán validar las nuevas funciones y capacidades, pero no alcanzan la cobertura de prueba completa.

Esto es frustrante para muchos probadores, pero no es su culpa, es solo la naturaleza de la bestia dadas las capacidades que existen en el mercado de herramientas. La parte peligrosa es que sin estas prácticas de calidad, los defectos se filtran a la producción y erosionan el beneficio percibido obtenido con la agilidad.

¿Qué pasa con las pruebas de API? ¿Puede salvar ágil?

Todos están de acuerdo en que las pruebas de API pueden identificar con mayor precisión la causa raíz de los defectos que las pruebas de IU porque las pruebas de API están más cerca del código, son más fáciles de automatizar y más resistentes a los cambios de aplicación. Además, las pruebas de API ofrecen una mejor forma de reproducción de defectos y comunicación entre el desarrollo y la prueba porque el artefacto de prueba representa la convergencia de esas dos áreas. (En un blog reciente me exploró las pruebas de API, qué es y cómo crear una estrategia integral de prueba de API. Puede leerlo para obtener más información sobre esta práctica de prueba extremadamente efectiva).

Probar en la capa de API es una gran práctica para el desarrollo ágil, específicamente porque permite a los evaluadores validar la funcionalidad dada la línea de tiempo comprimida, y las pruebas de API son altamente reutilizables.

Además, las pruebas de API tienen las siguientes ventajas que simplifican y respaldan las pruebas ágiles:

Menor tiempo de corrección de defectos en comparación con las pruebas de IU

Si una prueba de API falla, puede estar bastante seguro de saber aproximadamente dónde buscar en el código. A los desarrolladores les encanta recibir pruebas de API de los probadores porque los desarrolladores pueden ejecutarlas directamente en su aplicación sin tener que conectar todo el entorno. Y pueden volver a ejecutarlos continuamente a medida que comienzan a corregir el defecto.

El menor tiempo de corrección de defectos significa que, en general, el desarrollo puede corregir un error más rápido cuando se proporciona una prueba de API frente a una prueba de interfaz de usuario. Al considerar los marcos de tiempo involucrados en Agile, esto es exactamente lo que necesitamos. Una vez que se descubre un defecto, se proporciona una prueba de API al desarrollo, que pueden usar para encontrar, corregir y validar el defecto, todo sin tener que reconstruir la aplicación completa, lo que ahorra una enorme cantidad de tiempo. Este es exactamente el tipo de velocidad que necesitamos para agilidad

Las pruebas de API están "listas para la automatización"

Las API representan la comunicación invisible que tiene lugar detrás de escena de una aplicación. La naturaleza invisible de la comunicación ayuda al proceso de automatización. Hay una complejidad significativamente menor en llevar una aplicación al punto en el que puede comenzar a interactuar con ella a nivel de API de lo que sería necesario para poner en marcha una aplicación en su totalidad para poder operar a nivel de interfaz de usuario.

Como resultado, las pruebas de API se pueden ejecutar fácilmente en la automatización en etapas anteriores del SDLC. La mayoría de mis clientes los ejecutan al mismo tiempo que ejecutan sus pruebas unitarias en función de la verificación del código. Estas ejecuciones de prueba de API también se pueden asociar con el sistema de seguimiento de errores de una manera mucho más sencilla, de modo que cuando se resuelvan los defectos, las pruebas de API adjuntas se pueden transferir fácilmente entre el desarrollo y la prueba. Esto reduce significativamente el proceso de transferencia general porque en lugar de presentar el defecto, proporcionar los pasos para reproducir y luego esperar una nueva compilación del desarrollo, los evaluadores pueden recibir notificaciones del sistema de seguimiento de errores de que se ha resuelto un defecto y ver la prueba automatizada. Casos que validan la resolución. Esas pruebas de API pueden integrarse fácilmente en un conjunto de regresión y reutilizarse una y otra vez.

Las pruebas de API son más resistentes a los cambios que las pruebas de IU

Como parte de nuestra investigación, vimos que el 80% del tiempo de desarrollo se dedicó a administrar y actualizar las pruebas de IU que se habían roto como resultado del cambio. El cambio es un gran asesino cuando se trata de ágil, pero debido al aumento de los controles de código y los plazos más cortos introducidos con ágil, el cambio es constante.

Si una organización tiene una dependencia exclusiva de las pruebas de IU, el cambio de aplicación puede ser devastador porque muchos de los casos de prueba que se han creado para validar la funcionalidad crítica simplemente dejan de funcionar. Uno de los principios fundamentales de la agilidad es la capacidad de funcionar rápidamente, lo que significa que las interfaces de usuario y la funcionalidad están cambiando todo el tiempo y la carga de soportar y mantener esas pruebas puede volverse abrumadora para los equipos de prueba. Por otro lado, las pruebas de API ni siquiera ven la interfaz de usuario. Las API también tienen capacidades de control de versiones específicas integradas, que permiten a los evaluadores mantener la estabilidad a medida que la aplicación está experimentando cambios. Además, las API se definen con el contrato de servicio que se pueden aprovechar para actualizar los casos de prueba a medida que la aplicación sufre estos cambios.

Las pruebas de API pueden ahorrar agilidad al brindar a una organización la capacidad de probar fácilmente una aplicación en las primeras etapas de desarrollo, así como proporcionar un mecanismo de comunicación efectivo entre el desarrollo y la prueba que es altamente resistente al cambio. Las organizaciones que adoptan las pruebas de API como una pieza fundamental de su estrategia de pruebas pueden aprovechar la agilidad que brindan para adelantarse realmente a los desafíos de las pruebas.

Entonces, ¿por qué las organizaciones no realizan pruebas de API?

Incluso con todos los beneficios que provienen de las pruebas de API, la industria todavía se centra en las pruebas de IU:

Creemos que esto se debe a que los evaluadores no saben cómo probar la API y / o no saben cómo su aplicación usa las API. No es evidente de inmediato dónde comenzar a probar la API de una aplicación, y comprender cómo ensamblar todas las “piezas del rompecabezas” de una manera significativa requiere un conocimiento de dominio de la aplicación.

Dado que las organizaciones todavía tienden a aprovechar una práctica de prueba centralizada, los evaluadores necesitan un conocimiento profundo de todas las diferentes interfaces de aplicaciones y saber cómo unirlas correctamente. No es una tarea trivial.

Las pruebas de API todavía se consideran tierra de nadie. En una encuesta reciente, preguntamos a una serie de desarrolladores y evaluadores quién es responsable de las pruebas de API en su organización.

  • El 70% de los evaluadores dijeron que Desarrollo de Productos es responsable de las pruebas de API.
    • ¿Por qué? "El equipo de desarrollo creó las API y, a medida que se crearon, también deberían haber creado pruebas de API para validar que funcionan como se describe"
  • 80% de los desarrolladores dijeron que prueba es responsable de las pruebas de API
    • ¿Por qué? “Creamos estas API para que estén orientadas al exterior y las documentamos con un contrato de servicio. El equipo de pruebas debe entrar y validar que las API funcionan como se describe "

Como puede ver, existe cierta confusión en cuanto a quién es el responsable final de las pruebas de API. Nos ha interesado solucionar este problema. Creemos que las pruebas de API son responsabilidad tanto de los desarrolladores como de los probadores, en diferentes formas, pero es esta desconexión la que conduce a una cobertura de prueba de API baja.

Las pruebas a nivel de API requieren habilidades y herramientas especializadas para obtener una cobertura de prueba completa. No es intuitivo. Hay herramientas que existen en el mercado que intentan ayudar a las organizaciones a desarrollar una estrategia de prueba de API, pero la gran mayoría de ellas requiere un alto grado de experiencia técnica para crear pruebas de API completas. Además, los evaluadores aún deben comprender cómo funcionan las API, lo que requiere conocimientos de dominio. Como resultado, las organizaciones tienden a hacer lo mínimo para las pruebas de API, que es lo opuesto a lo que necesitamos para ser ágiles.

Inteligencia artificial para la automatización de pruebas

¿Por qué la IA, por qué ahora? La única forma de resolver este problema de la industria es crear herramientas que eliminen la complejidad de las pruebas de API. Hemos estado trabajando en el espacio de automatización de pruebas de software durante tres décadas y, en ese tiempo, hemos acumulado una gran cantidad de datos para ayudarnos a comprender qué se requiere para crear una prueba API completa. Hoy en día, la inteligencia artificial nos ayuda a aprovechar esa experiencia para simplificar el desafío de las pruebas de API para los probadores de toda la industria.

El generador de pruebas de API inteligente

El nuevo generador de pruebas de API inteligente SOAtest de Parasoft se creó desde cero para ayudar a eliminar la complejidad de las pruebas de API. Smart API Test Generator es un complemento para Chrome que utiliza inteligencia artificial para convertir pruebas de IU manuales en pruebas de API automatizadas, lo que reduce las habilidades técnicas necesarias para adoptar las pruebas de API y ayuda a las organizaciones a crear una estrategia integral de pruebas de API que escala.

Entonces, ¿cómo funciona?

Convierte la actividad de la interfaz de usuario en pruebas de API automatizadas

Smart Generator monitorea el tráfico en segundo plano mientras ejecuta pruebas manuales, analiza ese tráfico y usa inteligencia artificial para construir automáticamente un conjunto significativo de escenarios de prueba API. Al crear esas pruebas de API, Smart Generator primero identifica las llamadas de API, luego descubre patrones y analiza las relaciones entre ellos, para que pueda generar escenarios de prueba de API completos, no solo una serie de pruebas de API.

Reduce la curva de aprendizaje a las pruebas de API

El Generador inteligente proporciona a los probadores un lugar fácil para comenzar a crear pruebas de API, de modo que no tengan que tocar las actividades difíciles asociadas con la creación manual de pruebas de API, es decir, encontrar la definición de servicio correcta, comprender la carga útil de datos o ejecutar una prueba una y otra vez para comprender las relaciones entre solicitudes y respuestas para que pueda comenzar a construir afirmaciones.

En cambio, el Generador inteligente hace todo este trabajo pesado automáticamente, en función de la actividad que observa mientras el evaluador usa la interfaz de usuario. Esto ayuda a los usuarios novatos a comprender mejor las pruebas de API en general porque pueden asignar las actividades que realizaron en la interfaz de usuario a las pruebas de API que se crearon y desarrollar una mayor comprensión de la relación entre la interfaz de usuario y las llamadas de API subyacentes, lo que ayuda impulsar los esfuerzos futuros de pruebas de API.

Ayuda a los usuarios a crear estrategias integrales de prueba de API

Aunque la prueba de API es una de las prácticas de prueba de software más efectivas, muchas organizaciones no han adoptado con éxito la práctica porque requiere habilidades y herramientas especializadas. Para ayudar a las organizaciones a adoptar una práctica integral de prueba de API, Parasoft SOAtest proporciona herramientas visuales que son fáciles de adoptar, lo que permite a los principiantes de prueba de API comenzar a crear escenarios de API poderosos en menos tiempo que con otras herramientas. El generador inteligente cierra la brecha, llevando a los usuarios novatos al mundo de las pruebas de API

Entonces, ¿qué significa esto?

El desarrollo ágil ayuda a las organizaciones a entregar software de calidad al mercado más rápido, pero sin la tecnología necesaria para ayudar a las organizaciones a probar completamente sus aplicaciones a gran velocidad, los riesgos asociados con la entrega acelerada erosionan los beneficios potenciales de Agile. Ahora es el momento de que las organizaciones se vuelvan inteligentes con las pruebas de API.

Una sólida estrategia de prueba de API permitirá a las organizaciones obtener el máximo valor de sus ágiles transformaciones. Para que esto sea una realidad, las herramientas de prueba deberían funcionar para nosotros, y la última versión de Parasoft SOAtest hace precisamente eso. El nuevo Smart API Test Generator de SOAtest reduce la complejidad asociada con las pruebas de API, reduce sus barreras de adopción y ayuda a las organizaciones a implementar una estrategia de prueba manejable, fácil de mantener y escalable. Pruébalo por ti mismo!

Escrito por

Chris Colosimo

Como Gerente de Producto en Parasoft, Chris elabora estrategias para el desarrollo de productos de las soluciones de pruebas funcionales de Parasoft. Su experiencia en la aceleración de SDLC a través de la automatización lo ha llevado a implementaciones empresariales importantes, como Capital One y CareFirst.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft