IA en Pruebas de API: Cómo Probar Más Rápido Con ChatGPT

Hola a todos, y gracias por acompañarme hoy. Mi nombre es Olga, y me siento honrada de ser su guía en la intersección entre la inteligencia artificial y las pruebas de API. Así que creo que aprenderán nuevos tips y enfoques hoy.

Hoy, compartiré con ustedes una estrategia para las pruebas de API, paso a paso, y discutiré por qué incorporar la inteligencia artificial, particularmente con chat.dpt, puede elevar su proceso de pruebas a un nuevo nivel. Así que en los ejemplos de hoy, aprenderemos y veremos cómo usar el chat para REST API y GraphQL.

Pero primero, un poco sobre mí. Mi posición actual es gerente de QA en Spleeky. Durante la mayor parte de mi vida, trabajé con automatización, construí procesos desde cero y probé diferentes marcos de pruebas. También, soy una gran fanática de la mejora de vida. Me encanta escalar montañas y así sucesivamente. Por ejemplo, el mes pasado escalé a una altura de 3,000 metros en los Alpes. Pero en el trabajo, me encanta facilitar, no complicar. Así que ahora vamos a adentrarnos en el corazón del asunto.

La API es una de las capas importantes en la aplicación. Es muy fácil entender por qué. Es importante cubrir. Si echamos un vistazo a mis pirámides de conspiración, aquí las pruebas de API se establecen en el nivel de integración, que se supone que es el segundo lote de nuestras pruebas. Entonces, ¿cómo puede el chat ayudarnos en esta etapa? El punto principal es que podemos delegar el trabajo monótono y repetitivo a la IA. Permítanme ilustrar cómo solían ser las cosas en mi empresa. Me uní a Spleeky este verano, y yo era el único QA en el proyecto. El equipo probaba las características por su cuenta, pero no había procesos de QA o QC ni documentación de pruebas, así que tuve que empezar todo desde cero. Teníamos pruebas unitarias, pero también necesitábamos pruebas de extremo a extremo y cubrir los puntos finales con pruebas de API. En ese momento, teníamos 30 puntos finales en REST y 20 en GraphQL. Cuando empiezas desde cero, generalmente estás presionado por el tiempo. Y estaba buscando una herramienta popular y conveniente para impulsar mi trabajo. El chat estaba en boca de todos, así que decidí experimentar y probarlo para averiguar si valía la pena o no. Y el chat tiene dos versiones, 3.5 y 4, pero también lanzaron la versión 4.2.0, pero hoy nos centraremos solo en las dos primeras. Por supuesto, todas estas tienen sus pros y contras. La versión 3.5 es gratuita, pero solo toma texto. Las noticias cometen errores.

Y la última actualización fue en enero de 2022, lo que significa que no tiene acceso a la información más reciente. Y en cuanto a la versión 4.0, para desbloquear las características premium, necesitas pagar por ellas. Esa es la mala noticia.

Pero no solo toma texto, sino otros formatos de archivos como PDFs, tablas, imágenes, audio, videos y archivos. Además, puede generar imágenes por sí mismo. Y en cuanto a la actualización del conocimiento, la última vez fue en abril de 2023. Eso significa que esta versión es más relevante.

Ahora voy a entrar en la estrategia de testing. La estrategia de testing consta de dos pasos. En primer lugar, necesitamos verificar las especificaciones. Siempre necesitamos empezar desde este paso. Esto también es importante para asegurarnos de que los endpoints están nombrados correctamente, que los recursos y sus tipos representan el modelo correcto y que no hay falta de funcionalidad duplicada.

Luego viene el testing en sí. En cuanto al testing, se puede desglosar en varios pasos. En primer lugar, es necesario comprobar la actualidad del código de estado. Cuando envías, por ejemplo, una solicitud de post y creas un nuevo ítem, deberías obtener un código de estado 201. Si enviamos una solicitud que está prohibida, esperamos un código de estado 403. Luego verifica la carga útil. Comprueba que los nombres, tipos y campos del JSON del cuerpo son correctos. No olvides las solicitudes con una respuesta de error. La tercera cosa que necesitas es comprobar las cabeceras de la respuesta. Las cabeceras son críticas porque afectan la seguridad y el rendimiento. El último paso que necesitas hacer es comprobar el rendimiento básico. En caso de que la operación haya sido un éxito pero haya tardado mucho tiempo, la prueba aún se considera fallida.

