Cómo elegir una herramienta de automatización

Espero que todos se sientan bien y antes que nada, quiero agradecerles a todos por estar aquí hoy. Soy Lia y les mostraré un proceso que pueden utilizar para elegir una herramienta de automatización. Haré una comparación general de tres frameworks que considero los mejores en este momento, y hablaré un poco sobre otras herramientas que pueden integrar en su proceso de automatización.

Así que una breve introducción sobre quién soy. Soy una ingeniera de software en Nocare. Mi enfoque principal es la automatización de pruebas. Y ahora vamos a sumergirnos en esto. Este es un proceso de tres pasos, como todos los buenos, por supuesto. Pero cada paso requerirá atención y trabajo. Así que sigamos adelante y sumerjámonos en la primera fase, que es analizar.

Analizar significa responder algunas preguntas. Y la primera no es realmente una pregunta. Es entender su aplicación. Mírenla y sean realmente críticos al respecto. Traten de entender cuáles son los puntos débiles, las características que se pueden romper más fácilmente, y traten de pensar en casos extremos en la aplicación. Así que tengan una imagen general de la aplicación que van a probar y hagan una lista. Hagan una lista de las pruebas que quieren o necesitan hacer. En este momento, sería una buena idea hablar con el equipo de desarrollo y tratar de entender cuál es la cobertura de pruebas unitarias que tienen, si es que tienen, y al conocer su cobertura pueden evitar la duplicación de trabajo por su parte.

Y si no tienen pruebas unitarias, es una buena oportunidad para reunirse con ellos y con el equipo de gestión y pensar en una forma de tener cobertura desde el desarrollo hasta la producción. Y esto significa tener pruebas de automatización en todas las partes del proceso. Así que el equipo de desarrollo tendrá pruebas unitarias y ustedes pueden tener pruebas de seguridad, accesibilidad, o cualquier otro tipo que consideren más adecuado. Teniendo esto en cuenta, tendrán que preguntarse si quieren programar o no, y preguntar a su equipo si se sienten cómodos haciéndolo. Y en qué lenguaje se sienten más cómodos trabajando. Así que teniendo esto, terminarán con una lista más o menos como esta, en la que tienen si el equipo de desarrollo tiene pruebas unitarias o no, qué tipo de pruebas van a hacer, y tendrán un lenguaje con el que se sientan más cómodos trabajando, si eligen programar. Así que si no quieren programar, eso no es un problema porque aquí somos inclusivos y tenemos opciones para todos. Y si no quieren programar, les daré dos opciones que conozco, y tengan en cuenta que creo que hay muchas más opciones para ustedes, así que si estas opciones que les voy a dar no se adaptan a sus necesidades, simplemente búsquenlas. Y estamos entrando aquí en la siguiente parte que es buscar, pero antes les voy a hablar sobre testing y perfecto, y estas dos son similares en las cosas que pueden hacer, pero en una explicación rápida, estas dos graban sus pruebas manuales, y por cada acción que realicen en el navegador hacen un bloque. Y cuando terminen tendrán su caso de prueba y su automatización que es un grupo de bloques, al igual que en la programación pueden crear un grupo de bloques que pueden reutilizar entre pruebas, pueden crear carpetas para ejecutar en cada implementación, tienen un grupo completo de opciones que pueden tener al igual que en la programación. Así que si no quieren programar, echen un vistazo a esta herramienta y sumérjanse en ella porque estoy segura de que también tendrán opciones para ustedes. Así que si quieren programar, haré una comparación entre Selenium y Cypress.

