Integración continua y QA

Question

En mi proyecto, estamos configurando un entorno de integración continua y, como parte de este proceso, proponemos la fijación simultánea de defectos durante los ciclos de prueba de QA.

¿Cuál es el proceso generalmente practicado cuando se trata de liberar esto en el entorno de control de calidad? ¿Estas correcciones se implementan inmediatamente en el entorno de control de calidad (después de las pruebas de integración) o se acumulan hasta la finalización del ciclo de prueba actual?

Answer 1

Darse un objetivo en constante movimiento es realmente difícil. Tendemos a realizar reparaciones por lotes antes de implementar QA, generalmente sobre un despliegue de QA diario. QA toma la salida de la construcción durante la noche a primera hora de la mañana, y "según sea necesario" si un error realmente crítico está bloqueando una gran cantidad de pruebas.

CI es más un punto de referencia básico de calidad de código (por ejemplo, construye, pasa las pruebas de unidad/humo) - no se siente como QA necesita tomar cada construcción que sale de CI.

Answer 2

En Entiendo correctamente, usted se pregunta cuál es la duración del ciclo de control de calidad en un proyecto que tiene un ciclo de integración continua?

Usamos un QA ciclo diario. La construcción nocturna, si tuvo éxito, está disponible para probar durante el día siguiente.

Answer 3

La respuesta de nitzmahone es un gran consejo para equilibrar las compilaciones más frecuentes que obtendrá de un sistema de CI con las necesidades de QA para tener un objetivo conocido para las pruebas.

Puede aprovechar la integración continua para obtener pruebas adicionales en la parte superior de la unidad/pruebas de humo que se ejecutan como parte de cada compilación. Aquí hay un par de cosas que he hecho:

• Establecer un puesto de trabajo en el sistema de CI que se ejecuta un trabajo programado (por ejemplo, todos los días, en lugar de ser provocada por cambios en el código fuente) para hacer una prueba de rendimiento en su sistema, y ​​log los resultados. De esta forma puede realizar un seguimiento del rendimiento a lo largo del tiempo y detectar cualquier cambio que tenga un efecto adverso en el rendimiento.
• Haga que su trabajo de compilación de CI despliegue automáticamente su sistema si las pruebas de compilación y de unidades son exitosas, y tenga un monitor de TI como Nagios comprobando el sistema desplegado. Esto actúa como una prueba del sistema rápida y sucia que a menudo puede encontrar errores que no son detectados por las pruebas unitarias. Escribí un blog post que podría serle útil si está interesado en este tipo de prueba.

Answer 4

¿Son estas soluciones desplegadas inmediatamente en el entorno de control de calidad (después de las pruebas de integración) o son acumulados hasta la finalización del ciclo de prueba actual.

Depende. Si un problema es bloqueando y no permite que los probadores ejecuten más pruebas, para finalizar un plan de prueba completo (es decir, para hacer su trabajo), entonces es posible que sea necesario liberar el arreglo inmediatamente. Si un problema no es de bloqueo, entonces es preferible poner la solución en cola y ponerla a disposición en el siguiente lanzamiento. Pero esto requiere mucho trabajo administrativo (registrar el problema, anotar el caso de prueba, etc.).

Ahora, si QA ocurre muy temprano durante el desarrollo (es decirsi no está utilizando un ciclo de desarrollo muy secuencial), si los evaluadores trabajan estrechamente con los desarrolladores, entonces sería bueno solucionar un problema tan pronto como se descubra e incluso evitar crear un inventario de errores (gran desperdicio).

Answer 5

Al comienzo de los ciclos de prueba, tiendo a tomar nuevas construcciones solo si hay errores de bloqueo que se resuelven. Esto permite que mi equipo evite el problema provocado por las nuevas compilaciones y las regresiones sorpresa. La primera parte de un lanzamiento suele emplearse para comprender cómo se implementó realmente la funcionalidad y si el producto cumple con un conjunto mínimo de criterios de aceptación.

En medio de un ciclo de prueba, acepto compilaciones más a menudo para asegurar que las correcciones tengan la mayor exposición posible e identifique errores corregidos de manera incorrecta tan pronto como sea posible. Por lo general, esto es diario, excepto en entornos en los que realizamos pruebas de estrés o rendimiento a largo plazo.

A medida que se acerca el lanzamiento y ejerzo un mayor control sobre los errores corregidos (es decir: la versión actual es ramificada y tenemos una política de línea de código más estricta) Continuaré tomando construcciones solo cuando encontremos errores de bloqueo de versiones . En este momento, las compilaciones a menudo se denominan beta o candidatas de lanzamiento.

Answer 6

Depende del estilo de desarrollo del proyecto. Asumiendo que eres un equipo ágil.

• Hay dos niveles de prueba, la prueba durante la iteración y al final de la iteración
• El objetivo del CI es encontrar y corregir errores durante la iteración. El tipo de prueba se centra en la unidad, funcional y en la implementación de historias
• Los errores que encuentre en equipos tan ágiles deben repararse antes del lanzamiento al entorno de QA
• El entorno de QA se debe usar para realizar pruebas de regresión e integración. El propósito de estas pruebas debe ser encontrar la regresión y la integración en lugar de la funcionalidad de características

Arriba está el enfoque general., Fuera de curso, que es altamente dependiente de la naturaleza de su software y equipo de

Answer 7

errores encontrados durante la CI las compilaciones deben ser arregladas por los equipos de desarrollo tan pronto como atrapen. Mientras que los equipos de QA reciben las compilaciones regulares durante sus ciclos de lanzamiento regulares o ciclos de parches, no por problemas de compilación CI.

Como las pruebas automáticas de construcción de CI atraparon muchos errores relacionados con QA y no relacionados con QA, por lo tanto, esto lleva directamente a una gran carga de rendimiento en otras actividades de QA.

Todo depende de las políticas de control de calidad de la empresa, algunos pueden o algunos pueden no estar de acuerdo con mi punto :)

Answer 8

Esto puede hacerse dividiendo equipo de QA en sub-equipos es decir, internos y externos. El trabajo de QA interno como parte del equipo de desarrollo bajo el administrador de desarrollo y el QA externo realizan la prueba del producto que se está desarrollando.

El equipo de control de calidad interno es responsable de las pruebas de sanidad del producto. Evalúan la comprobación básica de la construcción ejecutando flujos de cordura. En caso de que falle el flujo de cordura o el módulo principal/recién creado se cuelga, IQA enruta el correo electrónico al gerente de lanzamiento/administrador de desarrollo para desarrollar una nueva construcción. Una vez que se pasan los flujos de cordura, el equipo de QA externo pruebas.

La construcción se planifica a diario, los errores externos se informan. Los QA internos están ahí para flujos de cordura y comunicación rápida y discusión con el desarrollador. De esta forma, se puede potenciar todo el proceso y se reduce la brecha QA-Dev al agregarlos en el equipo Dev.

Espero que responda a su pregunta! Saludos :)