Pruebas de aceptación realizadas primero ... ¿cómo se puede lograr esto?

8

La esencia básica de la mayoría de los métodos ágiles es que una característica no se "hace" hasta que se haya desarrollado, probado y, en muchos casos, lanzado. Se supone que esto sucederá en períodos de tiempo de respuesta rápidos como "Sprints" en el proceso Scrum.

Una parte común de Agile también es TDD, que establece que las pruebas se realizan primero.

Mi equipo trabaja en un programa GUI que hace muchos dibujos específicos y demás. Para proporcionar pruebas, el equipo de pruebas debe poder trabajar con algo que al menos intente realizar las cosas que está tratando de probar. No hemos encontrado una solución a este problema.

Puedo ver de dónde provienen porque si estuviera tratando de escribir un software dirigido a una interfaz básicamente misteriosa, me resultaría muy difícil. Aunque tenemos un comportamiento bastante bien especificado, el proceso exacto de interactuar con varios elementos de la interfaz de usuario cuando se trata de la automatización parece ser demasiado exclusivo de una característica para permitir que los evaluadores escriban scripts automáticos para controlar algo que no existe. Incluso si pudiéramos, muchas cosas terminan apareciendo más tarde como faltantes en la especificación.

Una cosa que consideramos hacer era hacer que los evaluadores escribieran "guiones" de prueba que son más como un conjunto de pasos que deben realizarse, como se describe desde una perspectiva de caso de uso, para que puedan ser "automatizados" por un ser humano. Esto puede ser realizado por el desarrollador (s) escribiendo la característica y / o verificado por otra persona. Cuando los probadores más tarde tienen la oportunidad, automatizan el "guión" principalmente para propósitos de regresión. Sin embargo, esto no terminó siendo popular en el equipo.

La parte de prueba del equipo en realidad está quedando atrás de nosotros por bastante margen. Esta es una de las razones por las cuales el tiempo aparentemente extra de desarrollar un "guión" para que un ser humano lo ejecute simplemente no sucedió ... están bajo problemas para mantenerse al día con los desarrolladores. Si los esperáramos, no haríamos nada. Realmente no es su culpa, son un cuello de botella pero están haciendo lo que deberían y trabajando lo más rápido posible. El proceso en sí parece estar en contra de ellos.

Muy a menudo terminamos teniendo que retroceder un mes o más en lo que hemos hecho para corregir errores que los probadores finalmente han podido verificar. Es una verdad fea sobre la que me gustaría hacer algo.

Entonces, ¿qué hacen otros equipos para resolver esta cascada de fallas? ¿Cómo podemos adelantar a los evaluadores y cómo podemos lograr que realmente haya tiempo para que escriban pruebas de las características que hacemos en un sprint sin hacernos sentarnos y girar nuestros pulgares mientras tanto? Tal como está funcionando actualmente, para "hacer" una función, usando definiciones ágiles, sería hacer que los desarrolladores trabajen durante 1 semana, luego los probadores trabajen la segunda semana, y con suerte los desarrolladores puedan solucionar todos los errores que se les ocurran. en los últimos días Eso simplemente no va a suceder, incluso si estoy de acuerdo en que es una solución razonable. Necesito mejores ideas ...

— Edward extraño
fuente

7

primero, elimine la división entre 'probadores' y 'desarrolladores'. Todos prueban

segundo, en TDD, los desarrolladores codifican las pruebas antes de codificar la característica / historia

Lo que ha descrito no es TDD [aunque puede ser Scrum; Scrum es una metodología de gestión de proyectos independiente de la metodología de desarrollo; Scrum no es relevante para su problema]

Los escenarios donde las pruebas automatizadas son imposibles son extremadamente raros. Los escenarios donde las pruebas automatizadas son difíciles, costosas o inconvenientes son mucho más comunes, pero es precisamente en estos escenarios donde las pruebas automatizadas son más necesarias.

Por la vaga descripción, supongo que el software está dibujando algo en la pantalla. Si lo que se dibuja está determinado por datos, fórmulas o pasos funcionales, al menos escriba pruebas automatizadas que prueben el nivel de los datos / fórmulas / pasos funcionales. Si la salida de la pantalla es determinista (los mismos pasos dan como resultado la misma salida de dibujo cada vez), pruebe manualmente una vez, tome una captura de pantalla y permita que las pruebas futuras comparen la salida con la captura de pantalla verificada. Si el resultado de la pantalla no es determinista y no se rige por datos, fórmulas o pasos funcionales, entonces está en esa área rara donde las pruebas automatizadas pueden ser imposibles. Pero lo dudo.

