Muy buen aporte!!! Gracias!
Al proximo post  podriamos agregarle como integro newman con Jenkins para correrlo desde un job.

Scrum es un enfoque ágil para el desarrollo de software, que se centra en ofrecer características comerciales valiosas en iteraciones de desarrollo cortas de 2 a 4 semanas. Los equipos Scrum tienen dos características definitorias: son multifuncionales (es decir, incluyen todas las habilidades necesarias para realizar el trabajo) y se auto organizan (es decir, se espera que el equipo descubra la mejor manera de hacer el trabajo. El rol del QA en Scrum es mucho más que escribir casos de prueba y reportar errores al equipo, pero muchos se preguntan, ¿Cómo pueden los profesionales de pruebas participar de manera efectiva durante un sprint antes de que se haya construido algo?"
En un equipo Scrum, los analistas de QA participan y cumplen una variedad de responsabilidades junto con otros miembros del equipo. Están involucrados desde el principio de un proyecto en el que trabajan en estrecha colaboración con analistas de negocios y desarrolladores. En Scrum, el rol de QA no es un equipo separado que prueba la aplicación que se está construyendo. En cambio, el equipo de Scrum es un equipo multifuncional donde los desarrolladores, analistas de negocios y QA trabajan juntos. Tener QA como representante del Product Owner cuando no está disponible ayuda a que el equipo siga avanzando en todo momento. También pueden interactuar con el propietario del producto haciendo preguntas y desafiando suposiciones para ayudar a aclarar los requisitos comerciales.

Estimación de historias
Los analistas de garantía de calidad suelen ser muy buenos para crear escenarios de casos de prueba basados en los requisitos del usuario. También se destacan en la identificación y captura de escenarios de casos de prueba complejos y negativos. De hecho, suelen ser mucho mejores en eso que los desarrolladores, que tienden a centrarse principalmente en el "camino feliz" de la historia del usuario. Incluir QAs durante la planificación de la versión y la iteración, cuando se estiman las historias de los usuarios, puede ayudar al equipo a pensar más allá del camino feliz. Esto ayuda al equipo a producir una estimación más realista, ya que se han considerado tanto los caminos "felices" como los "infelices". La estimación es una tarea difícil y es una buena práctica que todo el equipo participe en la elaboración de la estimación.

Colaborar con clientes y desarrolladores
Una de las principales responsabilidades de la función de calidad es proporcionar comentarios de su experiencia de prueba al PO, así como recopilar comentarios de ellos. Los QA trabajan en estrecha colaboración con el propietario del producto para ayudarlo a desarrollar criterios de aceptación detallados para sus historias de usuario. Según lo que el equipo aprende durante cada sprint, pueden ayudarlo a modificar o mejorar las historias de  usuario existentes para reflejar mejor los requisitos reales.
En estas situaciones, los QA y los desarrolladores se sentarán y trabajarán juntos para ayudar a mejorar la calidad del proyecto. Los QA pueden emparejarse con los desarrolladores para escribir casos de prueba y discutir los criterios de aceptación. Cuanto más trabajen juntos estos roles, mayor será la claridad compartida sobre los requisitos. Esta claridad que resulta de trabajar juntos reducirá las preguntas y dudas que los desarrolladores encuentran a menudo durante el tiempo de codificación, lo que produce una mayor eficiencia y un gran ahorro de tiempo tanto para los desarrolladores como para los testers.
También ayuda a producir el ritmo requerido para moverse más rápido con comentarios de prueba tempranos y mayor calidad.

Comentarios rápidos
El ciclo de construir-probar-arreglar que los equipos tradicionales de Waterfall repiten sin cesar produce mucho trabajo extra para el equipo y generalmente termina perdiendo mucho tiempo. Esta actividad es mucho más simple en Scrum ya que los QA y los desarrolladores trabajan juntos durante todo el proceso. Los desarrolladores pueden consultar los QA sobre los criterios de aceptación o el comportamiento esperado de cualquier funcionalidad desde la perspectiva del usuario mientras trabajan en la función, lo que da como resultado ciclos de prueba y corrección de errores guardados.

Automatizar las pruebas de regresión
A menudo se dice que la automatización es el mejor amigo del QA, ya que proporciona repetibilidad, consistencia y una mejor cobertura de prueba sobre la funcionalidad del software. Esto es particularmente cierto en un proyecto Scrum con pequeños ciclos de sprint de 2 a 4 semanas, ya que QA generalmente tiene menos tiempo para probar la aplicación. Durante cada sprint de 2 semanas, QA debe realizar pruebas de funcionalidad completa de las nuevas características que se agregan durante este sprint, así como realizar pruebas de regresión completas para todas las funciones implementadas previamente. Como era de esperar, esta responsabilidad aumenta significativamente con cada sprint que pasa, por lo que cualquier automatización que se pueda aplicar a estas pruebas reduciría en gran medida la presión que sienten los Testers
Las pruebas automatizadas son particularmente útiles para proporcionar retroalimentación rápida cuando los equipos implementan la Integración Continua (CI). Cada vez que hay una nueva compilación, las pruebas automatizadas se pueden ejecutar y proporcionar información inmediata sobre si las nuevas funciones están funcionando correctamente o si ha habido regresiones de la funcionalidad que funcionaba anteriormente. Sin automatización, QA debe realizar estas pruebas manualmente, lo que se convierte en una tarea muy monótona y propensa a errores. La automatización puede ayudar a detectar los defectos de forma temprana y dar a QA más tiempo para explorar los casos extremos de las nuevas funciones que se están desarrollando. La automatización puede ayudar al área de calidad a realizar trabajos de prueba de forma mucho más eficiente y eficaz.

Hacer cumplir la DOD
Tener una Definición clara de Terminado (DoD) es importante para un equipo Scrum. Un DoD no es más que una simple lista de criterios de finalización definidos por el equipo, todos los cuales deben completarse antes de que la historia del usuario pueda considerarse completa. Esta lista generalmente incluye cosas como escribir código, realizar pruebas funcionales y de regresión y obtener la aprobación del PO. Un DoD muy simple podría incluir lo siguiente:
•   Código completo
•   Prueba unitaria completa
•   Prueba funcional / UI completa
•   Aprobado por el propietario del producto
Si bien no es responsabilidad exclusiva de QA definir el DoD, a menudo es responsabilidad de QA monitorear el trabajo que realiza el equipo y asegurarse de que cada historia de usuario completa cumpla con el DoD de referencia. Un equipo Scrum eficiente revisará su DoD antes de comenzar cada nueva historia de usuario para asegurarse de que sepan lo que se espera.

Convergencia de funciones de tester y analista
En los equipos Scrum, es común ver que las responsabilidades de QA y las del analista de negocios comienzan a converger. El rol de Business Analyst es típicamente responsable de crear y mantener el sprint y el backlog del producto, analizar las historias de los usuarios desde la perspectiva del negocio y priorizar los requerimientos con información del Product Owner. El rol de QA, por otro lado, generalmente es responsable de ayudar a definir / refinar los criterios de aceptación para cada historia de usuario, probar la funcionalidad completa de cada sprint desde la perspectiva del usuario final y garantizar que toda la funcionalidad completada previamente no haya retrocedido. A medida que QA prueba cada historia de usuario y verifica que los criterios de aceptación definidos se hayan cumplido desde la perspectiva del usuario final, también están analizando las historias de usuario en términos del negocio.

Conclusión
Si bien los QA aún escriben pruebas e informan errores, también apoyan muchas otras funciones y responsabilidades en el equipo. Son una parte importante del equipo y están involucrados en el proyecto desde el principio.
Trabajar como analista de calidad en un equipo Scrum es una gran experiencia y brinda muchas oportunidades de aprendizaje.  En resumen, esta experiencia agrega muchas habilidades maravillosas a nuestra caja de herramientas y ayuda a aprender a desempeñar muchos roles diferentes, todo al mismo tiempo. Lo más importante es que se aprende a hacer preguntas en lugar de simplemente seguir la documentación y hacer lo que sea necesario para ayudar al equipo a tener éxito.

Buenas! necesito extraer el xpath de este elemento para poder hacer un getText() al WebElement.
probe con la clase, pero me trae 3 resultados, probe con ancestor y con parent... y no me trae nada. en la class help.block  se mostraran los diferentes mensajes de error en la misma posicion de acuerdo al tipo de error que se presente.

Marina.carrizo
@No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Hola, tengo un documento parecido en drive. quizás este post pueda completarse con la información que hay allí.
No tienes permitido ver los links. Registrarse o Entrar a mi cuenta