Ahora, es hora de la práctica. Antes de empezar, por favor ten en cuenta que no es seguro compartir datos sensibles. Siempre bórralos. Empecemos con la primera etapa, la documentación. Así que crea un prompt y pídele al chat que analice la documentación. Para este propósito, podemos usar varios pasos.

Luego ve a nuestra documentation. En este caso particular, usaré Swagger. Aquí también podemos actuar de dos maneras. Puedes tomar una instantánea de ella o puedes copiar y pegar el texto. Honestamente, prefiero más la segunda opción. Ahora obtenemos el resultado final. No entres en detalles. Solo mira las diapositivas. Así que representa el uso del lenguaje. Representa la evaluación del contenido, características o aspectos y otras cosas.

Así que lo que haremos a continuación es crear casos de prueba y automatizarlos. No es una sorpresa que necesitemos un prompt para estos dos. Y en unos segundos, obtenemos 13 comprobaciones. Por supuesto, es más una lista de verificación que los casos de prueba normales. Aún así, basándonos en ellos, podemos hacer escenarios de prueba completos. Así que analizamos la documentation, generamos casos de prueba. ¿Qué sigue? Es hora de la automation. Y enviamos el nuevo prompt. Y ahora de nuevo, en solo unos segundos, genera la prueba con afirmaciones. Y si lo deseas, también puede generar una descripción de la prueba al final. Así que aquí, puedes ver un ejemplo de un escenario positivo con solicitud de data, y está escrito por Cypress. Así que también puede ser lo mismo para GraphQL, pero unas pocas palabras sobre ello.

GraphQL es un lenguaje de consulta. Fue introducido por Facebook y diseñado para facilitar la gestión de los endpoints para APIs basadas en REST. Así que ahora, conoces la mejor fórmula para una prueba bien generada. Es un prompt correcto y data válida. Y en Cypress, no hay diferencia entre REST y GraphQL. Cuando creas pruebas, lo haces solo para la interfaz de usuario o para la API. Y aquí está nuestro resultado final.

Y por supuesto, el chat no es el único recurso existente. Es solo uno popular. Y puedes elegir cualquiera de estas herramientas según tu preferencia. Por ejemplo, en los últimos días, CodePilot ganó popularidad, y la gran ventaja de esto es que puedes usar CodePilot directamente en tu IDE. Y todos estos ejemplos son impresionantes.

Y quizás tengas una pregunta razonable. ¿Realmente puedo facilitar tanto mi trabajo? Y la respuesta es sí y no. Y aunque todas estas herramientas son muy útiles y podrían hacer nuestra rutina diaria de trabajo fácil, siempre necesitarás hacer una doble comprobación. Y al principio, siempre necesitas revisarte a ti mismo. No puedes usar data sensible en absoluto. Y además, los casos de prueba no están completos. Y desde mi perspectiva, no parecen profesionales. Y no tiene todas las comprobaciones. Y todavía necesitamos mejorar las pruebas y añadir nuevas. Y el código a veces tiene errores. Y como ejemplo, si pedimos generar una prueba que compruebe el estado de respuesta exitoso, el chat lo interpreta, literalmente, así que no es correcto. Otro ejemplo es la función de aleatorizar el nombre. Desde el primer punto de vista, parece bien. Pero si insertamos este fragmento de código en IDE, descubriremos que la variable no está inicializada. Así que todas estas actividades todavía necesitan humanos. Y creo que puede ser un buen asistente, pero no un buen probador. Para el big data, lleva más tiempo del que esperamos. Y como ves, también comete errores.

Y por ejemplo, si quieres realizar una tarea compleja, necesitas dividirla y así sucesivamente. Espero que esto ayude. Así que gracias por su atención. Y no duden en hacerme preguntas si tienen alguna.