Supongo que la única razón por la que las pruebas no se han automatizado hasta ahora es que a los desarrolladores no les importa . En TDD, los desarrolladores hacen las pruebas, por lo que sienten el dolor de la aburrida repetición de probar el mismo proceso de 62 pasos cien veces hasta que todos los errores hayan desaparecido. Nada obtendrá una solución de prueba automatizada desarrollada más rápido que hacer que los desarrolladores hagan la prueba.

— Steven A. Lowe
fuente

Estoy hablando específicamente de pruebas de aceptación, no de pruebas unitarias. En cualquier caso, no voy a tener la oportunidad de alterar la estructura departamental de la empresa. Necesita una solución que funcione tanto con desarrolladores como con "desarrolladores en prueba". Dicho esto, ¿cómo harías tu ejemplo de captura de pantalla antes de que hubiera algo para capturar? En realidad, hay MUCHAS pruebas automáticas que hacen esto, pero antes de que algo así pueda automatizarse, debe haber algo para tomar una captura de pantalla.

— Edward Strange el

@Crazy Eddie: TDD define pruebas para historias de usuarios que definen las características de la aplicación. La terminología de 'prueba unitaria' se usa a menudo en este contexto, pero no tiene el mismo significado limitado que tendría en una metodología puramente de prueba unitaria (donde la cobertura del código sería importante, por ejemplo). TDD prueba características y escala hasta el nivel de prueba de aceptación. El uso del término 'pruebas unitarias' en la literatura es un punto lamentable de confusión para muchas personas. En cuanto a la captura de pantalla, debe ejecutar la cosa con éxito una vez para que ese enfoque solo sea bueno para las pruebas de regresión.

— Steven A. Lowe

@Crazy Eddie: con un nombre como Crazy Eddie, espero que seas el campeón de desafiar ciclos de fracaso ineficaces e inútiles ;-) [sí, leí tu blog]. En serio, sin embargo, nada va a cambiar porque los desarrolladores no sienten dolor. Permítales sentir el dolor, o tal vez ofrézcales algún tipo de recompensa por ayudar, y encontrarán una solución para las pruebas automatizadas y / o comenzarán a escribir código que sea más fácil de probar.

— Steven A. Lowe

La diferencia que considero más importante desde mi perspectiva es que requieren diferentes áreas de especialización. Una prueba unitaria puede, y a menudo se escribe, en el mismo idioma que los bits de aplicación que prueban. Por otro lado, las pruebas de aceptación automatizadas hacen uso de cualquier idioma al que responda el software particular utilizado para controlar la IU. También requieren diferentes arquitecturas, ya que al menos nuestros probadores han desarrollado enormes bibliotecas de componentes reutilizables que se adaptan a necesidades específicas. Al igual que un equipo puede involucrar expertos en DB versus código, parece estar bien tener expertos en pruebas.

— Edward Strange

Supongo que esto resuelve el problema de mantener ocupados a los desarrolladores mientras se realizan las pruebas. Incluso si les toma más tiempo para cualquier tarea, podría valer la pena. Sin embargo, es muy posible que no obtenga la compra que necesito e imagino el problema de seguir resurgiendo hasta que podamos descubrir cómo escribir las pruebas con anticipación o al menos en sincronía. Todavía no veo ninguna forma de resolver este problema, ya que el requisito de tener algo allí para conducir parece ser un requisito previo del problema de automatización.

— Edward Strange

4

Mis equipos descubrieron que TDD no era adecuado para diseñar pruebas de GUI. Todos los marcos de prueba automatizados de nivel de GUI que usamos requerían que el código se escribiera antes de la prueba. Entonces cambiamos a Behavior Driven Development . Claro, las pruebas no están automatizadas, pero nos dieron una forma de medir si la IU estaba "terminada" desde el principio.

— Christopher Bibbs
fuente

3

Encontramos ATDD para la GUI difícil / costosa.

Usualmente hacemos primero el front-end. Dado que escribimos aplicaciones web, usualmente está en HTML / CSS / JS, y luego obtenemos la aprobación del aspecto, el flujo, etc. Estos eventualmente se traducirán en plantillas con las partes apropiadas reemplazadas por bits dinámicos.

Una vez que se completa la maqueta de la interfaz de usuario, escribimos pruebas que imitan una solicitud web. XPath se utiliza para afirmar que los datos existen en las etiquetas HTML correctas.

Encontramos que este estilo de prueba nos da un buen valor por el tiempo que pasamos. Todavía afirmamos que se devuelven los datos y alguna estructura general sobre el html. Como ya resolvimos el aspecto de antemano a través de la etapa de maqueta, no nos preocupamos de intentar afirmar la colocación de píxeles. Solo miramos la página a medida que desarrollamos tanto como parte del desarrollo como también una doble verificación.

