Ayúdame a entender cómo funciona el control de calidad en Scrum [cerrado]

Question

Aparentemente usamos la metodología de desarrollo Scrum. Aquí es en general cómo va:

Los desarrolladores intentan cumplir sus tareas. En general, las tareas toman la mayor parte del sprint para completar. QA acosa a Dev para que libere algo que puedan probar, Dev finalmente lanza un código de buggy a QA uno o dos días antes de que termine el sprint y dedica el resto del tiempo a corregir los errores que QA está encontrando. El control de calidad nunca puede completar las tareas a tiempo, los sprints rara vez se pueden liberar a tiempo, y Dev y QA tienen unos días miserables al final del sprint.

¿Cómo se supone que funciona scrum cuando las tareas de desarrollo liberables toman la mayor parte del sprint?

Gracias a todos por su parte en la discusión. Como es una pregunta bastante abierta, no parece que haya una " respuesta " - Hay muchas buenas sugerencias a continuación. Intentaré resumir algunos de mis " llevar a casa " Puntos y hacer algunas aclaraciones.

(BTW - ¿Es este el mejor lugar para poner esto o debería haberlo puesto en una 'respuesta'?)

Puntos para reflexionar / actuar:

• Debe asegurarse de que las tareas del desarrollador sean lo más pequeñas (granulares) posibles.
• La longitud del sprint debe basarse adecuadamente en la duración promedio de la tarea (por ejemplo, el sprint con tareas de 1 semana debe tener una duración de al menos 4 semanas)
• El equipo (incluido el control de calidad) debe trabajar para ser más precisos en la estimación.
• Considere hacer un sprint de control de calidad por separado en paralelo pero fuera de serie si eso funciona mejor para el equipo
• Pruebas de unidad!

Answer 1

Mi opinión es que tienes un problema de estimación. Parece que falta el tiempo para probar cada característica, y solo se está considerando la parte del edificio cuando se planifica el sprint.

No estoy diciendo que sea un problema fácil de resolver, porque es más común que cualquier otra cosa. Pero las cosas que podrían ayudar son:

• Considere el control de calidad como miembros del equipo de desarrollo e inclúyalos en la planificación y estimación de sprint más detalladamente.

• Las 'tareas de desarrollo liberables' no deben ocupar la mayor parte del sprint. Las características de trabajo completas deberían. Trate de reunir métricas sobre el tiempo de desarrollo contra el tiempo de control de calidad para cada tipo de tarea y use esas métricas cuando estime los futuros sprints.

• Es posible que tenga que revisar su acumulación para ver si tiene características muy generales. Intente dividirlos en tareas más pequeñas que puedan estimarse y probarse fácilmente.

En resumen, parece que su equipo no ha encontrado cuál es su velocidad real porque hay tareas que no se están considerando al realizar la estimación y la planificación para el sprint.

Pero al final, la inexactitud de la estimación es un problema difícil de administración de proyectos que se encuentra en proyectos ágiles o en cascada. Buena suerte.

Answer 2

Un poco tarde para la fiesta aquí, pero aquí está mi opinión basada en lo que escribiste.

Ahora, Scrum es una metodología de gestión de proyectos, no una de desarrollo. Pero es clave, en mi opinión, tener un proceso de desarrollo implementado. Sin uno, pasas la mayor parte de tu tiempo reaccionando en lugar de construir.

Soy un chico que prueba primero. En mi proceso de desarrollo, primero construyo pruebas para hacer cumplir los requisitos y las decisiones de diseño. ¿Cómo está tu equipo aplicando eso? El punto que trato de señalar aquí es que simplemente no puede " tirar cosas por encima de la valla " y esperar que ocurra algo que no sea el fracaso. Ese fallo será por parte del equipo de prueba (al no realizar las pruebas muy bien y, por lo tanto, dejar que pasen los problemas) o por los desarrolladores (al no crear el producto que resuelve el problema). No estoy diciendo que usted debe escribir pruebas primero - no soy un militante o un evangelista de prueba - pero estoy diciendo que debe debe tener un proceso establecido para producir código de calidad, probado y listo para la producción cuando llegue al final de una iteración.

He estado justo donde estás en esta metodología de desarrollo que llamo Método de la Espiral de la muerte . Construí software para el gobierno (EE. UU.) Durante años en ese modelo. No funciona bien, cuesta mucho dinero, produce código tardío, código deficiente y no hace nada por la moral. No puedes hacer ningún progreso cuando pasas todo el tiempo arreglando errores que podrías haber evitado en primer lugar. Fui absolutamente derrotado por el asunto.