Selenium y Playwright. Y esto es más o menos lo que van a hacer en la parte de búsqueda con los frameworks que elijan para comparar. Y comenzando con Selenium. Selenium es un framework que ha estado aquí durante mucho tiempo, y esto significa que Selenium tiene una gran comunidad que lo respalda. Y no estarán solos trabajando porque tendrán Stack Overflow para ayudarlos con un gran grupo de personas que pueden ayudarlos. Y en general, es un framework realmente bueno, pero necesitará terceros para trabajar con ciertos tipos de pruebas. Entonces, Selenium automatiza el navegador. Simula una interacción real del navegador, lo que significa que si necesitan hacer pruebas de API, deberán integrarse con un tercero para tener las pruebas de API. Y dado que Selenium no admite por sí mismo pruebas paralelas, deberán integrarse con Selenium Grid y una herramienta de navegadores cruzados para que funcione. Y para mí, las desventajas más importantes de Selenium son que no tiene una herramienta de informes incorporada, por lo que necesitarán un tercero como X-Ray o Test Rail, de los que hablaré un poco al final, para admitir esto. Y no admite iframes o popups. Entonces, si su aplicación depende de iframes de terceros, Selenium no será realmente el framework adecuado. Pero, si esto es algo con lo que pueden vivir sin, Selenium es realmente muy bueno para trabajar con un gran conjunto de pruebas, pero, como les dije, necesitará integraciones de terceros para algunos tipos de pruebas, y esto hará que sea más difícil trabajar al principio. No estoy diciendo que sea imposible porque nada es imposible, pero necesitarán algo de experiencia y conocimiento para comprender cuáles son las soluciones alternativas que deben hacer aquí, ¿de acuerdo? Entonces, es una buena herramienta. Si quieren algo más fácil para comenzar, pasemos a la otra herramienta y comprendamos cuáles son las diferencias aquí. Con Cypress, Cypress es una herramienta todo en uno, lo que significa que el equipo de desarrollo puede hacer pruebas unitarias y ustedes pueden hacer los otros tipos de pruebas en su sitio, y todo el equipo trabaja con el mismo framework, y esto es genial porque pueden ayudarse mutuamente y revisar el código entre ustedes, y es muy completo, tiene un informe incorporado, no necesitan integrarse con terceros aquí, pero la desventaja es que solo funciona con JavaScript y no admite pruebas paralelas y pruebas multitap, lo que significa que si necesitan tener ciertos tipos de configuraciones que deben ejecutarse al mismo tiempo, por ejemplo, si quieren tener un navegador con un dispositivo y varias configuraciones al respecto, deberán ejecutarlos por separado. Entonces, será un tiempo muy largo ejecutar el caso de prueba. Si necesitan tener varios conjuntos de configuraciones aquí, varios entornos ejecutándose al mismo tiempo, deben considerar si Cypress será una buena herramienta para ustedes. Pero para principiantes y para un grupo pequeño o mediano de pruebas, Cypress es realmente bueno. Es una herramienta muy simple de trabajar si trabajan con JavaScript, por supuesto. Es una herramienta muy simple de trabajar y tiene mucha documentación, la comunidad está creciendo, por lo que tendrán ayuda en Stack Overflow para cualquier tipo de datos que necesiten. Pero tiene sus desventajas, al igual que todos los frameworks que encontrarán aquí. Pasando a Playwright, Playwright es un framework bastante nuevo. La primera vez que escuché hablar de él fue aquí en 2020, si no me equivoco, y creo que es el más completo de los tres. Pueden tener todo tipo de pruebas ejecutándose en Playwright, admite pruebas paralelas para que puedan tener varios conjuntos de configuraciones y entornos ejecutándose al mismo tiempo. Tiene aislamiento de contexto para que puedan tener pruebas para nuevas pestañas y clics que se abren en una nueva pestaña, puede capturar videos y capturas de pantalla para que puedan tener pruebas visuales en comparación. Pero es un framework nuevo, así que tengan en cuenta que hay algunos tipos de características que no están completamente desarrolladas, por lo que si buscan un framework establecido, tal vez Playwright no sea la opción. Y dado que es un framework nuevo, la comunidad no es muy grande en comparación con los otros dos, por lo que necesitarán tener algo de experiencia en programación y conocimientos, y buscar cosas porque estarán un poco solos en esto. Tendrán la comunidad de Playwrights para resolver dudas, pero Stack Overflow no está realmente lleno de preguntas y respuestas sobre cómo avanzar con Playwright. Así que tengan en cuenta que necesitarán dedicar mucho tiempo a intentar avanzar con Playwright y la documentación es un poco confusa porque, dado que hace muchas cosas, es un poco complicado trabajar con ella.

