¿Cómo se integran las Pruebas en un proceso Scrum? [duplicar]

  

pero la empresa quiere saber cuándo están completas las historias de los usuarios

No se hace hasta que su cliente diga que está hecho: cualquier otra definición de "hecho" es ilusoria. Las pruebas de aceptación del usuario son los criterios de éxito para una historia de usuario: es por eso que se llaman "historias de usuario" y no "historias de administración".

Por lo general, la definición de hecho incluye más de lo que está incluyendo, como pruebas de integración, pruebas de aceptación y documentación (tanto para desarrolladores como para usuarios). Una vez que pasan las pruebas unitarias, puede integrar la nueva característica / componentes y ejecutar pruebas de integración. Una vez que la función está integrada, se ejecutan las pruebas de aceptación. Una vez que pasan las pruebas de aceptación, puede asegurarse de que toda la documentación refleje cualquier cambio reciente y la función esté completa. Un problema es que las pruebas de aceptación no deben ser una prioridad para un lanzamiento, sino una prioridad para verificar y validar la finalización de una historia.

En lo que respecta a la estimación, su estimación debe incluir todo, desde la validación de la historia del usuario hasta las pruebas de aceptación. Si no tiene en cuenta todas las actividades y tareas necesarias para completar, integrar, verificar y validar completamente la historia del usuario, la estimación no agrega tanto valor. Puede ser una función bastante simple de crear y probar, pero increíblemente difícil de integrar con su diseño actual, lo que significa que otras características deben volver a probarse y volver a probarse. No tener en cuenta esto significa que su seguimiento de velocidad estará desactivado.

Recomiendo sentarse con los usuarios o la administración apropiada y repasar este tema con mucho más detalle. El desarrollo de software profesional significa que realiza pruebas, incluso para historias de usuarios.

Tienes que hacer de esto una prioridad. Siempre es más fácil no abordar el problema y seguir escribiendo más código y ofreciendo más funcionalidad. Sin embargo, este no es el software que cuenta, y se puede contar con él, si parte del proceso de control de calidad no funciona.

Centrarse en el proceso y los beneficios a largo plazo. "Cambiar el aceite lleva tiempo", pero no lo postergas para siempre o de repente, ¡un día, obtienes una desagradable sorpresa! Así que programa el mantenimiento, las pruebas, como parte del proceso de desarrollo de software. Ya que está intentando cambiar un sistema existente, recomendaría hacer esto un poco más formal inicialmente para que el proceso continúe. Concéntrese en los beneficios (a la gente le gusta escuchar) en lugar de los problemas actuales (la gente se pone a la defensiva y pregunta).

Si la organización no comprende completamente el desarrollo de software profesional, puede educarlos o buscar otro lugar que lo haga.

Lo único que "RECOMIENDO" haría es implementar pruebas automatizadas. Por ejemplo; Si está probando cosas en Windows Forms o C # o WPF, use White.Core para las pruebas. Esto le permitirá probar nuevas implementaciones, compilaciones y características lo más rápido posible.

Trabajo como ingeniero de automatización y uso White.Core en C ++ / C # mientras pruebo las GUIs para verificar las correcciones de desarrollo antes de que termine una iteración.

La desconexión entre los diferentes estados de hecho generalmente es una fabricación de la gestión de proyectos que desea desesperadamente creer que los desarrolladores pueden entregar completamente el código a recursos no relacionados con el proyecto para UAT y seguir adelante.

Esto no es Scrum. Esto no es ágil. Este es un anti-patrón ágil.

Solo hay un estado de "hecho" para una historia de usuario determinada y es Aceptado . Un sprint se NO finaliza hasta que cada historia de usuario asignada en el sprint se haya eliminado del alcance de ese sprint o se haya aceptado.

Ahora un desarrollador puede ser Completo con una historia de usuario, lo que significa que está listo para la UAT, pero realmente no está descolgado hasta que la historia de usuario haya sido aceptada debido a una serie de problemas. ser encontrado durante la UAT que el desarrollador debe abordar antes del final del sprint.

Todas las fases de diseño, documentación, implementación y todos los tipos de pruebas deben tenerse en cuenta al estimar una historia de usuario. El control de calidad o la entidad que debe realizar la UAT debe ser un recurso del proyecto durante la planificación del sprint.