Las descripciones clásicas de desarrollo ágil tienen código liberable al final de una iteración. Si hay más pruebas y validaciones para crear un producto liberable, ¿cómo se integra eso en el proceso?¿Cómo se integran las pruebas del sistema en un proceso ágil?
¿Qué le impide hacer su propio proceso? Si encuentras algo que puede ser mejor ... solo hazlo. Si funciona, persevera con ello ... si no, prueba con otra cosa. No hay un proceso establecido si quieres agilidad.
El término que se usa con más frecuencia es 'que se puede enviar' al final de cada iteración. Lo que significa que puede dárselo al usuario final (como un grupo de archivos DLL para copiar un recurso compartido o entregar personalmente un CD/DVD) y obtendrá valor de su uso. Dicho código ha superado todas las pruebas unitarias (desarrolladores) y las pruebas de aceptación (clientes/QA/Analysts) que se consideraron necesarias para que se "HECHO". Las pruebas de aceptación son simulaciones de escenarios de clientes de extremo a extremo.
no estoy seguro de lo que quiere decir con 'más pruebas y validación' .. No puedo pensar en otras actividades de pre-lanzamiento '
Usted acaba de apilarlo al final de su último punto final de iteración (Si usted es particularmente pesimista como yo ... tome promedios históricos ... si lo lanza temprano. ¡Sí!) Entonces, si el negocio ha decidido que La iteración n. ° 14 delimita un buen conjunto de características que pueden ser una versión. Es solo 'Agregar n semanas' después del final de la iteración n. ° 14. No hay matemática compleja o incertidumbre en ese punto. El punto clave es que si ha estado involucrando regularmente a las partes interesadas/clientes, incorporando comentarios y manteniendo un nivel aceptable de calidad, no debería haber sorpresas de último minuto.
Si es necesario, puede incluso hacer un inicio rotativo .. es decir, el equipo de entrenamiento comienza a trabajar cuando el equipo de desarrollo entra en la iteración n. ° 13. Eso les da un mes suponiendo una iteración de 2 semanas ... y con suerte no tendrías muchas funciones ingresando en la última iteración ... Así que en un máximo de 2 semanas después de la iteración # 14 y sujeto a todas las alineaciones celestes/organizacionales, deberías estar tener un lanzamiento y un merecido descanso.
Las pruebas automatizadas después de cada compilación automatizada le permiten al menos una parte del camino.
En segundo lugar, utilizo Build Events para pruebas y documentación. –
Agregue las pruebas del sistema a su retraso acumulado (en Scrum) o su equivalente.
Según la misma documentación del usuario.
La ejecución de las pruebas del sistema suele ser demasiado lenta para integrarse estrechamente en el desarrollo ágil. (Hay excepciones a esto, por ejemplo, un juego bien diseñado de pruebas de navegador puede ejecutarse no mucho más lento que las pruebas unitarias típicas).
Una forma de integración es tener una compilación de una noche o continua, que se ejecuta todo el tiempo, y puede llevar varias horas construir y ejecutar todas las pruebas. Si una compilación supera todas las pruebas (pruebas unitarias + pruebas del sistema), se puede liberar, puede entregar ese código binario o la instantánea del código fuente.La idea es tener x versiones de tus binarios/instantáneas de código, verificarlas de forma asincrónica y entregar las compilaciones verdes. Esto debería funcionar tanto con pruebas automáticas del sistema como manuales.
Primero reconozca que el ancho/ancho de la prueba que habla de aumenta a medida que avanza el proyecto y el software gana alcance y/o complejidad. Intentar poner este esfuerzo en una iteración no funciona después de una o dos iteraciones debido a esto. La regla de sentirse bien para las iteraciones es un nivel constante de trabajo en cada una, según lo determinado por la velocidad del proyecto.
Las soluciones a esto entonces pueden tomar uno de dos caminos: con o sin automatización. La automatización en los niveles de prueba más altos reduciría el esfuerzo para ejecutar las pruebas, haciendo que el trabajo se ajuste nuevamente a la iteración, ya que cada iteración solo se enfocaría en el aumento incremental del alcance/complejidad. Esto no siempre se puede lograr en todos los contextos del proyecto, incluso si eso es lo que queremos. La sobrevaloración de la automatización de pruebas de alto nivel es una trampa que debe tomarse en serio, en otras palabras, evitar subestimar lo que un examinador exploratorio razonablemente experimentado trae a la mesa.
Sin automatización, el problema cambia a uno basado en la administración de pruebas. Las iteraciones de prueba paralelas y desplazadas en el tiempo son una solución candidata. Por ejemplo, puede optar por establecer una acumulación de pruebas para las tareas de prueba del sistema que se gestiona con la misma cadencia que las iteraciones de desarrollo, pero se retrasa, o se desplaza en el tiempo, hasta en una duración de iteración completa. Esto permite que los probadores trabajen holísticamente en las nuevas versiones en su propia caja de arena y en sus propias prioridades.
Yo recomendaría que los atascos de la iteración de prueba se construyan en colaboración con los desarrolladores, como me gustaría que los atascos de iteración de los desarrolladores se construyan en colaboración con los evaluadores. También recomendaría un equipo de prueba que tenga experiencia en automatización para que puedan automatizar el tedio y trabajar de una manera más exploratoria. Su cartera de pruebas automatizadas debería aumentar con cada iteración. También deberían tener acceso a pruebas de unidades de desarrollador y poder ejecutarlas en lanzamientos en el entorno limitado de pruebas.
Trabajar desfasado de esta forma no hace que desaparezca el creciente problema de alcance/complejidad de la prueba, pero proporciona un mecanismo para gestionar esa complejidad ya que el equipo crea elementos atrasados, ajusta prioridades, automatiza algunos, crea listas de verificación, etc. basadas en lo que colectivamente piensan que deben hacer a continuación. Lo más probable es que golpeen los artículos grandes.
Preservando la capacidad de los evaluadores para trabajar de manera integral y para desarrollar su comprensión y compartir sus conocimientos sobre el sistema a través de pruebas automatizadas, todos parecen valer la pena.
Trabajé con un proceso de lanzamiento que requería una prueba de esfuerzo prolongada de un producto de alta confiabilidad. Las pruebas de estrés incluyeron grandes volúmenes de datos y múltiples condiciones de error superpuestas. La prueba de estrés funcionaría durante varios días. Ese era el tipo de "pruebas adicionales" en las que estaba pensando. – Rachel
parece una falta de respuesta – BillR