No quieres que QA encuentre tus problemas. Quieres dejarlos sin trabajo, de verdad. Mi objetivo es hacer que el control de calidad quede pasmado porque todo funciona. Por supuesto, ese es un objetivo. En la práctica, encontrarán cosas. No soy superhumano. Cometo errores.

Volver a programar ...

En mi trabajo actual, hacemos Scrum, simplemente no lo llamamos así. No estamos en las etiquetas aquí, pero estamos en producir un código de calidad a tiempo. Todo el mundo está a bordo. Le decimos a QA lo que tendremos listos para probar y cuándo. Si llegan dos semanas antes, pueden hablar con la mano. Todos conocen el programa, todos saben lo que habrá en el lanzamiento y todos saben que el producto tiene que funcionar como se anuncia antes de que llegue al control de calidad. ¿Entonces que significa eso? Le dices a QA " no te molestes en probar XYZ; está roto y no se solucionará hasta la versión C " y si van a probar eso, les remitas a esa declaración y les dices que no pierdan el tiempo. Duro, tal vez, pero a veces necesario. No me gusta ser grosero, pero todo el mundo necesita saber " las reglas " y qué se debe probar y qué es un "problema conocido".

Su gestión tiene que estar a bordo. Si no es así vas a tener problemas. El control de calidad no puede ejecutar el programa y el grupo de desarrolladores tampoco puede ejecutarlo por completo. Todos los grupos (incluso si esos grupos son solo una persona por grupo o un tipo que usa varias funciones) deben estar en la misma página: el cliente, el equipo de prueba, los desarrolladores, la administración y cualquier otra persona. Más de la mitad de la batalla es la comunicación, normalmente.

Tal vez estés mordiendo más de lo que se puede lograr durante un sprint. Ese podría ser el caso. ¿Por qué estás haciendo eso? ¿Para cumplir un horario? Si es así, ahí es donde la administración debe intervenir y resolver el problema. Si está dando un código de error de control de calidad, espere que lo devuelvan. Mejor darles 3 cosas que funcionan que 8 cosas que están sin terminar. El objetivo es producir un conjunto de funcionalidades que se implementen completamente en cada iteración, no juntar un montón de cosas a medio hacer.

Espero que esto se reciba como se pretende que sea, como un estímulo no como una perorata. Como mencioné, he estado donde estás y no es divertido. Pero hay esperanza. Puedes dar vuelta las cosas en un sprint, tal vez dos. Quizás no agregue ninguna funcionalidad nueva en el próximo sprint y simplemente arregle lo que está roto. Tendrás que decidir eso como un equipo.

Un enchufe pequeño más para escribir el código de prueba: Me he encontrado mucho más relajado y mucho más seguro en mi producto desde que adopté el enfoque de "escriba primero las pruebas". Cuando todas mis pruebas pasan, tengo un nivel de confianza que simplemente no podría tener sin ellas.

¡Mucha suerte!

Answer 3

Me parece que hay un problema de asignación de recursos en escenarios que requieren pruebas funcionales de control de calidad para que una característica determinada se "haga" dentro de un sprint. Nadie parece abordar esto en ninguna discusión relacionada con el control de calidad que he encontrado hasta ahora, y la pregunta original aquí es casi la misma (al menos relacionada), así que quería ofrecer una respuesta parcial y ampliar la pregunta un poco.

En cuanto a la pregunta original específica acerca de las tareas de desarrollo que toman el sprint completo, parece que el consejo general para facilitar estas tareas tiene sentido si las pruebas funcionales de control de calidad son parte de su definición de "hecho". Dados, digamos, un sprint de 4 semanas, si se tarda aproximadamente una semana en probar múltiples funciones de múltiples desarrolladores, entonces parece que las tareas de desarrollo demoran aproximadamente 3 semanas, seguidas de una semana de retraso de tareas de prueba que demoran aproximadamente 1 semana es la respuesta. Por supuesto, el control de calidad comenzará tan pronto como sea posible si reconocemos que a partir del último conjunto de funciones entregadas, habrá un retraso de aproximadamente una semana. Me doy cuenta de que queremos obtener características para el control de calidad lo antes posible, por lo que no tiene este escenario similar a una cascada en un sprint, pero la realidad es que el desarrollo generalmente no puede obtener una funcionalidad real y valiosa para el control de calidad hasta 1 a 3 semanas. el sprint Claro que hay partes y partes aquí y allá, pero la mayor parte del trabajo es de 2 a 3 semanas de desarrollo, y luego aproximadamente una semana de pruebas.

