¿Es correcto corregir errores sin agregar nuevas características al lanzar software para probar el sistema?

Esta pregunta es para probadores experimentados o conductores de prueba. Este es un escenario de un proyecto de software:

Digamos que el equipo de desarrollo ha completado la primera iteración de 10 características y la lanzó a las pruebas del sistema. El equipo de prueba ha creado casos de prueba para estas 10 características y estimó 5 días para la prueba. El equipo de desarrollo, por supuesto, no puede permanecer inactivo durante 5 días y comienzan a crear 10 nuevas funciones para la próxima iteración. Durante este tiempo, el equipo de prueba encontró defectos y provocó algunos errores. Los errores tienen prioridad y algunos de ellos deben corregirse antes de la próxima iteración. El problema es que no aceptarían la nueva versión con nuevas características o cambios en las características existentes hasta que se solucionen todos esos errores. El equipo de prueba dice que así es como podemos garantizar una versión estable para las pruebas si también presentamos nuevas características junto con la corrección de errores. Tampoco pueden hacer pruebas de regresión de todos sus casos de prueba en cada iteración.

Esto significa que el equipo de desarrollo debe crear una rama de código únicamente para la corrección de errores y otra rama donde continúen el desarrollo. Hay más gastos generales de fusión especialmente con refactorización y cambios arquitectónicos.

¿Puedes aceptar si este es un principio de prueba común? ¿Es válida la preocupación del equipo de prueba? ¿Ha encontrado esto en la práctica en su proyecto?

En cambio, diría que cada lanzamiento de nuevas características debería estar en una rama separada. Esto permite desacoplar el desarrollo y las versiones.

¿Cómo funciona su lanzamiento para los usuarios finales en este proceso? Su equipo de prueba del sistema debería estar menos preocupado con el cronograma de desarrollo y, en cambio, centrarse en el cronograma de lanzamiento del cliente.

No tiene mucho sentido intentar probar formalmente nuevas características mientras el desarrollo continúa, porque es muy probable que sus próximas 10 características toquen la misma funcionalidad y requieran que prueben esas áreas nuevamente.

Pueden continuar probando informalmente las versiones internas provisionales durante el desarrollo y desarrollar su diseño de prueba (con suerte atrapando la mayoría de los errores en esas nuevas características), pero necesitarán un período adicional al final del desarrollo para la prueba formal de nuevas características y regresión pruebas.

Cuando estiman los 5 días necesarios para probar sus 10 nuevas funciones, lo que deberían considerar es que necesitan 5 días al final del ciclo de desarrollo, antes del lanzamiento a los clientes, para validar las nuevas funciones (y probablemente más tiempo para repetir) si se encuentran errores). Durante este período, la versión del cliente puede ser ramificada para pruebas, y el desarrollo de nuevas características puede continuar para la próxima versión.

Utilizamos un enfoque híbrido. Para el lanzamiento del cliente, definitivamente tenemos su propia rama, que es estrictamente solo para la corrección de errores críticos.

El desarrollo regular continúa en múltiples versiones de software. Por ejemplo, supongamos que la última versión estable es 2.0. Todas las características de riesgo se agregarán a la rama 3.0. Solo las correcciones de errores entran en las ramas 2.0. Las pruebas realizadas por un equipo de control de calidad dedicado solo se realizan en sucursales estables. Por supuesto, los lanzamientos de clientes se realizan desde otra sucursal basada en 2.0. Las características de larga duración como el desarrollo de la plataforma de próxima generación se realizarán en 4.0, ni siquiera en 3.0.

Todo esto se ve bien en el papel. Pero si un cliente desea una característica específica, debe agregarse a la propia sucursal 2.0, ya que 3.0 no es lo suficientemente estable como para ser lanzada a los clientes. Esto significa que el equipo de control de calidad tendrá que volver a ejecutar todo el conjunto de regresión.

Una cosa que hacemos es hacer una cobertura de código de cada caso de prueba de regresión. Solo se ejecutan los casos de prueba de regresión que se verán afectados por los cambios de código para la función. Por supuesto, para una versión de cliente, se ejecuta el conjunto de regresión completo.

Eso realmente depende de qué tan estrechamente estén las nuevas características con las partes que requieren correcciones de errores. Por ejemplo, si agrega una nueva función de arrastrar y soltar a una pequeña porción de la interfaz de usuario, "no debería" afectar el error relacionado con el análisis del archivo cargado por el usuario.

Dicho esto, es comprensible (no necesariamente justificado) que los evaluadores quieran probar las soluciones 'Ceteris paribus' (todas las 'otras' cosas son iguales).

Puede haber otras preocupaciones con la forma de lanzamiento y las expectativas de los usuarios finales. Por ejemplo, es posible que deba lanzar solo después de una iteración de corrección de errores + prueba y una nueva característica más + prueba porque los usuarios SOLO desean reinstalar o actualizar cuando hay nuevas características. Algunos pueden exigir arreglos como prioridad máxima lo antes posible.

Puede resolver este problema (común) fusionando fusionar ambos equipos.

Los probadores dentro del equipo de desarrollo, que prueban a medida que se producen las características, pueden ayudar a la mayoría de los equipos a aumentar la calidad del resultado.

Le sugiero que lea esta excelente publicación de blog de Henrik Kniberg que explica Kaban . Encontrará muchas ideas en el proceso Scrum (un libro gratuito también de Henrik Kniberg ).

También escribió un excelente artículo de Kanban VS Scrum en su blog.

Disfrutar.

