¿Quién escribe las pruebas de interfaz de usuario automatizados? Desarrolladores o probadores?

Question

Estamos en las etapas iniciales de un proyecto grande, y hemos decidido que algún tipo de prueba automatizado interfaz de usuario es probable que va a ser útil para nosotros, pero aún no se han resuelto exactamente cómo se va a trabajar ...

El objetivo principal es la de automatizar una instalación básica y de gestión a través de la aplicación, por lo que si un desarrollador provoca una rotura importante (por ejemplo: aplicación no se instalará, la red no se conecta, la ventana no se pantalla, etc) los probadores no tiene que perder su tiempo (y se molesta por) instalación y configuración de una acumulación roto

El segundo objetivo es ayudar a los probadores cuando se trata de tareas repetitivas.

Mi pregunta es: ¿Quién debe crear este tipo de pruebas? El supuesto implícito en nuestro equipo ha sido que los probadores lo harán, pero todo lo que he leído en la red siempre parece dar a entender que los desarrolladores crearán ellos, como una especie de 'prueba de unidad extendida'.

Algunas ideas:

• Los desarrolladores parecen estar en una posición mucho mejor para hacer esto, ya que saben controlar de identificación, clases, etc., y tienen una imagen mucho mejor de cómo la aplicación está funcionando

• Los probadores tienen la ventaja de no saber cómo la aplicación está funcionando, y por lo tanto puede producir pruebas que pueden ser mucho más útil

• He escrito algunos guiones iniciales usando IronRuby y White . Esto ha funcionado muy bien, y es lo suficientemente potente como para hacer literalmente cualquier cosa, pero entonces usted necesita para ser capaz de escribir código para escribir las pruebas de interfaz de usuario

• Todas las herramientas de prueba de interfaz de usuario automatizados que hemos probado (TestComplete, etc.) parecen ser muy complejo y frágil, y mientras los probadores pueden utilizarlas, que tardan alrededor de 100 veces más y que están en constante corriendo en "la complejidad accidental" causado por las herramientas de prueba de interfaz de usuario.

• Nuestros probadores no puede codificar, y mientras están montón inteligente, todo lo que conseguí eran divertidas parece cuando me sugirió que los probadores potencialmente podrían escribir scripts simples rubí (a pesar de que dijeron guiones son aproximadamente 100 veces más fácil de leer y escribir que el lío mutilado de botones y DataGrids que parece ser la norma para las herramientas de prueba de interfaz de usuario automatizados).

Me realmente aprecio ninguna respuesta de otros que han tratado de automatización de la interfaz de usuario en un equipo de desarrolladores y probadores. Lo que hizo, y no funciona bien? Gracias de antemano!

Editar La aplicación en cuestión es una aplicación "rich client" C # WPF que se conecta a un servidor utilizando WCF

Answer 1

Lo ideal sería que en realidad debería ser de control de calidad que terminan escribiendo las pruebas. El problema de usar una solución programática es la curva de aprendizaje involucrados en conseguir la gente de control de calidad a la velocidad con el uso de la herramienta. Los desarrolladores sin duda puede ayudar con esta curva de aprendizaje y ayudar al proceso de tutoría, pero se necesita tiempo y es un lastre para el desarrollo.

La alternativa es utilizar una herramienta de interfaz gráfica de usuario simple que realiza una copia de una lengua (y guiones de datos) y permite control de calidad para los scripts de creación visual, de ahondar en los detalles más finos de la lengua sólo cuando es realmente necesario - el desarrollo también puede participar aquí también.

Los intentos más exitosos que he visto han sido definitivamente con este último, pero configurar esto es la parte difícil. El selenio ha funcionado bien para las aplicaciones web sencillas y simples hilos a través de la aplicación. JMeter también (para conversaciones web de secuencias de comandos para servicios web) ha funcionado bien ... Otra opción que es la de casa construida en el instrumento de prueba - una herramienta simple a través de la parte superior de un lenguaje de script (maravilloso, Python, Ruby) que permite al control de calidad poner los datos de prueba en la aplicación, ya sea a través de una interfaz gráfica de usuario oa través de archivos de datos. Los archivos de datos pueden ser simples archivos de propiedades, o en casos más complejos estructurados (algo así como YAML o incluso Excel) archivos de datos. De esa manera pueden construir las pruebas de humo básicos para empezar, y luego ampliar esto en varias pruebas de escenarios impulsada.

Por último ... Creo ricas aplicaciones cliente son mucho más difíciles de probar de esta manera, pero depende de la naturaleza del lenguaje y las herramientas disponibles para usted ...

Answer 2

En mi experiencia, los probadores que pueden cambiar de trabajo código será un aumento de sueldo como desarrolladores.