Aquí está el problema de la asignación de recursos, y mi extensión a la pregunta: en el escenario anterior, el control de calidad tiene tiempo para probar las características planeadas de un sprint (3 semanas de tareas de desarrollo, lo que deja la última semana para probar las características entregadas). último). También asumamos que el control de calidad comienza a obtener algunas características comprobables después de 1 semana de desarrollo, pero ¿qué pasa con la semana # 1 para el control de calidad y qué con la semana # 4 para el desarrollo?

Si las pruebas funcionales de control de calidad son parte de la definición de 'hecho' para una característica en un sprint, entonces parece que esta ineficiencia es inevitable. El control de calidad estará prácticamente inactivo durante la semana # 1 y el desarrollo estará inactivo durante la semana # 4. Por supuesto, hay algunas cosas que se completan en este momento de forma natural, como la corrección y corrección de errores, el diseño / plan, etc., pero esencialmente estamos controlando nuestros recursos al 75% de su capacidad.

La respuesta obvia parece ser que se superponen los sprints para el desarrollo y el control de calidad, ya que la realidad es que el control de calidad siempre se retrasa en algún grado. Las demostraciones a los propietarios de los productos y otros seguirán el sprint de control de calidad, ya que queremos que las características se prueben antes de mostrarse. Esto parece permitir un uso más eficiente tanto del desarrollo como del control de calidad, ya que no tenemos mucho tiempo perdido. Suponiendo que queremos que los desarrolladores sigan desarrollando y probando, no puedo ver una mejor solución práctica. Tal vez me haya perdido algo, y espero que alguien pueda arrojarme algo de luz sobre esto; de lo contrario, parece que este enfoque rígido al scrum es defectuoso. Gracias.

Answer 4

Con suerte, puedes solucionar esto al enfrentar menos tareas de desarrollo en cada sprint. Lo que lleva a las preguntas: ¿Quién está configurando los objetivos del desarrollador? ¿Por qué Dev no alcanza esos objetivos constantemente?

Si dev no está estableciendo sus propios objetivos, es por eso que siempre llegan tarde. Y esa no es la manera ideal de practicar Scrum. Eso es solo un desarrollo incremental con grandes entregables de plazos y sin responsabilidad real de los interesados ??por parte de los desarrolladores.

Si los desarrolladores no pueden establecer sus propios objetivos porque no saben lo suficiente, tienen que estar más involucrados desde el principio.

Scrum depende de cuatro principios básicos, descritos en el Manifiesto Ágil .

1. Las interacciones son importantes: eso significa que dev, QA, gestión de proyectos y usuarios finales necesitan hablar más y hablar entre ellos. El software es un proceso de codificación de conocimiento en el lenguaje arcano de las computadoras. Para codificar el conocimiento, los desarrolladores deben tener el conocimiento. [¿Por qué crees que lo llamamos " código " ;?] Scrum no es una " especificación de escritura - lanzar sobre el travesaño " metodología. Es ANTI- " escriba las especificaciones - lanzar sobre el travesaño "

2. El software operativo es importante, lo que significa que cada pieza que devuelve el papel debe llevar a una versión funcional . No es un conjunto de correcciones de errores para el control de calidad con el que se lucha, pero funciona el software.

3. Colaboración con el cliente: eso significa que el desarrollador tiene que trabajar con analistas de negocios, usuarios finales, dueños de negocios, todos los que pueden ayudarlos a comprender lo que están creando. Los plazos no importan tanto como la próxima cosa entregada al cliente. Si el cliente necesita X, eso es lo más importante para todos. Si el plan del proyecto dice que la compilación Y, eso es una carga de malarkey.

4. Respondiendo al cambio: eso significa que los clientes pueden reorganizar las prioridades de los siguientes sprints. No pueden reorganizar el sprint en proceso (eso es una locura) pero todos los siguientes sprints son candidatos para cambiar las prioridades.

Si el cliente maneja, los plazos se vuelven menos artificiales " hitos del proyecto " y más " necesitamos X primero, luego Y, y esto en la sección Z, ya no lo necesitamos más. Ahora que tenemos W, Z es redundante. & Quot;

Answer 5

Las reglas de Scrum dicen que todos los elementos de Sprint deben ser " totalmente probados, características potencialmente implementables " al final del Sprint para ser considerado completo. Los Sprints terminan SIEMPRE a tiempo, y el Equipo no obtiene crédito y no se le permite presentar nada en la revisión de Sprint que no esté completo, e incluye el control de calidad.

