¿Los probadores de control de calidad tienen que seguir estrictamente sus sprints?

Mi equipo de desarrollo está formado por:

2 desarrolladores 1 probador de control de calidad 1 maestro Scrum (yo)

Actualmente el QA tester es parte del equipo scrum, sin embargo no lo hago seguir un sprint estricto por no tener mucho trabajo. Mientras que protejo al equipo de desarrollo de la interferencia externa, ya que tienen mucho trabajo por hacer.

Dado que solo está activo una vez que se ha completado el trabajo, que generalmente es al comienzo o al final del día, realiza otras tareas cuando está inactivo. Por lo tanto, acabamos de establecer un tiempo al comienzo y al final del día de 1 hora para realizar el control de calidad.

¿Esta bien?

Haz que hagan pruebas de regresión. pronto se quedarán sin tiempo en el día

Respuestas (3)

Esto va a depender en gran medida de su entorno de trabajo.

En mi experiencia, el control de calidad puede respaldar a un equipo de 3 a 5 desarrolladores, por lo que su control de calidad definitivamente está infrautilizado. Esto se puede abordar agregando más desarrolladores a su equipo / distribuyendo el control de calidad en varios equipos.

Más allá de la asignación de recursos; su control de calidad puede hacer más que solo probar la funcionalidad entregada durante el transcurso del sprint. Ellos pueden:

  1. Escriba casos de prueba para el trabajo que se entregará durante el sprint.
  2. Escribir pruebas de automatización para la aplicación.
  3. Configurar datos de prueba para el sprint actual
  4. (No se considera tradicionalmente) Incluya el control de calidad en la recopilación de requisitos / planificación previa del sprint, ya que a menudo podrán hacer agujeros en las historias que no se consideran.

También puede valer la pena hacer esta pregunta en el sitio de preguntas y respuestas sobre pruebas y control de calidad del software .

Estoy de acuerdo en que QA puede expandir sus actividades dependiendo de sus habilidades, pero no sé cómo llegó a: "QA puede admitir un equipo de más de 4 desarrolladores". Cada proyecto es diferente en tecnología, requisitos y personas involucradas y creo que no debemos hacer tal generalización.
Es un probador de usabilidad, no un probador que escribe código, es decir, un probador de automatización. Lo que significa que solo puede probar las funcionalidades una vez que el equipo de desarrollo lo haya escrito.
@bobo2000: Eso solo descarta el punto 2 del posible trabajo adicional. Y siempre puede preguntarle al probador si está dispuesto a aprender eso (podría ser más fácil si la automatización de la prueba usa un marco de trabajo de alto nivel en el que no se siente como si estuviera escribiendo código).
@MasterPJ La declaración se basa en mi experiencia trabajando en/con equipos scrum. He modificado la declaración para reflejar con mayor precisión esa experiencia.

Los equipos de Scrum deben trabajar de manera interfuncional. Si los evaluadores solo prueban después de que se realiza el desarrollo, se quedan atrás. Esto podría conducir a situaciones en las que el trabajo está "Terminado" pero no probado al final del sprint. ¿Ahora el probador va a probarlo en el próximo sprint? y los problemas se solucionan adhoc? Esto elimina todo el enfoque en una idea de Sprint.

Lo que sugieres suena como una mini-cascada , donde las disciplinas se esperan unas a otras.

Los probadores deben trabajar en paralelo con el equipo que prepara las pruebas y las implementa, preferiblemente de forma automatizada. Cuando el trabajo esté terminado, cualquiera debería poder verificar/probar el trabajo terminado. Haga esto antes de que alguien comience un nuevo trabajo, termine la historia de usuario por historia de usuario con todo el equipo. Los desarrolladores también pueden probar y los evaluadores también pueden codificar, hacer UX, documentar o cualquier otra tarea necesaria para terminar una historia de usuario. Use al probador como el experto en pruebas en el equipo en lugar de ser el único responsable de las pruebas. El equipo es responsable de la calidad, no solo el probador.

Lea el libro Agile Testing o deje que sus evaluadores realicen el curso Certified Agile Tester .

El evaluador de mi equipo es un evaluador de usabilidad, en realidad no está escribiendo código, es decir, pruebas automatizadas, etc. En realidad, ni siquiera está capacitado en eso.
Entonces, ¿solo prueba la usabilidad? y nada funcional? Lo llamaste un probador de control de calidad en tu pregunta, un poco confundido. Pero en su tiempo de inactividad actual, podría intentar aprender por sí mismo o, de lo contrario, comenzaría a buscar otro probador que pueda hacerlo. Alguien que solo es un probador manual no encaja en un pequeño equipo de Scrum si me preguntas.
Sí, eso es lo que estoy haciendo. En su tiempo libre, realiza otras tareas no relacionadas con el trabajo de los equipos de desarrollo.

En Scrum no existe el rol de probador. En la Guía Scrum está escrito:

Scrum no reconoce títulos para los miembros del Equipo de Desarrollo que no sean Desarrollador, independientemente del trabajo que realice la persona; No hay excepciones para esta regla;

Debe mantener el control de calidad dentro del Sprint para asegurarse de que después de cada Sprint tenga un producto potencialmente liberable . Sin QA, la prueba no se realiza y el incremento no se realiza.

Además, al hacer cumplir el trabajo en las funciones una por una en lugar de en paralelo y terminarlas todas a la vez al final del Sprint

  • su control de calidad tendría algo que hacer todo el tiempo,
  • El equipo de desarrollo descubrirá los errores antes y tendrá tiempo para solucionarlos.
  • El equipo de desarrollo tendrá un mejor control sobre lo que se puede terminar y lo que no.

En caso de que todavía haya algo de tiempo libre para el QA, debe mejorar sus habilidades para ser más útil en otras actividades.

hacer que los controles de calidad generen errores de cambio de especificaciones en el trabajo en progreso puede matar un sprint
@Ewan ¿Qué quieres decir? al comienzo del sprint, todas las personas deben comprender cuál debe ser el resultado de cada historia de usuario. ¿Podrías ser un poco más específico?
¿Nunca ha estado en la situación en la que el control de calidad genera 'errores' que, aunque los comentarios son perfectamente válidos, no están en la especificación? es decir, "si el menú es de ese color, choca con el fondo" cuando no se ha especificado el color del menú. El PO estará de acuerdo en que tienen razón y el error se colocará en medio del sprint, pero efectivamente es un trabajo adicional no planificado.
Claro, estas cosas pasan. De vez en cuando nos olvidamos de especificar algo, o no nos damos cuenta de algo y surge durante el sprint y provoca trabajo adicional no previsto. Pero creo que eso es normal, no puedes evitar eso sin importar lo que hagas. Además, cada vez que esto sucede es un punto potencial de aprendizaje. Y cuanto antes comience la prueba de control de calidad, antes lo sabremos. No ayudaría terminar la función de acuerdo con la especificación si no funciona.
La forma correcta es agregar la nueva función al siguiente sprint. claro, escribir la especificación es difícil, pero el objetivo de correr es hacer las cosas por pasos. Si solo prueba las historias completadas que se aplican
¿Los probadores de control de calidad tienen que seguir estrictamente sus sprints?
RespuestasAquíPolítica de privacidad1y, 0v