Creo que fue una muy buena introducción sobre cómo usar la IA para apoyar el trabajo que hacemos. Hay una pregunta que ha llegado hasta ahora relacionada con tu charla. Y bueno, hay un par. Mencionaste justo al principio, GPT 3.5.4 y 4.0 Turbo. ¿Has logrado probar Turbo todavía? ¿Has encontrado que se desempeña mejor en estas tareas, tal vez? Honestamente, no, todavía no. Pero pruebo la versión 4.0. Pago por ello. Así que invierto en mi trabajo. Y para mí, es más... Por supuesto, es más útil porque toma, como noté, y como dije, toma diferentes formatos de archivo, ya que podría ayudarte mucho. Pero aún así, si apenas comienzas tu trabajo y si apenas estás tratando de familiarizarte con este tipo de herramienta, es necesario probar la versión gratuita. Y tal vez puedes probar diferentes herramientas, no exactamente en GPT.

Interesante. Tenemos algunas preguntas. Por favor, continúen enviándolas. Una pregunta que tengo, uno de mis escepticismos personales de la IA para los desarrolladores en cualquier área de nuestro trabajo es que una cosa que pudiste hacer fue validar que una respuesta era, ya sabes, que algo que devolvía era incorrecto. Y creo que tu capacidad para hacer eso viene con la experiencia de ser un desarrollador. Al mismo tiempo, hay una gran cantidad de desarrolladores junior menos experimentados, personas que se están introduciendo en el campo, que tienen expectativas poco realistas de lo que estas herramientas harán por ellos. Tomarán algo literalmente y dirán, sí, parece correcto, probemos eso. ¿Tienes algún consejo, técnicas, herramientas para que estas personas sean más vigilantes con la salida de la IA? Creo que estas personas necesitan probadores. Porque como noté y como mencioné, puedes usar la IA, pero todavía necesitas conocimientos para entender y estar seguro de lo que realmente estás probando ahora. Sí. Creo que esto seguirá siendo un desafío para... También, los mantenedores de proyectos, por otro lado, las personas piensan que han escrito código válido, pero han tomado código alucinógeno. Genial, tenemos más preguntas. Durante tu charla, mencionaste que el uso de herramientas como ChatGPT con la ayuda de cosas como Prompt Perfect reduce tu tiempo total, pero parece que hay mucho más tiempo de configuración, tal vez, para hacerlo funcionar.

¿Crees que ese equilibrio es correcto? Aquí dice, como, ¿es realmente útil? Pero ¿en qué punto tiene sentido ese equilibrio? Esa es una muy buena pregunta.

Sí, por supuesto, necesitas trabajo extra para hacer tu trabajo principal. Pero solo imagina que necesitas generar 100 pruebas en un solo día, y puedes intentarlo con IA. Puedes intentarlo con, por ejemplo, chat. Porque si lo haces manualmente, aún necesitarás más tiempo que simplemente configurarlo en IA y usarlo para este propósito. Sí.

Me pregunto si también hay algo interesante allí sobre lo que tenemos, las expectativas de las empresas de la productivity del desarrollador se vuelven demasiado grandes con el estado de las herramientas hoy en día. Y parece que podría ser el caso. Si estuvieras seguro del resultado, entonces sí, mucha ganancia de productivity. Pero basándote en tu charla, no lo estás. Y ciertamente yo no lo estoy. Y no creo que muchos de nosotros deberíamos estar interesados, genial.

¿Alguna vez has intentado este proceso para hacer unit testing para React components? Y si lo hiciste, o componentes en general, ¿cómo te fue? No, no tuve esa experiencia, pero creo que será el próximo desafío en mi trabajo.

Vale. Vale. Entonces, hay un par de preguntas similares aquí. La primera que vemos aquí y la tercera que vemos aquí. Voy a resaltar la tercera porque está un poco más desarrollada. No, se movió bajo mi pulgar. Es esta aquí. El éxito de la IA en la generación de pruebas o en la interpretación de código o en la escritura de cualquier código es bastante... Parece que depende mucho de que la especificación inicial documentation sea buena o casi perfecta o completamente perfecta. ¿Pueden los documentos de especificación completos o imperfectos llevar a la creación de pruebas defectuosas? Puedo decir que la documentation incompleta o incorrecta podría ser el problema en nuestro desarrollo de productos. Y ese es también el problema con la IA. Por ejemplo, antes de analizarlo a través de estas herramientas, necesitas hacer una búsqueda humana antes de eso. Así que necesitas analizar esta documentation en sí misma porque no puedes delegar totalmente este trabajo a la IA. Solo un ejemplo. Vale. Analizará, pero no estarás en el contexto más tarde. Por eso creo que todavía necesitamos estar involucrados en este proceso.