con. Pero si quieres tomarte el tiempo para trabajar con el framework que lo hace todo por sí mismo, creo que será muy bueno trabajar con Playwright. Así que en general, creo que debes elegir con qué te sientes cómodo. Así que echa un vistazo al árbol, juega un poco con cada uno de ellos, si tienes tiempo, y elige uno con el que te sientas cómodo trabajando. Porque esto es algo con lo que vas a trabajar, como, seis horas de tu día. Así que no elijas uno porque tu amigo te dijo que es el mejor o porque yo te digo que es el mejor. Simplemente elige uno con el que te sientas cómodo y que cumpla la mayoría de las necesidades que tienes para testing una aplicación. Así que, pasando a esto, terminarás con un tablero, o deberías terminar con un tablero, más o menos como este, donde tienes el tipo de prueba que necesitas a la derecha, en la izquierda, lo siento, y marca y cruz o arriba y abajo del framework que estás comparando. Y solo como una nota adicional, cada uno de ellos tiene opciones para trabajar con pruebas de accessibility. El que conozco es AX, que puedes integrar con los frameworks, y puedes usar ApliTools para cada uno de estos tres para ejecutar pruebas visuales. Ten en cuenta que Cypress y Playwright hacen esto por sí mismos con capturas de pantalla y videos, pero si quieres que un tercero trabaje en esto, puedes trabajar con ApliTools. Después de esto, elegirás, o no, un informe, y esto será una comparación rápida porque no quiero profundizar mucho en esto, porque creo que elegir un informe no es una decisión solo del equipo de calidad, debería ser una decisión de todo el equipo de producto porque todos deberían estar integrados en el proceso. Pero solo en una comparación rápida, Xray tiene integración con Jita, TestRail también tiene integración con Jita, pero no es tan obvio que esté allí. Y Xray, puedes crear planes de prueba, ejecución de pruebas para integrar con los problemas que tienes en Jita, teniendo en cuenta que trabajas con Jita. Si no trabajas con Jita, esta no es una muy buena opción para ti. Pero en mi opinión, Xray es una herramienta más integrada con Jita y visible para todos en el equipo lo que se está testing y lo que se está haciendo para el equipo de calidad. Y TestRail está más en el lado negativo. Así que si quieres una herramienta con la que el equipo de calidad trabajará por separado de todos los demás equipos, iría con TestRail. Y si quieres una herramienta más integrada con el proceso y el equipo de producto y el equipo de desarrollo, iría con X-Ray.

Pero pasando a la parte del plan. Eso es lo importante... No diré lo importante, pero la parte en la que debes dedicar un poco más de tiempo para entender cómo lo vas a hacer. Así que la palabra clave aquí es priorizar. Y lo que quiero decir con priorizar es elegir qué pruebas vas a hacer primero. Y esto podría ser la prueba de extremo a extremo más dolorosa que haces manualmente. Y puede ser la prueba más simple que haces solo para comenzar y tratar de entender si puedes trabajar con este framework. Así que simplemente une a un equipo y si estás solo no te sientas triste, simplemente hazlo. Y piensa en ello, siéntate realmente y mira lo que vas a hacer y cuál va a ser lo primero que vas a hacer. Y paralelamente a esto, haz documentation. Esto es muy importante porque el conocimiento no puede estar solo en tu mente, necesitas compartirlo con el mundo, con el equipo, con la empresa para que las personas sepan lo que estás testing para asegurarse de que la aplicación es estable para ir a producción. Y solo para que tengas un lugar donde puedas confiar para entender

Recuerda lo que hiciste en el pasado. Porque ahora mismo, si estás comenzando, es muy fácil entender lo que estás haciendo, pero en 6 meses, o 1 año a partir de ahora, realmente dudo que recuerdes lo que estabas pensando cuando comenzaste el proyecto. Entonces, si tienes documentación, te ayudará a tener un lugar al que acudir, para recordar lo que estabas pensando al principio, para mostrar a otras personas qué se está probando en la aplicación, y es una buena práctica. Sé que a algunas personas del equipo de desarrollo realmente no les gusta tomarse el tiempo para hacer documentación, pero simplemente hazlo. Es una buena práctica y me lo agradecerás al final, créeme. Y después de tener esto, después de tener la lista de tipos de pruebas que quieres elegir y que eliges hacer, lo siento, el framework que eliges usar, el autor que crees que es el mejor para que el equipo lo use y las priorizaciones de las pruebas que vas a implementar, ahora es el momento de programar una reunión con el equipo de dirección o con el gerente. Así que estructura esto de manera que cuando lo presentes, no haya opción para que digan que no. Así que hiciste todo el trabajo, analizaste el producto, buscaste los frameworks, planificaste el trabajo que vas a hacer en el próximo mes, dos meses, en el futuro. Así que preséntalo con la certeza de que el equipo y tú quieren hacer esto y están muy seguros de que esto es lo mejor para el equipo y para el producto y ten confianza al respecto. Esto es importante decirlo porque creo que a veces la gente solo piensa que esta es mi opinión, pero ten mucha confianza en que esto es lo mejor que se puede hacer y lo vas a hacer. Y comparte esa confianza con el equipo de dirección y ten la seguridad de que no te cortarán las alas, estarán realmente muy contentos de dejarte hacer esto. Así que diviértete mucho trabajando en esto, programando o no programando, y si tienes alguna duda, simplemente inténtalo. Muchas gracias y nos vemos la próxima vez. Adiós.