Cómo ajustar pruebas en Scrum sprints y cómo escribir historias de usuarios en Scrum

Si las pruebas están separadas del desarrollo, tiene dos equipos de scrum separados. Es una mala idea tener una mano trabajando para la otra.

Sus desarrolladores deben escribir sus propias pruebas, por separado de este otro equipo. Debe tratar a este otro equipo de "prueba" como sus clientes.

  

En un sprint ... ¿cuándo se lanza para la prueba?

Cuando termine el sprint. Totalmente hecho Eso significa que has hecho tu propia prueba de unidad y estás seguro de que funciona. Una vez que haya finalizado su equipo de desarrollo, lo libera a otros equipos para "probar" o "implementar" o cualquier otra cosa que suceda en la organización.

  

Supongo que mi pregunta es cómo escribir historias que sean implementables y comprobables.

Eso varía de un equipo a otro. El BA es parte del equipo de desarrollo. Tienes que trabajar en eso como un equipo (desarrolladores BA más) para obtener la cantidad correcta de detalles. Es un esfuerzo de equipo para obtener la información correcta de BA para el resto del equipo.

  

¿Qué tan importante es tener pruebas automáticas de IU para Scrum?

Esencial. Completamente requerido para cualquier desarrollo de interfaz de usuario. Los desarrolladores deben realizar todas las pruebas por sí mismos antes que se entreguen al "equipo de prueba". Si hay una interfaz de usuario, deben probarlo. Si no hay una interfaz de usuario, no se requieren pruebas automatizadas de la interfaz de usuario. Se requiere una prueba, y una UI debe ser probada. Las pruebas automatizadas son la mejor práctica actual.

Línea inferior. Un equipo de "prueba" y una licenciatura que escriben cada pequeño detalle no es una organización óptima para Scrum. Scrum significa que tiene que repensar su organización y sus procesos.

La mayoría de las respuestas que voy a dar están relacionadas con un método Agile de desarrollo de software versus un método de cascada iterativa. Scrum simplemente es una implementación Agile popular.

1. En Scrum típico, no hay una fase de prueba separada, ya que la prueba formal debe realizarse durante todo el sprint. Cuando un desarrollador termina una historia de usuario, el recurso de control de calidad ya debe tener sus casos de prueba preparados y comenzar a probar en ese momento. Si sus casos de prueba pasan, aceptan la historia del usuario y pasan a la siguiente. Una vez que todas las Historias de usuario se hayan completado y aceptado, el sprint habrá terminado y comenzarás la siguiente. Todo esto depende, por supuesto, de la integración continua, por lo que los cambios de desarrollo están inmediatamente disponibles para el control de calidad. El desarrollo adicional debe seguir las pautas de TDD para garantizar que las pruebas de regresión sean lo más rápidas y sencillas posible.

2. Es una buena idea que los licenciados escriban historias de usuarios, pero para un control más detallado y específico, las historias de usuarios pueden acompañar documentos formales de requisitos. La historia del usuario debe escribirse desde la perspectiva de un solo usuario por rol. Expresa una necesidad desde el punto de vista del usuario, por lo que, naturalmente, si el software satisface actualmente todos los aspectos de esa necesidad, entonces se cumple la historia del usuario. Las historias de usuario pueden estar compuestas de historias de usuario secundarias y tareas asignables. Puede haber superposición de tareas para múltiples historias de usuarios.

3. Las pruebas automatizadas de UI pueden ser una buena cosa, pero personalmente creo que es más importante un mayor esfuerzo en los métodos TDD y una cobertura de pruebas unitarias del 100% de toda la lógica empresarial. Parece que la mayoría de los equipos de desarrollo de software no logran una cobertura del 100% de la lógica empresarial, por lo que, en mi opinión, las pruebas automatizadas de UI serían una pérdida de tiempo valioso que podría usarse para escribir más pruebas unitarias para BL. Es un lujo que no es una necesidad en mi opinión.

1. En Scrum, se supone que debes producir un incremento de software potencialmente enviable al final de cada sprint. Como resultado, Scrum promueve el concepto de equipo completo o equipo multifuncional en el que cada habilidad requerida para dirigir una historia de usuario determinada debe estar presente en el equipo.

   En mi proyecto actual, ya que una historia completamente probada es parte de nuestra definición de hecho, tenemos evaluadores integrados en los equipos. Durante los primeros días de un sprint, mientras los desarrolladores comienzan a trabajar en las primeras historias de usuario, los evaluadores prepararán escenarios de prueba y configurarán algunos datos de prueba. Tan pronto como finalice el desarrollo de una de las historias de usuario, lo probarán.

2. Esta es una de las mayores dificultades en Scrum IMO. Debe encontrar la cantidad correcta de especificación necesaria para obtener una historia de usuario comprobable e implementable. Demasiado análisis inicial, documentación y especificación resultarán en un plan rígido que inevitablemente resultará incorrecto en el transcurso del sprint. A la inversa, una historia de usuario que no haya sido claramente definida y expresada por el Propietario del Producto conducirá a un ancho de banda de comunicación saturado entre los desarrolladores y el PO durante el Sprint y retrasos en el desarrollo, mientras que el PO toma decisiones sobre las historias de usuario a mitad del sprint. .

   En nuestro caso, hemos definido la cantidad correcta de detalles para que una historia de usuario sea 1 / una descripción en la forma de "como ... quiero ... para que ..." y 2 / a Serie de criterios de aceptación. Rara vez realizamos simulaciones de la interfaz de usuario de antemano, puede suceder durante las planificaciones de velocidad, pero son más bocetos que se descartan posteriormente.