Técnicamente, eso es todo lo que necesitas. Un equipo se compromete a una cierta cantidad de trabajo, finalmente lo pone en control de calidad dos días antes del final del Sprint y el control de calidad no se realiza a tiempo. Por lo tanto, la salida del Sprint es cero, tienen que ir delante del Cliente y admitir que no tienen nada que mostrar durante un mes de trabajo.

La próxima vez, apostará a que elegirán menos trabajo y descubrirán cómo llevarlo al control de calidad para que pueda terminarse a tiempo.

Answer 6

Hablando como control de calidad que ha trabajado en proyectos Agile durante 2,5 años, este es un tema realmente difícil y todavía no tengo todas las respuestas.

Trabajo como parte de un " triplet " (dos desarrolladores que combinan el programa + un control de calidad) y estoy involucrado en la preparación de historias y la estimación en la planificación de reuniones al comienzo de las iteraciones de dos semanas. Como adrianh mencionó anteriormente, es esencial que los QA se hagan escuchar en la planificación inicial del sprint. Esto puede ser difícil, especialmente si trabaja con Desarrolladores con personalidades muy fuertes, sin embargo, los QA deben ser asertivos en el verdadero sentido de la palabra (es decir, no son agresivos ni enérgicos, pero buscan respetuosamente entender la Verdad / PO y los Desarrolladores / expertos técnicos mientras se hacen ellos mismos) entendido). Yo abogo por la producción de tareas de control de calidad en primer lugar durante la planificación para fomentar una mentalidad basada en pruebas: el control de calidad puede tener que literalmente adelantarse para que esto sea adoptado. Es opuesto a cuánta gente cree que el desarrollo de software funciona, pero paga dividendos por varias razones;

1. El control de calidad se escucha y no se relega a que se le pregunte " ¿cómo va a probar eso? " después de que Devs haya dicho su pieza (mentalidad de cascada).

2. Le permite a QA proponer ideas para realizar pruebas que, al mismo tiempo, verifican la verificabilidad de los criterios de aceptación mientras la Verdad / PO está presente (dije que es esencial que estén presentes en la reunión de planificación no 't I ?!) para llenar cualquier hueco en la comprensión.

3. Proporciona la base para un enfoque basado en pruebas: después de que se haya enunciado y asignado la tarea, los Devs pueden pensar en cómo producirán el código para aprobar esas pruebas.

4. Si los pasos 1 a 3 son su única actividad de TDD para el resto de la iteración, todavía lo está haciendo un millón de veces mejor que el escenario postulado por Steve en la primera publicación; " Los desarrolladores se debaten tratando de cumplir sus tareas. En general, las tareas toman la mayor parte del sprint para completar. QA acosa a Dev para que libere algo que puedan probar, Dev finalmente lanza un código de buggy a QA uno o dos días antes de que termine el sprint y pasa el resto del tiempo corrigiendo errores que QA está encontrando "

No hace falta decir que esto viene con algunas advertencias para el control de calidad;

1. Deben estar preparados para que sus ideas para pruebas sean cuestionadas por Devs y Truth / PO y para llegar a un compromiso; la " policía QA " La actitud no se lavará en un equipo ágil.

2. Las tareas de control de calidad deben tener un equilibrio difícil para que no sean ni demasiado detalladas ni demasiado genéricas (las tareas se pueden escribir en una tarjeta para ir a la "placa del radiador" y se deben discutir en las reuniones de pie diarias, deben ser movido de " en progreso " a " completado " DURANTE la iteración).

3. Los QA deben prepararse para las reuniones de planificación / estimación. ¡No espere poder simplemente aparecer y producir un enfoque de prueba desde la parte superior de su cabeza para historias de usuarios invisibles! Los desarrolladores parecen ser capaces de hacer esto porque sus tareas a menudo son mucho más claras, por ejemplo. " cambiar x módulo para interactuar con el componente z " o " método de refactor y " ;. Como control de calidad, debe estar familiarizado con la funcionalidad que se está introduciendo / cambiando ANTES de planificar para que conozca el alcance de las pruebas y las técnicas de diseño de pruebas que podría aplicar.

4. Es casi esencial automatizar sus pruebas y tenerlas escritas y " que fallan " dentro de los primeros dos o tres días de una iteración o al menos co-incidir cuando los Devs tengan el código listo. Luego puede ejecutar la / s prueba / s y ver si pasan como se esperaba (QA TDD adecuada). Así es como se evita una mini cascada al final de las iteraciones. Realmente deberías mostrar la prueba a los Devs antes o cuando empiecen a programar para que sepan a qué apuntar.

5. Yo digo que 4 es " casi esencial " porque a veces se puede lograr lo mismo con listas de verificación manuales (¡me atrevería a decir scripts!) del comportamiento esperado - la clave es compartir esto con Devs antes de tiempo; ¡Sigue hablando con ellos!

Con respecto al punto 2 anterior sobre el tema de las tareas, he intentado crear tareas tan granulares como de 1/2 hora a 2 horas cada una correspondiente a una pieza de trabajo demostrable, por ejemplo. " Agregar comprobaciones de contraseña incorrecta a prueba automática - 2 hrs " ;. Si bien esto me ayuda a organizar mi trabajo, ha sido criticado por otros miembros del equipo por ser demasiado detallado y tiene el efecto de ser parte de mí, ya sea moviendo múltiples tareas para completar desde el día anterior o no poder mover ninguna tarea en absoluto porque No los he subido todavía. La gente realmente desea ver una sensación de progreso constante en las paradas diarias, por lo que es más útil crear tareas en bloques de 1/2 día o 1 día (pero es posible que tenga su propia lista de "tareas de micro" para hacer hacia). completar las tareas más grandes que utiliza para COMUNICAR el progreso general en el stand-up).