Para la interfaz gráfica de usuario no web, probablemente intente agregar algunos ganchos para que el front-end sea programable. Probablemente también haría una maqueta de la interfaz de usuario primero, incluso en papel.

— dietbuddha
fuente

1

 > Acceptance tests done first…how can this be accomplished?

Prefiero un estilo de desarrollo bdd-tdd como se describe en este artículo: Desarrollo basado en comportamiento con SpecFlow y WatiN .

El ejemplo utiliza .net para el desarrollo con SpecFlow + NUnit + WaitN. Si está desarrollando con (j) ruby / java, puede probar pepino + junit + waitr

— k3b
fuente

1

Una cosa que consideramos hacer era hacer que los evaluadores escribieran "guiones" de prueba que son más como un conjunto de pasos que deben realizarse, como se describe desde una perspectiva de caso de uso, para que puedan ser "automatizados" por un ser humano. Esto puede ser realizado por el desarrollador (s) escribiendo la característica y / o verificado por otra persona. Cuando los probadores más tarde tienen la oportunidad, automatizan el "guión" principalmente para propósitos de regresión. Sin embargo, esto no terminó siendo popular en el equipo.

Esto es más o menos lo que hacemos. Cada característica se desarrolla en paralelo con el caso de prueba (secuencia de comandos) y ninguna característica se 'realiza' hasta que se realizan los tres pasos: desarrollo, caso de prueba y prueba. Todos los casos de prueba se escriben a partir de los requisitos de los probadores y se verifican con los desarrolladores, por lo que todos tenemos una comprensión común del problema. Al igual que su sugerencia 'cada dos semanas', excepto que cuando los desarrolladores están trabajando en la función los probadores están trabajando en casos de prueba y cuando los probadores están probando los desarrolladores están investigando la próxima función.

Creo que el mayor problema que tienes es que

[l] a prueba de parte del equipo se está quedando atrás de nosotros por bastante margen. [...] Si los esperáramos, no haríamos nada

Como el equipo de prueba está tan lejos, realmente creo que deberías esperarlos. Estoy seguro de que hay algo productivo que podría hacer, como desarrollar algunas características que son fáciles de probar pero que lleva mucho tiempo desarrollar. También puede ayudar a tener en cuenta el tiempo de prueba al planear un sprint, ni los desarrolladores ni los evaluadores deben estar sobrecargados o inactivos.

— Paula
fuente

1

El desarrollo basado en pruebas de aceptación (distinto de, pero complementario al desarrollo basado en pruebas) es una excelente manera de garantizar que tenga los requisitos establecidos antes de comenzar a codificar.

En mi equipo, nosotros (propietarios del producto, analistas de control de calidad y desarrolladores) nos sentamos juntos y usamos dos pruebas de aceptación de escritura de FitNesse . Estas sesiones generalmente son impulsadas por el control de calidad, pero todos participamos. Estos no se ejecutarán de inmediato ya que se necesita un esfuerzo de desarrollo para agregar los accesorios (el pegamento entre las páginas wiki y el código de producción). Estas pruebas forman los criterios de aceptación de una historia . FitNesse está diseñado para interactuar con la capa debajo de la interfaz de usuario.

Como desarrolladores, trabajamos para que estas pruebas de aceptación pasen. Usamos TDD para esto, pero TDD no debe confundirse con ATDD.

Una vez que las páginas de FitNesse se vuelven verdes, casi hemos terminado, todavía tenemos trabajo por hacer (pruebas exploratorias, generalmente dirigidas por QA, etc.).

— Johnsyweb
fuente

Veo cómo las pruebas unitarias y las pruebas de aceptación no deben confundirse. No es que el tío Bob sea un dios, pero en "Principios, patrones y prácticas ágiles en C #" incluye pruebas de aceptación (y usa FitNesse) como parte de TDD y no hace una distinción y ni siquiera menciona ATDD.

— JeffO

0

Quizás escribir pruebas de IU codificadas puede ayudarlo. Si está trabajando con Visual Studio 2010, puede usar un complemento llamado "prueba de interfaz de usuario codificada" para grabar y codificar un script muy específico para interactuar con la interfaz de usuario de su aplicación. Grabar una interacción en un guión introduce un nivel adicional de abstracción que te protege contra pequeños cambios en la interfaz de usuario. Sin embargo, la introducción de esta forma de prueba también introduce la carga de mantener las pruebas.

— Carlo Kuip
fuente