is there any start stop boundary qa s role scrum
Cuál es el papel de QA en Scrum: actividades de Scrum para los testers
Este artículo no es solo un tutorial sobre algunos procesos o métodos o instrucciones sobre cómo trabajar como QA. Más bien, este es un artículo en el que quiero compartir mi propia experiencia de trabajo como Senior QA en SCRUM.
Mi CTO anterior siempre solía decir que 'Con la libertad viene la responsabilidad'. Si se le da la libertad de hacer su trabajo a su manera, entonces es usted y solo usted quien es responsable de su trabajo o tareas o actividades.
¡¡De esto se trata Scrum !! Déjame darte una idea básica sobre Scrum a medida que avanzamos.
Lo que vas a aprender:
Descripción general de Scrum
Scrum es un subconjunto del metodología ágil y es un marco de proceso ligero que se utiliza ampliamente.
Scrum nos ayuda a mantener contentos a los clientes dándoles el producto en pequeños módulos, también mantiene al cliente consciente de que sus requisitos que cambian con frecuencia pueden ralentizar las actividades. Los lanzamientos son cortos y el trabajo se realiza según la capacidad del equipo involucrado, por lo que las posibilidades de fallas o clientes insatisfechos se reducen en gran medida.
Por otro lado, los requisitos (en este caso, las historias de usuario) se finalizan antes de que comience el Sprint para evitar que se vuelva a trabajar y, por lo tanto, resulte en un Sprint retrasado o fallido (las excepciones siempre están ahí).
Pero el mayor desafío para un control de calidad es que el período de lanzamiento es corto, un Sprint es principalmente un ciclo de 15 días. Por lo tanto, entregar un producto 'libre de errores' en un máximo de 4-5 días (eliminando el tiempo de desarrollo) requiere muchos esfuerzos y pensamiento inteligente.
Soy el QA de mi equipo:
Oh sí, soy el QA de mi equipo y soy un jugador importante de mi equipo. ¿¿Por qué?? Porque los clientes, BA, Scrum Master y todos los demás están confusos acerca de la calidad, la apariencia y el rendimiento de la aplicación o producto.
En Scrum, como la duración del sprint es corta, el control de calidad tiene que funcionar de manera inteligente y, por lo tanto, la necesidad de que el control de calidad se involucre desde el principio, la 'planificación' se vuelve muy importante. Hay ocasiones en las que un QA puede desempeñar el papel de propietario de un producto proxy cuando la orden de compra no está disponible, lo que ayuda al BA a crear los escenarios / casos de prueba de criterios de aceptación.
Los desarrolladores también se acercan al control de calidad cuando se enfrentan a problemas con la funcionalidad o las reglas comerciales. En Scrum, el enfoque está solo en tener un lanzamiento de Sprint fluido y exitoso y no se trata de 'Mi trabajo' o 'Tu trabajo' para ayudar cuando tu equipo se acerca a ti en busca de ayuda.
En la vinculación del equipo Scrum, las relaciones saludables entre los miembros del equipo juegan un papel muy importante y, al ser un QA, debe tener mucho cuidado al comunicar su opinión sobre las historias de usuario que está probando. Su comunicación debe ser sobre la historia del usuario o la funcionalidad y no sobre la persona que trabajó en ella.
En Scrum, QA no es juzgado ni apreciado por la cantidad de errores que descubre, sino también por cómo está interactuando con el equipo, ayudando al equipo y motivando al equipo incluso en momentos difíciles.
Además de probar las tareas de Sprint, la redacción de planes de prueba / casos de prueba / documentos de lanzamiento también intenta involucrar más porque la duración del lanzamiento del Sprint es corta y el objetivo es el mismo para todos. “Para entregar un producto que funcione sin errores con éxito ayudándonos unos a otros”.
Un QA está involucrado en casi todas las actividades que se llevan a cabo en un Sprint y técnicamente no hay límites para el inicio o la parada de las actividades de QA. A diferencia del modelo Waterfall tradicional, donde el control de calidad solo se limita a probar el lanzamiento, aquí el control de calidad tiene muchas más responsabilidades. Por lo tanto, sugeriría probar y hacer más de las siguientes actividades.
Actividades a seguir
A continuación se presentan algunas actividades que le sugiero que siga como QA en Scrum.
descarga gratuita de dvd ripper para windows 10
# 1) Permanezca más profundo:
Con esto quiero decir que cuando las historias de usuario y sus criterios de aceptación estén listos, estúdialos a fondo y piensa más en profundidad sobre las dependencias, los resultados ocultos y si hay una mejor manera de hacerlo.
Comuníquese y colabore con el BA y el equipo de desarrollo sobre esto porque puede suceder que ellos tampoco hayan pensado en esto. Comparta sus ideas y hallazgos con el equipo.
Si encuentra que hay obstáculos ocultos o impactos negativos, entonces plantearlos con el Scrum Master y la gente de desarrollo les dará tiempo para pensar y actuar en consecuencia. Esta actividad en Scrum se vuelve muy crítica cuando el proyecto es a gran escala y cuando hay módulos repartidos por los equipos.
Ahora bien, mientras se estudia sobre las dependencias, un impacto es muy importante para un QA e incluso hace que el equipo de desarrollo sea consciente de lo mismo. Para hacer esto, discuta con los QA de los otros equipos y obtenga información de ellos.
# 2) Involucrar en estimaciones:
La práctica habitual es involucrar un QA en las estimaciones, pero muchas veces debido al pequeño sprint, es posible que no se le pida al QA una estimación para probar las tareas y dejarlas con 3/4/5 días para el trabajo de prueba.
Nunca aceptes esto. Levante la voz si es necesario, pero asegúrese de proporcionar su estimación de prueba, que debe incluir el tiempo que necesita para cada trabajo.
Puede incluir tiempo para la investigación, tiempo para configuraciones, tiempo para recopilar datos históricos, etc., pero sea estricto y específico sobre el tiempo requerido para llevar a cabo las actividades de prueba y agregue estos valores de tiempo a la historia del usuario junto con el tiempo de las tareas de desarrollo. .
Esto es muy importante porque si intentas hacer tu trabajo en el tiempo asignado y no puedes completarlo, solo tú serás responsable de la falla. Cuando se agrega el tiempo de QA, el Scrum Master, el PO estará al tanto de las actividades de QA involucradas y la cantidad de tiempo requerido.
# 3) Emparejamiento de Dev QA:
Idealmente, en Scrum, las historias de usuario de Sprint se entregan para probar después de que se completa el desarrollo y una vez que se han realizado las pruebas de desarrollo, pero el problema aquí es que para cuando se entregan al control de calidad para que las prueben apenas entre 4 y 5 días a la demostración o revisión permanecen.
Ahora, si como QA descubre incluso 4 bloqueadores o fallas funcionales, tendrá que trabajar hasta tarde en la noche o el fin de semana para cumplir con su fecha de lanzamiento, ya que habrá pruebas funcionales, regresiones, etc., por hacer. Este parece el modelo de cascada tradicional que no es la mejor manera de hacerlo, en Scrum la forma más inteligente es “Prevenir defectos en lugar de encontrar defectos”.
Por lo tanto, la solución es hacer un emparejamiento de QA de desarrollo y realizar una ronda básica de pruebas en la configuración de desarrollo tan pronto como los desarrolladores estén listos con las historias incluso antes de un lanzamiento formal para las pruebas.
Se pueden tener en cuenta los siguientes criterios para realizar un BVT en la configuración del desarrollador para las historias de usuario:
- Criterios de aceptación para cada historia de usuario: BVT de las historias de usuario de acuerdo con los criterios de aceptación.
- Falta de confianza en los desarrolladores: A veces, los desarrolladores no confían en algunas implementaciones y, por lo tanto, discuten tales implementaciones y hacen un BVT para aquellos en la misma configuración de desarrollo.
- Dependencias / Pruebas de impacto: BVT de las dependencias o impacto sobre / de los otros módulos de las nuevas implementaciones.
- Examen de la unidad: Haga un BVT con el desarrollador de las pruebas unitarias que ha creado, si es necesario ayúdelo agregando o actualizando las pruebas unitarias.
Esto ayudará a reducir el ir y venir de los errores, ahorrará tiempo a todos, ya que antes del lanzamiento al control de calidad, la mayoría de los errores funcionales o bloqueados ya están corregidos. Recuerde registrar esos defectos en sus herramientas antes de la revisión del sprint y hacer que se muevan hasta el estado 'cerrado'.
# 4) Control de calidad en la pizarra:
Siempre he animado personalmente a mi equipo a incluir tareas de control de calidad en el tablero de White Scrum, incluidos los errores también. Esto ayuda al Scrum Master a averiguar el estado de QA de una historia de usuario simplemente mirando el tablero.
El no. de errores en la lista de tareas pendientes, los errores de la lista en curso, las actividades de control de calidad en las listas de tareas pendientes, en curso y terminadas hablan por sí solas. Me resulta realmente doloroso cuando alguien me pregunta sobre el estado de las pruebas de historias individuales para un Sprint porque tengo que dedicar más tiempo a sacar mi estado de la compilación de herramientas y mostrarles o redactar un correo electrónico.
Simplemente prefiero señalar a la persona al Scrum Board y dejar que lo haga por sí mismo. Prefiera un color sobresaliente brillante para las hojas adhesivas QA.
# 5) Documentación:
Este es uno de los inconvenientes o desventajas de Scrum: debido al pequeño tamaño de Sprint, no hay mucho tiempo para la documentación y nunca he visto un escritor técnico en un equipo Scrum. El Scrum Master / BA no puede actualizar y no siempre actualiza los documentos sobre la información del producto.
El problema surge si se unen nuevos miembros o, en el peor de los casos, si las reglas de negocio, las funcionalidades cambian y cómo realizar un seguimiento de ellas, porque buscar información en las historias de usuario 'Hecho' será como buscar una aguja en un pajar.
La solución es tener una tarea separada creada en un sprint siempre que sea posible (principalmente en tiempos de inactividad o cuando la carga de trabajo es muy menor) para la documentación, de modo que pueda revisar los documentos y actualizarlos o hacer que Scrum Master o BA los actualicen.
Un QA es la persona adecuada para ayudar a actualizar los documentos porque usted es quien prueba, verifica las historias de los usuarios y conoce la funcionalidad dentro y fuera. Hágalo usted mismo si no hay BA y si su Scrum Master está ocupado para actualizar.
# 6) Revisión de Sprint / Demo de Sprint:
La mayoría de las veces sucede que el QA es el elegido para dar la demostración al PO y las partes interesadas. pero si no persuade a su Scrum Master para que lo haga. Un QA es la persona adecuada para dar la demostración, ya que ha probado la historia del usuario dentro y fuera.
Un QA puede hacer una demostración desde el punto de vista comercial porque conoce las funcionalidades, los flujos y las reglas comerciales. Prepárese bien para la demostración y trate de responder todas y cada una de las preguntas que tengan la OP y las partes interesadas. Esto te ayudará a convertirte en el punto de contacto para ellos en ausencia del Scrum Master y BA.
# 7) Actúa como un BA:
Esta no es una tarea regular y ni siquiera se espera de un QA, pero intente desempeñar este papel cuando se presente una oportunidad porque un QA es la mejor persona para ser un BA. Por ejemplo, intente pensar y visualizar si los flujos, funcionalidades o reglas de negocio pueden modificarse de forma que beneficien al cliente.
Piense y busque las tendencias actuales en la interfaz de usuario, la apariencia de la aplicación y cómo se puede beatificar, hacer más fácil de usar, etc. Si el equipo está atascado en algún problema, involúcrese e intente dar una respuesta simple e inteligente. solución. Esto dará un impulso a su rol y será un factor para contribuir al crecimiento de su carrera.
Las posibilidades surgen durante las llamadas con el PO cuando se discuten algunos problemas o en una revisión / demostración donde puede dar sugerencias.
Conclusión
Scrum es una metodología muy diferente del método Waterfall normal, y el Scrum Master es un facilitador. Por lo tanto, no espere que él / ella defina sus actividades por usted.
En Scrum, no hay límites de inicio y fin para el rol de un QA. QA necesita y debe estar involucrado en cada actividad desde el principio hasta el final, desde la planificación previa hasta la revisión / demostración del sprint y debe participar en todas las actividades.
Esto ayudará a comprender el producto o la aplicación ya que (como dije antes) no hay documentación adecuada disponible cuando se trabaja en Scrum. Se espera que sea responsable, motivado y proactivo. Por lo tanto, no espere a que alguien venga y le diga qué o cómo se supone que debe hacer.
Debe tomar iniciativas por su cuenta, ayudar al equipo de todas las formas posibles, mantener una relación saludable, realizar un seguimiento de las cosas en curso en el equipo y, lo más importante, tener claras sus tareas en un sprint determinado.
Aquí, no hay gerentes que lo monitoreen o mantengan un registro de sus actividades. Esté siempre listo para ayudar a su equipo y obtendrá la mejor de las oportunidades.
Siéntase libre de expresar sus pensamientos / sugerencias sobre este artículo informativo en la sección de comentarios a continuación.
Lectura recomendada
- Rol de los analistas de negocios en SCRUM y ¿Por qué es mejor un control de calidad para este rol?
- Cuestionario en línea de Agile Scrum: Pon a prueba tu conocimiento de Agile Scrum
- Instale su aplicación en el dispositivo y comience a probar desde Eclipse
- Kanban vs Scrum vs Agile: una comparación detallada para encontrar diferencias
- Cómo ofrecer funciones de software de alto valor en un corto período de tiempo utilizando Agile Scrum Process
- Manifiesto ágil: comprensión de los valores y principios ágiles
- Triaging de defectos en Scrum: cómo se organiza en una configuración de Scrum
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)