3. En mi experiencia, las pruebas automatizadas de UI requieren mucho tiempo y son extremadamente frágiles. Hay formas para hacer eso en WPF, pero ponderaría cuidadosamente el costo de mantenimiento de tales pruebas con los beneficios antes de ir de esa manera.

Trabajar en iteraciones cada vez más cortas hace que todas estas transferencias sean cada vez más caras. Puedes reducir estos costos siguiendo una regla estúpida y simple: reduce el tamaño de los lotes a la mitad, cambia la forma en que trabajas para que sea cómodo, repítelo hasta que esté satisfecho.

Toma tu ejemplo de sprint de 5 pisos. Si sus equipos están acostumbrados a escribir el código para las 5 historias y luego probar las 5 historias, entonces el tamaño del lote es de 5 historias. Cortar eso por la mitad. En el próximo sprint, trabaje primero en las 3 historias más urgentes, preparándolas para la prueba tan pronto como sea posible. Mientras los evaluadores prueban esas 3 historias, el resto puede preparar las 2 historias restantes para la prueba. Esto causará algunos dolores de crecimiento. Cambia cómo trabajas para que esto sea más cómodo.

  

Por ejemplo, más personas trabajarán juntas en cada historia, así que intente más emparejamiento y vea si eso le ayuda a trabajar de manera más constante. O, tal vez, los evaluadores encontrarán problemas en la historia 2 que distrae a algunos programadores mientras intentan trabajar en la historia 5, así que aliente a los programadores y evaluadores a que hagan un seguimiento antes de cómo probar una de las historias en el "primer lote". "de modo que es menos probable que los programadores cometan un error que un probador pueda detectar fácilmente con una prueba.

Es posible que se necesiten algunos pasos para resolver los grandes problemas asociados con los evaluadores que prueban un pequeño lote de historias mientras los programadores trabajan en el siguiente grupo de historias. Una vez que se sienta cómodo, corte el tamaño del lote nuevamente a la mitad. Y otra vez. Dentro de aproximadamente un año, el equipo estará probando historias con comodidad, ya que los programadores creen que han terminado con ellos y probablemente cometiendo menos errores en el camino. Cada historia se hará antes.

Por supuesto, en este punto, ahora puede hacer lo mismo con los lotes que el equipo recibe de los propietarios del producto, o que el equipo envía a la organización de operaciones. Y así. En este punto, puede abordar "¿cuántos detalles deben escribir los licenciados para las historias?" problema.

Por cierto: para que los evaluadores puedan reducir su tiempo de respuesta, tendrán que adoptar cierta automatización, mediante una combinación de aprendizaje de automatización y programadores que los ayuden a automatizar. A medida que intente reducir el tamaño del lote, descubrirá cuándo necesita solucionar esos problemas. No agregue automatización solo porque un libro dice que lo necesita.

Espero que te ayude.

Solo quiero compartir algunas experiencias como se muestra a continuación, espero que te sea útil.

  

En un sprint con, por ejemplo, 5 historias, ¿cuándo se lanza para las pruebas? Es tan pronto como una historia se completa con el desarrollo o después de que todas las historias se completan, pero antes del final del sprint, dale a la prueba el tiempo requerido para realizar la prueba.

Para cada historia de usuario grande, se debe desglosar en muchas tareas secundarias y cuando el desarrollador realiza las tareas secundarias por completo, deben enviarse a control de calidad para que se realicen las pruebas de inmediato. El defecto debe solucionarse después de la prueba para que las sub-tareas terminen la prueba.

  

Si el BA escribe historias de usuario, ¿cuál debería ser el detalle? Tradicionalmente, lleva mucho tiempo escribir una especificación con todo el diseño de la interfaz de usuario, el comportamiento, el texto, etc., para finalizar. Supongo que mi pregunta es cómo escribir historias que sean implementables y comprobables.

En Scrum, las historias de usuario deben estar en cualquier formato siempre que las conversaciones que rodean las historias ocurran y no se espere que se completen o sean estáticas. Una pequeña historia, llamada simplemente una historia de usuario, es una que se comprende bien y se puede implementar dentro de un sprint.  La prioridad de una historia se puede basar en el ROI, el valor comercial o cualquier otra cosa que el usuario acepte es importante. Se trata de actividades por PO.

  

Nuestro equipo de pruebas no es técnico. Qué importante es tener pruebas de interfaz de usuario automatizadas para Scrum. La interfaz de usuario se basa en WPF

Aplicar las pruebas de automatización en Scrum es una actividad bastante difícil. Debido a que todas las funciones se implementan de forma incompleta y no realmente estable, el control de calidad puede implementar el caso de prueba mediante alguna herramienta de prueba automática. Se debe hacer para un sprint llamado: regresión.