Estoy de acuerdo con usted en las herramientas automatizadas de pruebas de interfaz de usuario. Cada lugar que he trabajado que era lo suficientemente ricos para pagar WinRunner o LoadRunner no podía permitirse el personal que realmente se utilicen. Los precios pueden haber cambiado, pero en aquel entonces, éstos estaban en el alto de 5 dígitos para etiquetas de precio bajo de 6 dígitos (pensar en el precio de un piso piloto). Los productos eran difíciles de usar, y por lo general se mantienen desinstalan en un gabinete cerrado porque todo el mundo tenía miedo de meterse en problemas por romperlas.

Answer 3

He trabajado durante 7 años como desarrollador de aplicaciones antes de que finalmente cambié a las pruebas y la automatización de pruebas. La prueba es mucho más difícil que la codificación y automatización de cualquier desarrollador que quiera tener éxito debe dominar las habilidades de prueba.

Hace tiempo que puse mis pensamientos en matrices de habilidad en un par de entradas de blog.

Si está interesado por discutir:

http://automation-beyond.com/ 2009/05/28 / qa-automatización de habilidades matrices /

Gracias.

Answer 4

Creo que tener los desarrolladores a escribir las pruebas será de la mayor utilidad. De esta manera, se puede obtener "rotura de comprobación" a lo largo de su ciclo de dev, no sólo al final. Si todas las noches automatizado construye, se puede tomar y corregir errores cuando son pequeños, antes de que se conviertan en grandes errores, medias, devoradores de hombres.

Answer 5

¿Qué hay de los probadores que proponen las pruebas, y los desarrolladores escribir realmente él?

Answer 6

Creo que en un primer momento que depende en gran medida de las herramientas que utiliza.

Nuestra empresa utiliza actualmente selenio (Somos una tienda de Java).

La IDE de selenio (que registra las acciones en Firefox) funciona bien, pero los desarrolladores necesitan para corregir errores de forma manual se hace en contra de nuestras aplicaciones web, así que no es realmente apropiado para control de calidad para escribir pruebas con.

Una cosa que he intentado en el pasado (con cierto éxito), fue escribir funciones de biblioteca como contenedores para las funciones de selenio. Su texto es el llano Inglés:

selenium.clickButton("Button Text")

... pero detrás de las escenas para comprobar la disposición y etiquetas en el botón adecuado, tiene un id, etc.

Desafortunadamente esto requiere una gran cantidad de configurar para permitir la escritura fácil de pruebas.

Hace poco me di cuenta de una herramienta llamada Gira (de ThoughtWorks, construida sobre el motor Eclipse), que es un contenedor de selenio, lo que permite las pruebas de estilo Inglés de civil que se escribirá. Tengo la esperanza de ser capaz de suministrar esto a los probadores, que pueden escribir simples afirmaciones en la llanura Inglés!

Se crea automáticamente talones para nuevas afirmaciones también, por lo que los probadores podrían escribir las pruebas, y pasarlos a los desarrolladores si necesitan nuevo código.

Answer 7

He encontrado la opción más razonable es tener suficientes características tales que la gente de control de calidad pueden apagar la prueba, básicamente averiguar lo que quieren poner a prueba en cada 'pantalla' o en cada componente, resguardo y aquellos a cabo. Los talones deben ser nombrados de tal manera que son muy descriptiva en cuanto a lo que están probando. Esto también ofrece una manera de cristalizar requisitos funcionales. De hecho, hacerlo con los requisitos de esta manera son particularmente fácil, y ayudan a las personas no técnicas realmente funcionan a través de las aguas fangosas de su propio proceso de embargo.

El talones puede ser llenado a través de una combinación de personas de QA / dev. Esto le permite entrenar BARATO la gente de control de calidad en cuanto a cómo escribir pruebas, y por lo general sorber hacia arriba, ya que favorece su seguridad laboral.

Answer 8

Creo que depende principalmente del nivel de su equipo de pruebas, las herramientas disponibles y la cultura del equipo con respecto a cómo los desarrolladores y probadores interactúan entre sí. Mi situación actual es que tenemos un equipo de prueba relativamente técnica. Se espera que todos los probadores de tener habilidades de desarrollo. En nuestro caso, los probadores escriben UI Automation. Si su equipo de pruebas no tiene esas habilidades no van a ser establecido para el éxito. En ese caso, puede que sea mejor para los desarrolladores que escriben la automatización de la interfaz de usuario.

Otros factores a tener en cuenta:

¿Qué otras tareas de prueba están en la placa de los probadores? Quiénes son sus clientes y cuáles son sus expectativas relacionadas con la calidad? ¿Cuál es el nivel de habilidad del equipo de desarrollo y cuál es su voluntad de asumir el trabajo de automatización de pruebas?

-Ron