Hola!! Muy buen análisis. Yo use cucumber como 3 años hace algunos años atrás y cuando probé cypress o testcafe sin la necesidad de implementar esta capa extra de cucumber me facilitó la vida. En la práctica nadie lee los features de cucumber, solo les importa el reporte de ejecución final y eso lo resolvemos con los frameworks más utilizados hoy día como playwright, cypress, t etc. Saludos desde España.
Exacto! Ese es el tema más importante acá: Alguien lee esos features? Sino... ni los usemos. Y si lo hacen...necesitamos una forma menos engorrosa de colaborar.
No es que piense que se requiere Cucumber, pero si el cliente esta dispuesto a pagar por los features es algo que se debe presentar, por lo regular en los trabajos donde se pide un Playwright o Cypress tester no se está pidiendo Cucumber,, entonces parece que ya se dieron cuenta que no se requiere Cucumber!
Totalmente de acuerdo... Yo me gaste varios meses iterando el Gherkin con el BA y terminaba yo escribiendo los features que como dices tu luego NADIE los leia. Tambien estoy de acuerdo en que a nadie de la capa de negocio incluso a los devs les interesa meterse a tu repo a ver que hiciste en tus pruebas... todos quieren ver si PASO o NO PASO el test y eso es directamente proporcional al reporte HTML. Me parece maravillosa esta ventana que estas abriendo a eliminar una capa que en realidad se usa por moda o por vender humo. El proyecto quiere valor y resultados.. no cañones para matar moscas
Buenas! Estoy aprendiendo Playwright (vengo de usar Cucumber) y me surge la siguiente duda: como se pueden definir los Scenarios Outline? Es decir, como se pueden introducir los "Examples" para ejecutar el test más de una vez con diferentes variables? Gracias!
Hola! Lo podés hacer con un loop for. En el curso de Playwright hicimos casualmente un ejercicio como este usando un test para validar varios redirects.
Confieso que un poco amarillista el planteo, pero... no se eh jajaja. Cómo lo ves Charly? La reusabilidad y el hecho de que las personas que colaboran necesiten que se ejecute para generar el reporte y ver al nivel de sintaxis necesario no me termina de cerrar. En otro comentario estaba planteando la idea de un plugin para generar un artefacto o lo que sea en función de los test.steps y demás...
@@FreeRangeTesters en general siempre opino de que si realmente se utiliza como documentación viviente y tanto las áreas técnicas como no técnicas la utilizan, perfecto. Ahora si luego NADIE lee los features me parece una perdida de tiempo y aumento innecesario de complejidad. El problema es el uso sin fundamento o el mal uso, si tenés un escenario de 3737373315 pasos en los que detallas interacción con la UI, eso es una red flag.
El reporte sale en el localhost porque lo levanta en un servidor local. En Python te recomiendo MIL que pruebes con Allure. En el curso de Selenium con Python en la web lo cubrimos.
No encuentro sentido a la comparación. Es mas que claro que cualquier proyecto que tenga Cucumber va a tener una capa de complejidad, y compararlo con otra que no tenga siempre va a ser "mas simple"... no te parece? De todos modos cualquier framework de testing tiene anotaciones que te permite generar un estilo BDD...
Fue un experimento, idea que quise hacer. La comparación pasa por el objetivo que tiene Cucumber y cómo se podría hacer de otra manera, no un 1:1 entre herramientas. Cucumber está para que colaboren las partes, para que se lea fácil lo que se está probando...y creo que se puede hacer de formas más sencillas con los frameworks más modernos que tenemos ahora.
No coincido con vos. Mi punto de vista: - No murió el proyecto Cucumber, hay comunidad y gente atras manteniendo el proyecto (por lo que ya sentenciar que murió como titulo es un poco amarillista che 😆, igual banco un poco de clickbait para sumar interés en el tema) - La forma que propones necesita de una ejecución para que negocio acceda a esa documentación, lo cual es una GRAN contraparte a que ellos puedan disponer de la documentación y consultarla/pedir modificaciones (literalmente necesitas otra herramienta más de documentación, así sea Confluence, el mismo JIRA, etc. que si bien por lo general se trabaja a la par, me he encontrado/redactado con .features más legibles que las mismas HU) - Hay una capa intermedia entre Negocio y QA Automation que quizás no consideras, que son los QA manuales que le pueden sacar mucho provecho a escribir los .features. Implementé en varios proyectos (trabajo en consultora) trabajo colaborativo con QA manuales los cuales se encargaban de escribir estos .features y luego los QA automation los automatizabamos, lo cual es genial para negocio (que se hace de los test cases más rápido) y para automation (que con solo el IDE abierto ya puede resolver la automatización y no perder tiempo en revisar requerimiento, escribir test case, etc.). Con la metodología que propones es algo más dificil algo similar o como dije antes necesitas de una 2nda herramienta en la cual apoyarse. No todo es desacuerdo, coincido en empezar a investigar en alternativas para el como trabajamos, quizás la IA juegue un papel en el nexo QA-Negocio en el futuro (?). Me parecen piolas tus videos, me gustaría bastante ver diferentes workflows que hayas implementado para los proyectos en los que trabajaste. Stack que usaste para determinada necesidad, estructura del proyecto y esas cuestiones que a veces me pasa que me cuesta flexibilizar y adaptar un framework o metodología de trabajo y vendría super bien. Saludos!!
Hola Coco! Si, fue un poco extremo el título, pero ud me entiende :). Por el lado que lo veo yo, los QA manuales y las otras partes que colaboran con este tipo de documentación pueden hacerlo directamente en las user stories al escribir los scenarios en este formato. Es más...idealmente las user stories deberían tener su criterio de aceptación escrito así. Y si...lo de la ejecución para obtener el documento es la parte que menos me cierra de este experimento, pero... si está en la user story... por ahí estaría bueno un plugin que muestre, sin ejecutar, esta documentación generada a partir de los describe/test/steps en el IDE o repo en alguna parte... La otra parte que no me gusta al 100% es la no reusabilidad de los steps, aunque sí es cierto que podría crear funciones para las partes repetitivas...pero no estarían acopladas necesariamente al test.step... en fin, es un rabbit hole en el que me voy a seguir metiendo porque me interesan las alternativas que puedan haber para tener un mejor pantallazo de lo que se prueba.
Creo que todos lo odiamos. Aunque...tenemos que ser justos. Lo odiamos seguro porque caímos en un proyecto en el que se implementó muy mal y nos tocó sufrirlo.
Hola Pato yo siempre he usado selenium con java, testng y maven, reporte de allure y resulta que en los test anotation también tengo un anotation describe y quizás ahí podría poner todo el mono de gherkin.. Given, when, then. Se podría de igual modo? . Por que en los reportes me sale esa información. Saludos.
Mirá...yo RE exploraría qué te brinda TestNG para hacer algo similar a lo que se hace con Cucumber. De hecho...me lo llevo para un posible Test Drive acá en el canal.
Alto video❤ Buen update! Ahora mismo uso Playwright en mi proyecto, amandolo cada vez más jaja sin usar el pinche cucumber
Hola!! Muy buen análisis. Yo use cucumber como 3 años hace algunos años atrás y cuando probé cypress o testcafe sin la necesidad de implementar esta capa extra de cucumber me facilitó la vida. En la práctica nadie lee los features de cucumber, solo les importa el reporte de ejecución final y eso lo resolvemos con los frameworks más utilizados hoy día como playwright, cypress, t etc. Saludos desde España.
Exacto! Ese es el tema más importante acá: Alguien lee esos features? Sino... ni los usemos. Y si lo hacen...necesitamos una forma menos engorrosa de colaborar.
Leer los features? Que eso? Naa jodo. Nadie los lee mayormente
No es que piense que se requiere Cucumber, pero si el cliente esta dispuesto a pagar por los features es algo que se debe presentar, por lo regular en los trabajos donde se pide un Playwright o Cypress tester no se está pidiendo Cucumber,, entonces parece que ya se dieron cuenta que no se requiere Cucumber!
Yo creo que depende del contexto del proyecto siempre. Cucumber en si no es malo, el uso que le dan es malo
Gracias por la información. Yo que estoy empezando me sirve mucho
Me alegra que te sirva Christian!
Gracias por hacer este tipo de videos 😊
Gracias! Se vienen un par de experimentos relacionados a este video también :)
Totalmente de acuerdo... Yo me gaste varios meses iterando el Gherkin con el BA y terminaba yo escribiendo los features que como dices tu luego NADIE los leia. Tambien estoy de acuerdo en que a nadie de la capa de negocio incluso a los devs les interesa meterse a tu repo a ver que hiciste en tus pruebas... todos quieren ver si PASO o NO PASO el test y eso es directamente proporcional al reporte HTML. Me parece maravillosa esta ventana que estas abriendo a eliminar una capa que en realidad se usa por moda o por vender humo.
El proyecto quiere valor y resultados.. no cañones para matar moscas
Dado que también sufriste BDD al divino botón
Cuando te encontrás con alguien que le pasó lo mismo
Entonces vas a hacer high five con esa persona
Buenas! Estoy aprendiendo Playwright (vengo de usar Cucumber) y me surge la siguiente duda: como se pueden definir los Scenarios Outline? Es decir, como se pueden introducir los "Examples" para ejecutar el test más de una vez con diferentes variables? Gracias!
Hola! Lo podés hacer con un loop for. En el curso de Playwright hicimos casualmente un ejercicio como este usando un test para validar varios redirects.
Saluden a Cucumber 👋🏽
😂Arrivederchi cucumber
Confieso que un poco amarillista el planteo, pero... no se eh jajaja. Cómo lo ves Charly? La reusabilidad y el hecho de que las personas que colaboran necesiten que se ejecute para generar el reporte y ver al nivel de sintaxis necesario no me termina de cerrar. En otro comentario estaba planteando la idea de un plugin para generar un artefacto o lo que sea en función de los test.steps y demás...
@@FreeRangeTesters en general siempre opino de que si realmente se utiliza como documentación viviente y tanto las áreas técnicas como no técnicas la utilizan, perfecto.
Ahora si luego NADIE lee los features me parece una perdida de tiempo y aumento innecesario de complejidad.
El problema es el uso sin fundamento o el mal uso, si tenés un escenario de 3737373315 pasos en los que detallas interacción con la UI, eso es una red flag.
Nueva opción y nueva forma de mostra la documentación. Que mas podrás suprimir a futuro Pato???
Pato: "Trabajar".
se puede hacer esto con python? con el locahost tal cual?
El reporte sale en el localhost porque lo levanta en un servidor local. En Python te recomiendo MIL que pruebes con Allure. En el curso de Selenium con Python en la web lo cubrimos.
Muy buen análisis, vas a sacar el curso de playwright en udemy ?😅
Una vez lo termine, si. Mientras está accesible en la web con más de una hora de contenido. Saco clases nuevas todas las semanas :)
No encuentro sentido a la comparación. Es mas que claro que cualquier proyecto que tenga Cucumber va a tener una capa de complejidad, y compararlo con otra que no tenga siempre va a ser "mas simple"... no te parece? De todos modos cualquier framework de testing tiene anotaciones que te permite generar un estilo BDD...
Fue un experimento, idea que quise hacer. La comparación pasa por el objetivo que tiene Cucumber y cómo se podría hacer de otra manera, no un 1:1 entre herramientas. Cucumber está para que colaboren las partes, para que se lea fácil lo que se está probando...y creo que se puede hacer de formas más sencillas con los frameworks más modernos que tenemos ahora.
No coincido con vos. Mi punto de vista:
- No murió el proyecto Cucumber, hay comunidad y gente atras manteniendo el proyecto (por lo que ya sentenciar que murió como titulo es un poco amarillista che 😆, igual banco un poco de clickbait para sumar interés en el tema)
- La forma que propones necesita de una ejecución para que negocio acceda a esa documentación, lo cual es una GRAN contraparte a que ellos puedan disponer de la documentación y consultarla/pedir modificaciones (literalmente necesitas otra herramienta más de documentación, así sea Confluence, el mismo JIRA, etc. que si bien por lo general se trabaja a la par, me he encontrado/redactado con .features más legibles que las mismas HU)
- Hay una capa intermedia entre Negocio y QA Automation que quizás no consideras, que son los QA manuales que le pueden sacar mucho provecho a escribir los .features. Implementé en varios proyectos (trabajo en consultora) trabajo colaborativo con QA manuales los cuales se encargaban de escribir estos .features y luego los QA automation los automatizabamos, lo cual es genial para negocio (que se hace de los test cases más rápido) y para automation (que con solo el IDE abierto ya puede resolver la automatización y no perder tiempo en revisar requerimiento, escribir test case, etc.). Con la metodología que propones es algo más dificil algo similar o como dije antes necesitas de una 2nda herramienta en la cual apoyarse.
No todo es desacuerdo, coincido en empezar a investigar en alternativas para el como trabajamos, quizás la IA juegue un papel en el nexo QA-Negocio en el futuro (?). Me parecen piolas tus videos, me gustaría bastante ver diferentes workflows que hayas implementado para los proyectos en los que trabajaste. Stack que usaste para determinada necesidad, estructura del proyecto y esas cuestiones que a veces me pasa que me cuesta flexibilizar y adaptar un framework o metodología de trabajo y vendría super bien.
Saludos!!
Hola Coco! Si, fue un poco extremo el título, pero ud me entiende :). Por el lado que lo veo yo, los QA manuales y las otras partes que colaboran con este tipo de documentación pueden hacerlo directamente en las user stories al escribir los scenarios en este formato. Es más...idealmente las user stories deberían tener su criterio de aceptación escrito así.
Y si...lo de la ejecución para obtener el documento es la parte que menos me cierra de este experimento, pero... si está en la user story... por ahí estaría bueno un plugin que muestre, sin ejecutar, esta documentación generada a partir de los describe/test/steps en el IDE o repo en alguna parte...
La otra parte que no me gusta al 100% es la no reusabilidad de los steps, aunque sí es cierto que podría crear funciones para las partes repetitivas...pero no estarían acopladas necesariamente al test.step... en fin, es un rabbit hole en el que me voy a seguir metiendo porque me interesan las alternativas que puedan haber para tener un mejor pantallazo de lo que se prueba.
soy automation y odio cucumber saludos
Creo que todos lo odiamos. Aunque...tenemos que ser justos. Lo odiamos seguro porque caímos en un proyecto en el que se implementó muy mal y nos tocó sufrirlo.
Hola Pato yo siempre he usado selenium con java, testng y maven, reporte de allure y resulta que en los test anotation también tengo un anotation describe y quizás ahí podría poner todo el mono de gherkin.. Given, when, then. Se podría de igual modo? . Por que en los reportes me sale esa información.
Saludos.
Mirá...yo RE exploraría qué te brinda TestNG para hacer algo similar a lo que se hace con Cucumber. De hecho...me lo llevo para un posible Test Drive acá en el canal.