Sí. Estoy vigilante. Me he preguntado en el pasado cómo, ya sabes, están empezando a surgir estas interfaces de estilo chat GPT en la documentation de los desarrolladores. Siempre me preocupo por lo que sucede si esa documentation base no se ha mantenido adecuadamente. Como usuario, no necesariamente sé de inmediato que esta no es una documentación muy bien mantenida. Y luego obtenemos resultados que son incorrectos. Y eso es un gran desafío.

Entonces, más allá de escribir pruebas, supongo, ¿cuáles son los casos de uso más comunes que ves para cosas como CoPilot, chat GPT u otros sistemas GPT? Así que en cuanto a CoPilot, por ejemplo, la última vez me preguntaba si sabe sobre la principal brecha o problema en Cypress. Y pregunté sobre esto, y CoPilot me dijo que hay un problema para las pruebas móviles. No podemos probar la aplicación móvil. Eso es cierto, por supuesto. Es claro y es obvio. Y en cuanto a los casos de uso comunes, simplemente puedes intentarlo para los casos de prueba, como mencioné, y puedes intentarlo para la lista de verificación y este trabajo simple que puede ser fácilmente delegado. Creo que es esa cosa de delegación fácil y, ya sabes, razonablemente, no sé exactamente la manera correcta de expresar esto, donde no necesariamente puedes tener una gran, gran, gran cantidad de confianza en un primer paso y eso no es absolutamente perjudicial.

Esta pregunta tiene un gran número de pulgares arriba, con respecto a los datos sensibles. ¿Cómo evitamos no pasar datos sensibles sin nuestro conocimiento? Porque imagino que esto sucede a veces o en términos simples, ¿cómo podemos ser más cautelosos alrededor de no dar nuestros datos sensibles a estos sistemas? Cuando mencioné datos sensibles, me refiero a que se trata más sobre el nombre de usuario. Se trata más de contraseñas. Y por supuesto, no se trata de secretos de la empresa. Se trata solo de datos realmente sensibles de los usuarios de nuestro producto. Y esto es lo mismo cuando escribes en tu prueba y te deshaces de estas credenciales importantes y sensibles. Simplemente lo haces a través, no sé, archivo gitignore u otras cosas cuando configuras tu para pruebas. Y esto es lo mismo cuando configuras estas herramientas de IA para tu ayuda, necesitas estar seguro de que no hay estos datos sensibles como mencioné, contraseñas, inicios de sesión, etc. Imagino que es muy similar a simplemente pasar datos a los flujos de trabajo CICD. Quieres asegurarte de emitir datos. Probablemente sea una cantidad de vigilancia muy similar a la que necesitarías emprender.

¿Cómo... Déjame leer esta pregunta. ¿Cómo se separa de alguna manera... Así que sí. Entonces, cuando se trata de escupir estas pruebas, genial.

Estoy configurándolos. Estoy configurando mis archivos de prueba. ¿Deberías, o cómo podrías separar o deberías molestarte en separar las pruebas que son escritas por una IA, una máquina versus aquellas que son realmente hechas a mano y escritas manualmente por los desarrolladores?

Es muy notable cuando es generado por IA porque todavía tenemos el factor humano. No estoy seguro si eres un buen probador por ejemplo o no, pero cuando generas una prueba por ti mismo, puedes perder algo o el título de esta prueba no... Parece que no es técnico. Es solo el nombre del caso de prueba y está ubicado en tu prueba. Pero cuando es generado por IA, se ve increíble. Sabes, es wow. El nombre de esta prueba es realmente, realmente detallado y la estructura de esta prueba también es notable.

Y en cuanto a la separación entre una de la segunda parte, incluso si vas a implementar, y creo que implementarás esta prueba generada por IA en tu marco de pruebas, todavía tendrás algo de trabajo manual solo para tener una guía de desarrollo. Necesitas crear tus propios, por ejemplo, títulos o necesitas crear variables. Y por ejemplo, alguien apoya la página de componentes como para otros componentes, y tú también puedes hacer este tipo de trabajo adicional.

