¿Cómo se integran las pruebas del sistema en un proceso ágil?[cerrado]

Question

Las descripciones clásicas del desarrollo ágil tienen código liberable al final de una iteración.Si es necesario realizar más pruebas y validaciones para crear un producto lanzable, ¿cómo se integra eso en el proceso?

Answer 1

¿Qué te impide hacer tu propio proceso?Si encuentras algo puede ser mejor...hazlo.Si funciona, persevera con ello...si no, prueba con otra cosa.No existe un proceso fijo si desea agilidad.
El término que se utiliza con más frecuencia es 'enviable'código al final de cada iteración.Lo que significa que puede entregárselo al usuario final (como un conjunto de archivos DLL para copiar un recurso compartido o entregarle personalmente un CD/DVD) y él obtendrá valor al usarlo.tal código ha pasado todas las pruebas unitarias (desarrolladores) y pruebas de aceptación (clientes/QA/Analistas) que se consideraron necesarios para que estuviera "hecho!" Las pruebas de aceptación son simulaciones de escenarios para el cliente de extremo a extremo.

No estoy seguro de lo que quiere decir con "más pruebas y validaciones".Puedo pensar en otras actividades 'previas al lanzamiento'.

• ciertas actividades como “Conferencias de Capacitación” y creación de contenidos relacionados.
• Demostraciones o implementaciones en sitios Beta durante un mes antes del lanzamiento si las implementaciones de los clientes son raras o no es posible realizarlas con frecuencia.
• Clientes potenciales / Expertos / Servicios obteniendo un adelanto práctico del nuevo producto del que han estado escuchando.

Simplemente lo apilas al final del punto final de tu última iteración (si eres particularmente pesimista como yo...tome promedios historicos..si liberas temprano.¡Sí!) Entonces, si la empresa ha decidido que la iteración n.° 14 delimita un buen conjunto de características que pueden ser una versión...Es simplemente 'Agregar n semanas' después del final de la iteración n.º 14.No hay matemáticas complejas ni incertidumbre en ese momento.El punto clave es que Si ha estado involucrando a las partes interesadas/clientes con regularidad, incorporando comentarios y manteniendo un nivel de calidad aceptable, no debería haber sorpresas de último minuto.

Si es necesario, puedes incluso hacer un comienzo rodante..es decir.el equipo de capacitación comienza a trabajar cuando el equipo de desarrollo ingresa a la iteración n.° 13.Eso les da un mes suponiendo una iteración de 2 semanas.y con suerte no tendrías un montón de funciones ingresando en la última iteración.Entonces, como máximo 2 semanas después de la Iteración #14 y sujeto a todas las alineaciones celestiales/organizativas, deberías tener una liberación y un merecido descanso.

Answer 2

Primero reconozca que el ancho/amplitud de las pruebas de las que habla aumenta a medida que el proyecto avanza 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 para 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 encaje nuevamente dentro de la iteración, ya que cada iteración solo se centraría en los aumentos incrementales de alcance/complejidad.Esto no siempre es posible en todos los contextos de proyectos, incluso si eso es lo que queremos.Sobrevalorar la automatización de pruebas de alto nivel es un error que debe tomarse en serio; en otras palabras, evite subvalorar lo que un evaluador exploratorio con razonable experiencia aporta.

Sin automatización, el problema se centra en la gestión de pruebas.Las iteraciones de prueba paralelas y en diferido son una solución candidata.Por ejemplo, podría optar por establecer un trabajo pendiente de prueba para las tareas de prueba del sistema que se gestione con la misma cadencia que las iteraciones de desarrollo pero que se retrase o se desfase en el tiempo hasta en una iteración completa.Esto permite a los evaluadores trabajar de manera integral en nuevas versiones en su propia zona de pruebas y según sus propias prioridades.

Yo recomendaría que los retrasos en las iteraciones de prueba se creen en colaboración con los desarrolladores, del mismo modo que yo recomendaría que los retrasos en las iteraciones de los desarrolladores se crearan en colaboración con los evaluadores.También recomendaría un equipo de pruebas 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 las pruebas unitarias de desarrollador y poder ejecutarlas en las versiones del entorno de pruebas.

Trabajar fuera de fase de esta manera no hace que desaparezca el problema cada vez mayor del alcance/complejidad de las pruebas, pero sí proporciona un mecanismo para gestionar esa complejidad, ya que el equipo está creando elementos de trabajo pendiente, ajustando prioridades, automatizando algunos, creando listas de verificación, etc.basándose en lo que colectivamente piensan que deberían hacer a continuación.Lo más probable es que lleguen a los artículos más importantes.

Parece que vale la pena esforzarse por preservar la capacidad de los evaluadores de trabajar de manera integral, desarrollar su comprensión y compartir sus conocimientos sobre el sistema a través de pruebas automatizadas.

Answer 3

Las pruebas automatizadas después de cada compilación automatizada le ayudarán al menos en parte del camino.

Answer 4

Agregue pruebas del sistema a su trabajo pendiente de sprint (en Scrum) o su equivalente.

Lo mismo ocurre con la documentación del usuario.

Answer 5

La ejecución de las pruebas del sistema suele ser demasiado lenta para integrarse estrechamente en el desarrollo ágil.(Hay excepciones a esto, p.e.un conjunto de pruebas de navegador bien diseñado no puede ejecutarse mucho más lento que las pruebas unitarias típicas).

Una forma de integración es tener una compilación nocturna o una compilación continua, que se ejecute todo el tiempo y que pueda tardar varias horas en compilarse y ejecutar todas las pruebas.Si una compilación pasa todas las pruebas (prueba unitaria + pruebas del sistema), se vuelve liberable, puede entregar ese binario o la instantánea del código fuente.La idea es tener x versiones de sus binarios/instantáneas de código, verificarlas de forma asincrónica y entregar las compilaciones ecológicas.Esto debería funcionar tanto con pruebas de sistemas automatizadas como con pruebas manuales.