Con respecto a los puntos 4 y 5 anteriores; Las pruebas automáticas o las listas de verificación manuales que prepara con anticipación deberían cubrir solo los caminos felices o los criterios de aceptación clave. Una vez que se hayan aprobado, puede haber planificado una tarea adicional para una ronda final de " Pruebas exploratorias " hacia el final de la iteración para comprobar los casos de borde. Lo que hacen los Devs durante ese tiempo es problemático porque, en lo que a ellos respecta, están " código completo " A menos y hasta que encuentre un error. Algunos profesionales de Agile abogan por ir primero a los casos más avanzados, aunque esto también puede ser problemático, ya que si te quedas sin tiempo es posible que no hayas asegurado que se hayan cumplido los criterios de aceptación. ¡Esta es una de esas decisiones finamente equilibradas que dependen del contexto de la historia del usuario y su experiencia como control de calidad!

Como dije al principio, todavía no tengo todas las respuestas, ¡pero espero que lo anterior proporcione algunos consejos que surgen de una experiencia difícil!

Answer 7

Parece que su equipo de desarrollo podría no estar haciendo suficientes pruebas por su cuenta, antes del lanzamiento al control de calidad. Si todas las pruebas de unidad pasan, el ciclo de control de calidad debería ser relativamente suave, ¿no? Encontrarán algunos errores de integración, pero no debería haber muchos de ellos, ¿no?

Answer 8

Creo que hay varios problemas aquí. Primero, creo que quizás las tareas del desarrollador no sean lo suficientemente detalladas, o quizás no se hayan estimado bien, o quizás ambas cosas. Todo el propósito de los sprints en Scrum es poder demostrar un código funcional al final de los sprints. Los dos problemas que mencioné podrían llevar a un código de buggy.

Si los desarrolladores lanzan código de buggy hacia el final del sprint, también vería:

• ¿Los propietarios de los productos realmente hacen que los miembros dev sean responsables de cumplir con sus tareas? Ese es el trabajo de la orden de compra y, si eso no sucede, los desarrolladores se relajarán.
• ¿Están los desarrolladores utilizando cualquier tipo de TDD? Si no, eso podría ser de gran ayuda. Pon a los desarrolladores en el hábito de probar su código. Tenemos este problema en el que trabajo, y mi equipo está enfocado en hacer el TDD en las áreas importantes para que no tengamos que hacer que otra persona lo haga más adelante.
• ¿Son las historias de tareas / usuarios demasiado genéricas? El espacio de maniobra en las tareas desglosadas hará que los desarrolladores sean descuidados. De nuevo, esto es un problema de PO.

Una idea que he escuchado en el pasado es usar a una persona de control de calidad como scrummaster. Estarán presentes en los enfrentamientos diarios y pueden tener una idea de dónde están las cosas con los desarrolladores. Pueden abordar los problemas con la OP (suponiendo que la OP puede hacer su trabajo adecuadamente).

No puedo evitar sentir que necesitas más coorporación entre QA y tus equipos de scrum. Parece que las pruebas solo ocurren al final, lo cual es un problema. Lograr que el control de calidad sea parte del equipo ayudará a identificar las cosas que se pueden probar antes y mejor.