El equipo de prueba definitivamente tiene una preocupación válida, pero cuestionaría la necesidad de múltiples iteraciones de prueba para cada versión. ¿Por qué realizar una ronda completa de pruebas en una versión de código que los usuarios nunca verán?

Si los evaluadores intentan obtener una versión definida para un cliente, que no espera las nuevas funciones, entonces su solicitud es razonable, justificada y usted debe hacer lo imposible para entregarla.

Si esto es solo para ayudar en sus "procesos" durante las fases normales de desarrollo, y para asegurarse de que la lista de errores no se esté quedando sin control, sin hacer un problema, pregúntele al jefe de pruebas si esta restricción se puede relajar un poco hasta nos acercamos al punto de lanzamiento.

Considere cambiar su sistema de control de fuente a un producto distribuido. Esto facilitará mucho la entrega de dicha versión.

"¿Puede aceptar si este es un principio de prueba común?

Yes

¿Es válida la preocupación del equipo de prueba?

Yes

¿Ha encontrado esto en la práctica en su proyecto ".

Yes

:

and Yes Merging is the downside of it 

No preguntó quién es la responsabilidad, pero es responsabilidad del Administrador de configuración. Esta estrategia de transmisión debería estar en su CMP. De lo contrario despedirlo. Creo que la respuesta de Pierre 303 también es muy buena, pero por supuesto siempre que sea posible técnicamente (por ejemplo, pensando en un lanzamiento de Siebel ...) y organizativamente.

El problema es que si prueban los errores en una rama, aún necesitan volver a probarlos y hacer una prueba de regresión en el tronco una vez que se vuelven a fusionar (a menos que confíen mucho en los probadores buenos que rara vez lo hacen). Esto no solo está haciendo más trabajo para los desarrolladores, está haciendo más trabajo para los probadores.

No hay una respuesta correcta aquí, pero debe considerar algunas cosas:

• ¿Podrían estas versiones de errores (sin la nueva funcionalidad) llegar alguna vez a los usuarios? Si es así, sí, debe ser ramificado y probado y todos deben aceptarlo como una sobrecarga.

• ¿Es posible dividir la nueva funcionalidad de tal manera que exista en áreas completamente separadas de la aplicación a los fragmentos anteriores en los que se trabajó? Si es así, esto le brinda opciones: los evaluadores pueden llevar a cabo las pruebas de error y las partes de prueba de regresión de la aplicación. No es ideal, pero es un compromiso que podría funcionar y darles algo de lo que quieren.

• ¿Cuánto trabajo es realmente para ramificar un lanzamiento? En general, es una molestia, pero la cantidad real de trabajo no suele ser tan buena. Obviamente, los necesitará para confirmar que no solo es más trabajo para ellos también (vea lo primero que digo) sino que he visto lugares que hacen que esto funcione.

• ¿Hay una mejor manera de usar el control de versiones aquí? Algo como Mercurial (vea http://hginit.com/ - léalo, es bueno) u otro sistema de control de versiones distribuido se ramifica y fusiona de una manera diferente y puede permitirle solucionar el problema. Realmente, échale un vistazo porque creo que podría ser la respuesta a tu problema.

Pero buena suerte, es un dolor. Sobre todo, recuerde que el mejor camino a seguir dependerá mucho de su empresa, producto y situación, así que asegúrese de pensar en eso y no solo saque algo del estante y crea que debe cumplirlo al 100%.

Si los errores que describe son defectos reales y no optimizaciones de diseño , entonces sí, realmente debería intentar solucionarlos antes de comenzar a trabajar en nuevas características.

Si crea nuevas funciones además de errores conocidos, está creando un castillo de naipes. Es probable que desarrolle software frágil e impredecible. Dependiendo del nivel de aislamiento entre el código con errores y sus nuevas funciones, los errores también podrían afectar sus nuevas funciones. Si es así, ¿cómo podría saber si sus nuevas funciones funcionan correctamente?

Si primero corrige sus errores, tendrá una base más sólida para cualquier característica nueva que agregue.

Ciertamente, hay momentos en que las fuerzas externas te presionan para que vayas en contra de tu mejor juicio. Intente ayudar a los responsables de la toma de decisiones a tomar una decisión informada cuando sean conscientes de las consecuencias de cualquier curso de acción (es decir, defectos no resueltos versus fechas de entrega de características perdidas) y permítales ejercer su criterio. A veces hay razones legales y financieras donde un curso de acción, aunque no es preferible, es necesario.

¡Intente siempre corregir errores antes de agregar nuevas funciones!

Donde trabajo manejamos este escenario donde cada lanzamiento previsto para producción tiene su propia rama. Por ejemplo, supongamos que por un segundo habrá un lanzamiento a fines de junio y otro a fines de julio. La versión de junio obtendría su propia sucursal, y todas las características se agregarían allí y se enviarían a QA. En este punto, comenzaríamos a trabajar en el lanzamiento de julio y nos ramificaríamos desde la sucursal de junio. Cuando QA encuentra errores, los corregimos en la rama de junio y una vez que las correcciones se han enviado a QA, se fusionan en la rama de lanzamiento de julio. Esto agrega un poco de sobrecarga para manejar estas fusiones, pero generalmente las fusiones son bastante indoloras. De vez en cuando es muy doloroso saber qué, pero eso solo ocurre cuando se realizan cambios generales, y no deberían ocurrir durante el ciclo de control de calidad (pero suceden, más de lo que me gusta admitir). Pero con un buen conjunto de pruebas (unidad e integración), y cobertura de código y todas las otras palabras de moda de TDD, los riesgos se mitigan un poco. Para ayudar, generalmente tenemos una persona que maneja las fusiones para cada proyecto.