Selenio y miembros del equipo no técnico.

Trabajo en un equipo desarrollando un sitio web con una gran cantidad de páginas. El QA en el equipo actualmente ejecuta todas las pruebas manualmente. Estoy pensando en que cree un montón de guiones de Selenium. No creo que pueda automatizar todas las pruebas, pero podría automatizar muchas de ellas.

Debido a que no tiene experiencia en programación, ¿qué tan difícil será para él crear y administrar un lote de secuencias de comandos Selenium? ¿Con qué problemas necesitará ayuda?

Creo que Selenium como una herramienta independiente de "grabación y reproducción" es ideal para usuarios no técnicos. El modismo de grabar mi camino y luego volver a reproducirlo es intuitivo, y la interfaz, aunque obviamente está orientada a los no principiantes, no es demasiado intimidante.

Selenium 2 / Selenium RC es obviamente un orden más alto de complejidad, y no creo que pueda pedirle a un no programador que interactúe con eso. (En realidad, me ha frustrado la falta de una interfaz completa para lenguajes que no sean Java. Sé que la versión actual es de transición, pero realmente podría usar una solución PHP completa en este momento, no en una versión mítica futura. Pero eso no es lo que estás preguntando)

Creo que si tu chico probador ya no sabe sobre Selenium, te besará en la boca por decirle al respecto.

Selenium-IDE está diseñado para ser utilizado por no programadores. Pero mi experiencia es que los scripts que se producen de esa manera (usando XPath generado) son muy frágiles.

Así que crear en ellos no debería ser un problema en absoluto. La administración no será tan mala si su aplicación es bastante estable. O casi imposible si su aplicación está en desarrollo y / o cambia con frecuencia.

Selenium-RC es puramente una herramienta de desarrollo.

Le recomiendo que haga esta pregunta en el sitio beta de Software Quality Assurance & Testing , o busque preguntas similares que ya se hayan hecho allí. Encontrará una mayor experiencia con el uso de Selenium para grabar y reproducir el control de calidad.

La respuesta de Eric es la experiencia de la mayoría de los ingenieros de control de calidad que utilizaron herramientas de grabación y reproducción: las pruebas resultantes fueron frágiles y difíciles de mantener. Un desarrollador puede usar Page Objects con Selenium RC para hacer un conjunto de pruebas de IU mucho más fácil de mantener, y es una mejor opción cuando está disponible.

Esto no quiere decir que Selenium IDE no sea útil para su probador; sin embargo, la utilidad (y el potencial de dañar los esfuerzos de prueba en lugar de ayudar) depende en gran medida de qué tan fija sea la IU. Obtendrá sus mejores resultados con la grabación y reproducción si la interfaz de usuario se puede congelar temprano en el ciclo de desarrollo. Es posible que deba enseñarle al probador cómo obtener nuevos XPaths cuando los XPaths anteriores están rotos, y cómo saber si la prueba está fallando debido a un cambio en la interfaz de usuario (porque el XPath ya no es válido) o debido a un error de funcionalidad.

Creo que usar Selenium IDE es mejor que ninguna automatización para cualquier proyecto que tenga una interfaz de usuario generalmente estable. Ejecutar cientos de pruebas manuales en una interfaz de usuario estable cada vez que hay un cambio menor es una pérdida de tiempo real. Simplemente establezca las expectativas en consecuencia y tenga en cuenta que cambiar la interfaz de usuario tendrá un impacto significativamente mayor en el programa de control de calidad una vez que comience a usar la automatización de grabación y reproducción para esa interfaz de usuario. Su probador puede querer elegir y elegir las áreas que automatiza sabiamente.

No tuve problemas para entrenar a personas que no son de programación para escribir pruebas de Selenium con XPaths relativos en Java / JUnit. El programador lo configura y escribe una plantilla de prueba básica, el probador desarrolla más pruebas, grabándolas y luego ajustándolas. Si el probador necesita algo específico, le pide al programador que lo escriba. Tester necesita tener una comprensión realmente básica de HTML y XPath, y un poco de ayuda para adquirir Selenium API (así como el complemento Selenium para Firefox y Firebug).

Lo curioso es que al principio estaba considerando algo elegante como el pepino o algo similar, pero esta combinación de selenio / JUnit demostró ser lo suficientemente buena y simple. Curiosamente, los evaluadores sin experiencia previa en Java no tuvieron problemas serios al escribir pruebas JUnit. Lo único importante es que un programador experimentado configure la prueba, de modo que el probador básicamente solo necesita producir nuevas pruebas y llamar a los métodos Selenium.