Tengo una pregunta volviendo a algo que dijiste antes y parte de tu charla también. Entonces, ha generado esta prueba, la prueba es incorrecta. Hay algún error con ella. Y entonces todavía hay un grado de vigilancia que debes tener de las herramientas generadas por IA antes de simplemente seguir adelante y tomar esas pruebas e implementarlas. Y me pregunto si para muchas pruebas de escritura es mucho de... Incluso los ejemplos que diste, no eran necesariamente muy advanced ejemplos, pero escribir muchos de ellos es bastante menial. Me pregunto, ¿tienes algún pensamiento en torno al intercambio de tiempo entre tener IA generando algo que podría o no estar mal y necesitar revisarlo y validarlo versus simplemente escribirlo manualmente en primer lugar?

Depende de la complejidad. Si solo se trata de comprobar los componentes, tal vez no sea un buen ejemplo con API, pero cambiaré al lado de la interfaz de usuario. Entonces, si solo necesitamos comprobar los componentes, no intentamos la prueba de extremo a extremo completa cuando te conectas a la database y realizas algunas acciones antes de ejecutar tus pruebas. Cuando solo necesitas probar, no sé, el formulario de inicio de sesión, es suficiente. Pero si tienes algunas cosas muy difíciles y profundas, puedes usarlo como ayuda. Por supuesto, facilitará tu trabajo. Pero aún así, como probador experimentado, no lleva mucho tiempo escribirlo por ti mismo, pero será fácil para ti hacerlo. Espero que esté claro. Sí. Solo... Es este intercambio en mi mente que no está del todo claro. No estoy seguro si solo estoy dando vueltas en círculos y otros están sintiendo lo mismo o no sintiendo lo mismo.

Pero en el momento en que validé la salida potencialmente alucinada de la IA, para muchas cosas, me sentiría más bien, más seguro simplemente escribiéndolo. También el ejemplo que diste, y de hecho, otra pregunta, que haré como una introducción a la mía. Oh, no, accidentalmente marqué la casilla. La pregunta era, ¿cuántas pruebas has generado de esta manera? ¿Estamos hablando de docenas, cientos, miles? Si es en ese número más grande, ¿cuál es tu estrategia para validar una salida antes de aceptar una prueba?

Sí, en caso de que esté presionado por el tiempo y actualmente ya no tengo esta situación, pero cuando lo estaba, puedo generar alrededor de 50 pruebas en un día. Y por supuesto, si lo haces manualmente, puedes copiar y pegar y cambiar algunos data allí, pero también necesitas cambiar las afirmaciones. También necesitas revisarlo dos veces. Así que 50 pruebas, fue mi máximo. Interesante. Y en ese punto, todavía puedes hacer alguna validation manual. Por supuesto. Porque son números lo suficientemente pequeños como para que puedas echar un vistazo. Algo de eso es simplemente manual. Algo de eso será lanzarlo en un editor de código, asegurándote de que está afirmando correctamente. Pero, sí, eso es interesante. Pero entonces el tiempo ahorrado para 50 y el tiempo ahorrado para 1,000 son simplemente tan, tan diferentes. Eso es súper interesante.

Tenemos tiempo para tal vez una pregunta más súper rápida. Y es en realidad esa pregunta. Marqué la casilla de nuevo en lugar de la cosa que la trae, pero recuerdo la pregunta. Lo siento mucho, a todos. La pregunta era, ¿cuánto tiempo crees que esto te ha ahorrado en la práctica en cualquier proyecto dado, cualquier ronda de escritura de pruebas? Al principio, puedes ahorrar al menos dos días. Es un mínimo que puedes ahorrar. Sí. Excelente. Genial. Estaría interesado... Versus qué. ¿Me puedes dar una idea? ¿Dónde estabas al principio? ¿No había pruebas escritas y esto es solo vamos a construir lo básico aquí? ¿O fue un poco más de contexto sería realmente útil? Sí. Entonces, si comencé desde cero, no había nada. Y puedes ahorrar tu tiempo. Puedes hacer este trabajo en dos días versus siete días, por ejemplo. Fue mi conteo personal. Así que sí. Interesante. Genial. Muchas gracias. Eso fue fascinante. Realmente aprecié tener un poco más de tiempo para hacer preguntas. Un gran aplauso para Olga, por favor. Gracias.