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 ...
fuente
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.
fuente
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.
fuente
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
fuente
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
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.
fuente
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.).
fuente
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.
fuente