Considere utilizar un marco de prueba basado en palabras clave. La idea es que los desarrolladores desarrollen palabras clave de alto nivel (o use las que vienen en una biblioteca), y el probador simplemente reúne estas palabras clave en casos de prueba de alto nivel.

Los equipos en los que he estado en los últimos años han logrado mucho kilometraje de este enfoque. Usamos el marco de robot pero hay otros como pepino (compatible con varios idiomas) y specflow (una implementación de pepino para .net)

Por ejemplo, al usar este enfoque, su probador podría escribir una prueba similar a esta:

| Login with valid credentials
| | Go to page | LoginPage
| | Login as a normal user
| | The current page should be | DashboardPage

Estas palabras clave podrían escribirse en Python (o Java, o un lenguaje .NET), de esta manera:

class LoginPage(PageObject):
    def login_as_a_normal_user(self):
        username = self.browser.find_element_by_id("username")
        username.send_keys(DEFAULT_USER)
        password = self.browser.find_element_by_id("password")
        password.send_keys(DEFAULT_PASSWORD)
        ... and so on...

Hay una biblioteca prefabricada para robots con palabras clave genéricas basadas en selenio ("ir a la página", "la página debe contener", "botón de clic", etc.) con la que el probador puede ser productivo de inmediato.

Muy a menudo, estas palabras clave genéricas son suficientes, pero usar el concepto de objetos de página y palabras clave específicas de la página es una forma poderosa de escribir pruebas. Sus desarrolladores pueden crear una clase para cada página de su aplicación, y para cada página pueden escribir palabras clave de propósito especial para que el evaluador pueda centrarse más en la función lógica de la página en lugar de la implementación física.

Aquí hay un par de publicaciones de blog que escribí que profundiza en el uso de objetos de página con el marco de robot:

• Robot Framework Page Page Objects
• Usar Mixins con objetos de página

Experiencia real de miembros del equipo no técnicos escribiendo código Selenium: no salió bien

Realmente tuvimos esta situación en la que tuvimos un miembro del equipo no técnico (en este caso, un SQA sin antecedentes de programación). Esto desafortunadamente no fue muy bien.

Graba y reproduce pruebas creadas que no se pueden mantener

Primero, nuestro equipo probó las herramientas de grabación y reproducción, pero como otros han dicho, las pruebas que genera son muy frágiles y difíciles de mantener. Nuestro SQA finalmente terminó cayendo en un patrón de solo volver a grabar una prueba cada vez que cambiaba, lo que no era realmente tan eficiente, especialmente cuando un cambio rompió la mayoría de nuestras pruebas (tuvimos un cambio en la página principal de nuestro sitio web que rompió alrededor de 60 % de nuestras pruebas).

Sin la ayuda de aquellos con experiencia en programación, el código escrito manualmente era horrendo

Escribimos nuestras pruebas de Selenium en Java y el SQA nunca había usado Java antes, por lo que lo estaba aprendiendo solo. Descubrimos que las pruebas terminaron usando algunas prácticas de programación realmente pobres:

• Usar variables públicas estáticas cuando realmente deberían haber sido variables de instancia privadas
• Tener bloques de código que no hicieron nada
• Un montón de Thread.sleep () en lugar de usar WebDriverWait porque no sabía cómo escribir condiciones personalizadas
• Pruebas unitarias realmente incómodas: vi bastantes assertTrue(false)líneas para terminar una prueba
• Pobres nombres de variables
• Suprimir las excepciones que deberían haberse manejado (o prevenido en primer lugar)
• Pruebas que pasaron sin importar la entrada que utilizó
• Algún código que nunca descubrimos y terminamos reescribiendo

Cuando llegué al equipo, el SQA original se había ido y la ejecución de cualquier prueba resultó en un montón de excepciones de consola que simplemente se nos dijo que ignoramos. Después de eso, terminamos involucrando a los desarrolladores y reescribiendo masivamente gran parte del código para que realmente funcione correctamente y sea mantenible y fácil de entender.

Si va a hacer que personas no técnicas escriban código Selenium, haga que una persona técnica los ayude

Creo que algunos de estos problemas podrían haberse evitado si tuviéramos a alguien técnico que viniera a ayudarlos. Si hubieran explicado por qué las variables estáticas públicas deberían ser variables de instancia privadas, o cómo funciona JUnit, o cómo usar WebDriverWait, o por qué dispersar Thread.sleep () en todas partes es malo, podríamos haber tenido un mejor código.

Pero tal como está, terminamos con un código que en última instancia no se podía mantener y, al final, simplemente reescribimos la mayor parte, lo que resultó en una gran pérdida de tiempo y dinero.