También siento que tienes un problema con el propietario del producto. Deben estar allí asegurándose de que todos estén conduciendo en la dirección correcta. deberían asegurarse de que exista una buena cooperación, no solo entre QA y los desarrolladores, sino entre los mismos desarrolladores.

Answer 9

  

" ¿Cómo se supone que funciona scrum cuando se puede liberar Dev?   ¿Las tareas ocupan la mayor parte del sprint? "

Como ya descubrió, no funciona muy bien :-) El proceso que está describiendo no me suena como Scrum para mí, o al menos no es como si Scrum se haya hecho bien.

No estoy seguro de lo que describió si la gente de control de calidad es parte del equipo, o de un grupo separado.

Si son un grupo separado, esto probablemente sea una gran parte del problema. No participarán en el compromiso del equipo para completar las tareas, y en la negociación del alcance asociado con el propietario del producto. Nunca he visto a un grupo ágil tener éxito sin que sean habilidades de control de calidad en el equipo. Ya sea por tener desarrolladores con muchas habilidades de prueba / control de calidad, o por tener una persona de control de calidad integrada o tres en el equipo.

Si están en el equipo, entonces necesitan que su voz se escuche más en la planificación inicial del sprint. A estas alturas, debe quedar claro para el propietario y el equipo del producto que usted está comprometiéndose demasiado.

Probaría algunas cosas si fuera yo:

• Obtenga personal de control de calidad / pruebas en el equipo si aún no están allí
• Tenga una buena conversación larga con el propietario del producto & amp; el equipo sobre lo que cuenta como " hecho " ;. Parece que algunos de los desarrolladores aún se encuentran en la mentalidad previa al scrum de " entregado a QA " " == hecho.
• Divida las historias en partes más pequeñas: facilita la detección de errores de estimación
• Considere correr sprints más cortos, porque poco y más a menudo es más fácil de rastrear y aprender.

También puede encontrar estos consejos sobre cómo suavizar la quema de un scrum .

Answer 10

Resolvimos este problema de la siguiente manera: - Cada artículo en la cartera de productos debe tener criterios de ajuste o aceptación, Sin eso, no empezamos un sprint. - Un evaluador forma parte de nuestro equipo. Para cada elemento de la cartera de productos, crea tareas de prueba (1 o más, según los criterios de aceptación) junto con una estimación y un enlace al elemento para probar. - Durante el scrum diario, todas las tareas que se terminan se colocan en una columna 'Para probar' - Nunca hacemos tareas que duren más de 16 horas; Las tareas que se estiman más largas, se dividen

Answer 11

Divida las tareas en tareas más pequeñas.

También, el control de calidad puede crear casos de prueba para que Dev los pruebe.

Answer 12

Una idea a considerar es hacer que el control de calidad trabaje una iteración detrás del desarrollo principal. Eso funciona bien en nuestro entorno.

Answer 13

Aquí diría que, Una talla no se ajusta a todas. Cada equipo trata el control de calidad de manera diferente. Depende mucho del proyecto en el que estés trabajando, ya sea uno pequeño o uno grande. ¿Necesita una regresión extensa, aceptación del usuario y pruebas exploratorias o tiene bastantes pocos escenarios para probar? Permítanme reiterar que en Agile, los generalistas son los preferidos de los especialistas. ¿Que es eso? Porque hay tiempo durante el proyecto cuando no tienes nada para probar, por lo que en ese momento podrías estar haciendo otra cosa. También es posible que estés haciendo pruebas aunque seas un programador de núcleo duro.

¿Cómo lo manejamos? Tenemos sprint regular de 2 semanas. Las pruebas comienzan después de una semana en la tarea completada por los desarrolladores durante la semana. Ahora, el probador sigue agregando problemas a nuestro Rastreador de problemas y los desarrolladores que han terminado con sus tareas de sprint comienzan a seleccionar esos errores. Al final del sprint, en general, hemos terminado con nuestra tarea de sprint y todos los errores importantes y críticos.

Entonces, ¿qué hace el probador dos en la primera semana del sprint?

Bueno, siempre hay cosas para probar. Tenemos tareas de prueba en el registro, que pueden incluir algunas pruebas exploratorias. Muchas personas no valoran las pruebas exploratorias, pero eso es extremadamente importante para construir productos de calidad. Los buenos evaluadores crean tareas para sí mismos y encuentran las posibilidades donde las cosas van mal y las prueban.

Espero que ayude!