Entiendo que, en teoría, el control de calidad debería estar trabajando con el desarrollador "colaborando" desde el día 1 de un sprint. Pero, ¿cómo funciona realmente en la vida real? Permítanme presentar dos escenarios:
Escenario 1 donde una historia requiere 3 días de desarrollo: digamos que es un informe complicado con una configuración de base de datos y una lógica de dominio que consumen mucho tiempo, etc. y tarda 3 días en codificarse. Dado que el desarrollador no puede entregar nada significativo para probar antes de 3 días y suponiendo que solo toma 4 horas escribir todos los casos de prueba relevantes, ¿qué se espera que haga el control de calidad hasta que el informe esté listo para la prueba?
Escenario 2 donde las historias son lo suficientemente pequeñas como para completarse en horas: consideremos una pantalla de inicio de sesión/registro. Puede haber pequeñas historias para que el usuario pueda iniciar sesión, el usuario pueda registrarse, olvidó la funcionalidad de la contraseña, etc. Un desarrollador puede completar cada una de estas historias en horas y pasar al control de calidad y pasar a la siguiente historia pero la siguiente historia podría romper los anteriores. Por ejemplo, si el desarrollador finaliza la funcionalidad de inicio de sesión y el control de calidad comienza a probarla y luego comienza a trabajar en la funcionalidad de contraseña olvidada, podría interrumpir el inicio de sesión de formas inesperadas porque las funcionalidades están realmente relacionadas. Si el control de calidad espera a que se completen todas las historias relacionadas, terminaremos con el escenario 1 anterior.
En un mundo perfecto, se puede esperar que QA no haga nada si de hecho no hay nada que hacer y aceptarlo como parte del costo. Pero en un mundo real, PMO y otros grupos que realizan un seguimiento de la utilización de recursos sin duda lo señalarán como una mala gestión de proyectos y cosas peores. Entonces, ¿cómo funciona todo en escenarios de la vida real? ¿Cuál es la mejor manera de aplicar Scrum en este tipo de escenarios?
Está cayendo en una falacia de utilización al tratar el desarrollo y el control de calidad como actividades separadas. En un equipo ágil, las prácticas como el desarrollo basado en pruebas (TDD), el desarrollo basado en el comportamiento (BDD) o el desarrollo basado en pruebas de aceptación (ATDD) aseguran que la calidad se integra escribiendo las pruebas primero .
En otras palabras, el patrón rojo/verde/refactor significa que el control de calidad debe participar antes de que se escriba ningún código. Incluso en equipos donde los individuos tienen forma de I en lugar de forma de T, los desarrolladores y evaluadores deben trabajar de la mano todo el tiempo a través de la programación en pareja y la integración continua.
Los desarrolladores y evaluadores deben colaborar activamente, en lugar de trabajar en paralelo o en secuencia. Incluso si su organización cae presa de la falacia de utilización del 100 %, siempre hay cosas que los evaluadores deben hacer en un equipo ágil, que incluyen:
No estoy recomendando de ninguna manera que evacue sus procesos. Simplemente estoy señalando que siempre hay mucho trabajo de prueba y control de calidad por hacer, incluso en ausencia de código o características nuevas.
También es dinero inteligente para el proyecto invertir en desarrolladores y evaluadores de capacitación cruzada. Muchos desarrolladores pueden beneficiarse al aprender sobre técnicas de prueba, para que puedan escribir más código comprobable. Del mismo modo, los probadores pueden beneficiarse de aprender más sobre el desarrollo, lo que los convierte en mejores probadores y recursos más completos.
Junto con la "agilización" de los proyectos, el papel del control de calidad está "evolucionando" considerablemente.
Veo el escenario de Todd (+1!) como el estado objetivo para un equipo de control de calidad maduro. Espero que su equipo pueda hacerlo directamente. Sin embargo, hay casos en los que el equipo de control de calidad es menos maduro y requiere algunos pasos de madurez intermedios.
En un mundo perfecto, se puede esperar que QA no haga nada si de hecho no hay nada que hacer y aceptarlo como parte del costo.
No existe un mundo ideal en el que alguien no haga absolutamente nada .
Se cita a Abraham Lincoln diciendo
“Si tuviera cinco minutos para cortar un árbol, pasaría los primeros tres afilando mi hacha”.
Eso es lo que cualquier control de calidad, independientemente de cuán maduro sea un proceso o un equipo, debería estar haciendo mientras no hace... bueno, control de calidad.
Entonces, ¿cómo funciona todo en escenarios de la vida real? ¿ Cuál es la mejor manera de aplicar Scrum en este tipo de escenarios?
QA ya no es un equipo responsable de ejecutar casos de prueba. El control de calidad es responsable de comprender en profundidad cómo funciona la aplicación y prever los posibles casos de uso que podrían fallar y de los que el desarrollador puede no estar al tanto. En el pasado, esto lo hacían en gran medida los analistas (funcionales). Es posible que este ya no sea el caso. En algunos aspectos, existe la expectativa de que QA se convierta en la referencia para el conocimiento funcional. es discutible, pero es importante considerar esto.
Python se está convirtiendo en uno de los lenguajes más útiles en la actualidad. Los desarrolladores están usando más Python para el análisis de datos que para el desarrollo web. ¿Sabes quién también podría beneficiarse de conocer los conceptos básicos sobre el análisis de datos? Sí, control de calidad.
Al aplicar los pasos uno y dos, es posible que esté a mitad de camino con un equipo capaz de encajar en el equipo de control de calidad de Todd.
Usted preguntó cómo se ve la colaboración y esa es la pregunta importante. En Scrum, no es necesario que haya una fase de control de calidad. Prácticas como las reuniones de 3 Amigos, el desarrollo basado en pruebas, el desarrollo basado en el comportamiento y el emparejamiento significan que los miembros del equipo de control de calidad pueden colaborar con el equipo todo el tiempo. En la medida de lo posible, queremos usar el principio Lean de Build Quality In en lugar de verificarlo después y para eso, necesitamos la perspectiva de control de calidad a lo largo de todo el proceso.
La mentalidad y la forma de trabajar ágiles son muy diferentes de la mentalidad y la forma de trabajar tradicionales. Esta oración muestra que "PMO y otros grupos que realizan un seguimiento de la utilización de recursos sin duda lo señalarán como una mala gestión de proyectos y cosas peores". que su empresa tiene un largo camino hasta que pueda llamarse ágil. Le sugiero que lea Agile Manifesto como una actividad de equipo y descubra lo que significa para usted como equipo.
Otra cosa que parece que te falta: Testing y QA no es lo mismo . La prueba es la forma en que analizamos el software con el objetivo de encontrar errores que ya construimos. QA representa todas las actividades que establecemos con el objetivo de evitar que el software tenga errores incorporados: ¡sin errores, no es necesario corregirlos! Escribí un artículo sobre eso.
En un equipo ágil, el probador puede asumir ambos roles: encontrar errores (pruebas) y establecer reglas que protejan el software (QA). Para las pruebas necesita un software, para el control de calidad no necesita un software.
En la vida real, el día de los evaluadores ágiles podría tener actividades como esta:
Espero que ayude.
¿Pueden tener las cosas listas para probar, de modo que cuando los desarrolladores completen las historias/errores, estén listos para probar? Configuración de servidores, bases de datos o datos para que puedan ponerse en marcha cuando sea el momento de la prueba.
Tenemos varios clientes, todos con su propia base de datos. Nuestro equipo de control de calidad sabe qué historias/errores afectan a ciertos clientes cuando comienza el sprint. Entonces, nuestro equipo de control de calidad crea copias de seguridad de la base de datos para esos clientes específicos y prepara las bases de datos de prueba en nuestro entorno de prueba.
Encontré este artículo interesante: https://www.352inc.com/blog/what-does-qa-do-on-the-first-day-of-a-sprint/
Anime a su persona de control de calidad a aprender nuevas habilidades para ayudar a pasar las historias al control de calidad. Opciones > incluyen:
aprender a programar
Haz un trabajo de diseño
Realizar algunas pruebas de usuario
Configuración y administración del servidor
Todos los puntos que menciona en su pregunta son válidos, pero estos problemas se pueden resolver mediante una cuidadosa colaboración dentro del equipo Scrum.
Un ejemplo de una conversación durante la planificación del sprint:
"Algunas de estas historias tardarán unos días en desarrollarse antes de que estén listas para la prueba. Pero algunas de las otras historias son bastante rápidas de hacer. ¿Por qué no hacemos algunas de las historias más pequeñas primero, para que los probadores ¿Tienen algo con lo que empezar? Entonces pueden trabajar en la primera gran historia cuando estén listos".
También:
"Me preocupa que muchas de nuestras historias dependan unas de otras. Eso hará que la planificación de las pruebas sea realmente complicada. ¿Deberíamos refactorizar las historias para que sean independientes para que las pruebas se realicen sin problemas?"
Y:
"Este sprint va a ser bastante ligero en las pruebas. ¿Por qué no dedicamos más tiempo disponible a expandir nuestra cobertura de regresión automatizada?"
A medida que el equipo de Scrum madura, es posible que adopte prácticas como el desarrollo basado en pruebas y el desarrollo basado en el comportamiento. También puede obtener capacitación cruzada entre desarrolladores y evaluadores para que los miembros del equipo tengan perfiles de habilidades en forma de T.
Con más experiencia y prácticas de trabajo mejoradas, el equipo mejorará cada vez más a la hora de equilibrar el desarrollo y las pruebas. Eventualmente habrá poca distinción entre lo que se considera codificación y lo que se considera prueba.
Lo más crítico que quise decir, al comienzo de la respuesta anterior, fue esto:
Si sus desarrolladores necesitan embarcarse en un avance de desarrollo de varios pasos que es de cierta complejidad y desean dividirlo en hitos además de "historias de usuario", entonces sugiero que deberían crear pruebas a medida que desarrollan el código. (Además de cualquier "talonario" necesario, etc.) El hito se alcanza cuando se pasan todas las pruebas, y avanzan desde ese punto mientras verifican constantemente que las pruebas continúan pasando, por lo que saben de inmediato si simplemente rompió algo. De vez en cuando, pueden retirar una de sus pruebas. Los presento como separados de las actividades de un equipo de control de calidad que se centra en "lo que finalmente será visible". Todo lo anterior, "Desarrollo basado en pruebas", bien podría ser competencia del gerente de desarrollo,
Aquí hay dos niveles de "seguridad" al mismo tiempo, ambos muy similares, pero muy diferentes. Pero el director del proyecto debe estar en todo momento al tanto de lo que sucede en ambos niveles. ¡ Y los dos niveles deben ser distintos!
En mi opinión, entonces, los dos niveles no son (todavía) distintos. Si lo hubiera, entonces estaría muy claro un "proceso de lanzamiento de candidatos de lanzamiento por parte del equipo de desarrollo", y no habría duda de en qué consistía el "código para ser aprobado por el control de calidad".
La razón específica por la que "los dos niveles no son (todavía) distintos" es exactamente como se indica en el párrafo editado: en un proyecto de software de cualquier tamaño, debe haber dos niveles distintos. El equipo de control de calidad, que opera completamente en el nivel dos, no debe participar ni verse afectado de ninguna manera por los procesos internos (pero muy necesarios) que podrían estar ocurriendo en el nivel uno. Pero los equipos de desarrollo nunca deberían lanzar "candidatos" hasta el control de calidad de nivel uno hasta que estén seguros.
Mi sospecha es que el equipo de desarrollo está "avanzando a la carrera", de un hito que solo él conoce a otro, esperando de alguna manera que el equipo de control de calidad evalúe un objetivo que se mueve bajo sus pies. Obviamente esto es una tontería.
Además, veo en su descripción que la funcionalidad que se supone que debe probar su equipo de control de calidad no está en una rama estable de control de versiones que no se verá afectada por futuras actividades de desarrollo. El material desarrollado debe agregarse a las sucursales de control de calidad y etiquetarse para que el control de calidad siempre esté probando contra un objetivo inmóvil.
Pero también: cuando dices que "una historia futura rompe una anterior", entonces diría que tienes un problema mucho más grande de desglose de tareas. Se supone que las "historias" representan lo que ve un usuario hipotético, pero también deben reflejar el comportamiento de la aplicación que se lanzará, no un paso intermedio.
Las "historias" tienen que estar compuestas en lo que serán los flujos de trabajo reales y los hitos de cuatro de sus equipos de desarrollo; es posible que no coincidan exactamente porque "los narradores de historias no necesariamente saben cómo funciona". Lo que realmente impulsa su programa de desarrollo debe ser una búsqueda a veces paralela de funciones completas, que luego se pueden probar de manera significativa de modo que no se espere una "regresión" de ese estado de pruebas aprobadas. Es posible que un solo incremento de flujo de trabajo de desarrollo pueda completar "parte de una historia" o "parte de varias historias". En la práctica, la arquitectura de la aplicación, en particular la de una aplicación heredada , dicta esto.
código511788465541441