is there any start stop boundary qa s role scrum
Quel est le rôle du contrôle qualité dans Scrum: activités Scrum pour les testeurs
Cet article n'est pas seulement un didacticiel sur certains processus ou méthodes ou des instructions sur la façon de travailler en tant que QA. Il s'agit plutôt d'un article dans lequel je souhaite partager ma propre expérience de travail en tant que Senior QA chez SCRUM.
Mon ancien directeur technique disait toujours que «Avec la liberté vient la responsabilité». Si vous avez la liberté de faire votre travail à votre manière, c'est vous et vous seul qui êtes responsable de votre travail ou de vos tâches ou activités.
C'est ce qu'est Scrum !! Permettez-moi de vous donner une idée de base sur Scrum au fur et à mesure que nous progressons.
Ce que vous apprendrez:
Présentation de Scrum
Scrum est un sous-ensemble du méthodologie agile et est un cadre de processus léger qui est largement utilisé.
Scrum nous aide à garder les clients heureux en leur donnant le produit en petits modules, il tient également le client conscient que leurs exigences fréquemment changeantes peuvent ralentir les activités. Les versions sont courtes et le travail est pris en fonction de la capacité de l'équipe impliquée, d'où les risques d'échec ou de clients mécontents sont réduits dans une large mesure.
D'autre part, les exigences (dans ce cas les User Stories) sont finalisées avant le début du Sprint afin d'éviter les retouches et donc cela entraîne un Sprint retardé ou échoué (les exceptions sont toujours là).
Mais le plus grand défi pour un QA est que la durée de publication est courte, un Sprint est principalement un cycle de 15 jours. Par conséquent, livrer un produit «sans bogue» en 4 à 5 jours maximum (en supprimant le temps de développement) nécessite beaucoup d’efforts et une réflexion intelligente.
Je suis le QA de mon équipe:
Oh oui, je suis le QA de mon équipe et je suis un joueur important de mon équipe. Pourquoi?? Parce que les clients, les BA, Scrum Master et tout le monde sont flous sur la qualité, l'apparence et la performance de l'application ou du produit.
Dans Scrum, comme la durée du sprint est courte, le contrôle qualité doit fonctionner de manière intelligente et par conséquent le besoin du contrôle qualité d’être impliqué dès le début, la «planification» devient très important. Il y a des moments où un AQ peut jouer le rôle d'un propriétaire de produit proxy lorsque le bon de commande n'est pas disponible, aidant ainsi le BA à créer les scénarios / cas de test des critères d'acceptation.
Les développeurs abordent également le contrôle qualité à des moments où ils rencontrent des problèmes avec les fonctionnalités ou les règles métier. Dans Scrum, l'objectif est uniquement d'avoir une version de Sprint fluide et réussie et il ne s'agit pas de 'Mon travail' ou 'Votre travail' pour donner un coup de main lorsque votre équipe vous demande de l'aide.
Dans le lien d'équipe Scrum, des relations saines entre les membres de l'équipe jouent un rôle très crucial et en tant que QA, vous devez être très prudent lorsque vous communiquez votre opinion sur les user stories que vous testez. Votre communication doit porter sur la user story ou la fonctionnalité et non sur la personne qui a travaillé dessus.
Dans Scrum, l'assurance qualité n'est pas jugée ou appréciée pour le nombre de bugs qu'il / elle découvre mais aussi sur la façon dont il / elle interagit avec l'équipe, aidant l'équipe et motivant l'équipe même dans les moments difficiles.
En plus de tester les tâches de sprint, la rédaction de plans de test / cas de test / documents de publication essaie également d'en impliquer davantage car la durée de publication du Sprint est courte et l'objectif est le même pour tout le monde «Pour livrer avec succès un produit fonctionnel sans bogue en s'aidant les uns les autres».
Un AQ est impliqué dans presque toutes les activités réalisées dans un Sprint et techniquement, il n'y a pas de limite pour le démarrage ou l'arrêt des activités d'AQ. Contrairement au modèle Waterfall traditionnel où le QA se limite uniquement à tester la version, le QA a ici beaucoup plus de responsabilités. Donc, je suggérerais d'essayer et de faire plus des activités suivantes.
Activités à suivre
Vous trouverez ci-dessous quelques activités que je vous suggère de suivre en tant que QA dans Scrum.
comment trouver le code de sécurité de mon réseau
# 1) Vivez plus profondément:
Par cela, je veux dire que lorsque les user stories et leurs critères d'acceptation sont prêts, étudiez-les en profondeur et réfléchissez plus en profondeur aux dépendances, aux résultats cachés et s'il existe une meilleure façon de le faire.
Communiquez et collaborez avec le BA et l'équipe de développement à ce sujet car il se peut qu'ils n'aient pas non plus pensé à cela. Partagez vos idées et vos découvertes avec l'équipe.
Si vous trouvez qu'il y a des obstacles cachés ou des impacts négatifs, alors les soulever avec le Scrum Master et les développeurs leur donnera le temps de réfléchir et d'agir en conséquence. Cette activité dans Scrum devient très critique lorsque le projet est à grande échelle et lorsqu'il y a des modules répartis dans les équipes.
Maintenant, tout en étudiant les dépendances, un impact est très important pour un contrôle qualité et il rend même l'équipe de développement consciente de la même chose. Pour ce faire, discutez avec les AQ des autres équipes et prenez leur avis.
# 2) Impliquez dans les estimations:
La pratique habituelle est d'impliquer un QA dans les estimations mais souvent en raison du petit sprint, le QA peut ne pas être demandé d'estimation pour tester les tâches et leur laisser 3/4/5 jours pour le travail de test.
N'acceptez jamais cela. Élevez votre voix si vous devez le faire, mais assurez-vous de fournir votre estimation de test qui devrait inclure le temps dont vous avez besoin pour chaque travail.
Cela peut inclure du temps pour la recherche, du temps pour les configurations, du temps pour la collecte des données historiques, etc., mais soyez strict et précis sur le temps nécessaire pour effectuer les activités de test et ajoutez ces valeurs de temps à l'histoire de l'utilisateur avec le temps des tâches de développement. .
Ceci est très important car si vous essayez de faire votre travail dans le temps imparti et si vous ne parvenez pas à terminer, vous serez seul responsable de l'échec. Lorsque le temps d'AQ est ajouté, le Scrum Master, l'OP sera informé des activités d'AQ impliquées et du temps requis.
# 3) Couplage Dev QA:
Idéalement, dans Scrum, les histoires d'utilisateurs Sprint sont remises pour test une fois le développement terminé et une fois les tests de développement terminés, mais le problème ici est qu'au moment où ils sont remis au QA pour des tests à peine 4-5 jours à la démo ou à l'examen restent.
Maintenant, si en tant que QA vous découvrez même 4 bloqueurs ou défaillances fonctionnelles, vous devrez travailler tard dans la nuit ou le week-end pour respecter votre date de sortie car il y aura des tests fonctionnels, des régressions, etc., à faire. Cela semble être le modèle de cascade traditionnel qui n'est pas la meilleure façon de faire, dans Scrum, la manière la plus intelligente est «Évitez les défauts plutôt que de trouver des défauts».
Par conséquent, la solution consiste à effectuer un appariement QA de développement et à effectuer une série de tests de base sur la configuration de développement dès que les développeurs sont prêts avec les histoires avant même une version formelle pour les tests.
Les critères suivants peuvent être pris en compte pour effectuer un BVT sur la configuration de développement pour les user stories:
- Critères d'acceptation pour chaque user story: BVT des user stories conformément aux critères d'acceptation.
- Manque de confiance envers les développeurs: Parfois, les développeurs ne sont pas sûrs de certaines implémentations et par conséquent discutent de ces implémentations et font un BVT pour ceux qui sont sur la même configuration de développement.
- Dépendances / tests d'impact: BVT des dépendances ou impact sur / des autres modules des nouvelles implémentations.
- Test unitaire: Faites un BVT avec le développeur des tests unitaires qu'ils ont créés, si besoin aidez-les en ajoutant ou en mettant à jour les tests unitaires.
Cela aidera à réduire les va-et-vient des bogues, à gagner du temps à tout le monde, car avant la publication de QA, la majorité des bogues en panne ou fonctionnels sont déjà corrigés. N'oubliez pas de consigner ces défauts dans vos outils avant la révision du sprint et de les déplacer jusqu'à l'état «fermé».
# 4) QA sur le tableau blanc:
J'ai toujours personnellement encouragé mon équipe à inclure les tâches d'AQ sur le tableau White Scrum, y compris les bogues. Cela aide le Scrum Master à déterminer le statut QA d'une User Story en regardant simplement le tableau.
Le non. des bogues dans la liste À faire, les bogues dans la liste En cours, les activités QA dans la liste À faire, En cours et Terminé parlent d'eux-mêmes. Je trouve cela vraiment douloureux quand quelqu'un vient me demander l'état des tests d'histoires individuelles pour un Sprint parce que je dois passer plus de temps pour retirer mon statut des outils compiler et les montrer ou rédiger un e-mail.
Je préfère simplement diriger la personne vers le Scrum Board et la laisser s'en sortir elle-même. Préférez une couleur éclatante exceptionnelle pour les feuillets QA Sticky.
# 5) Documentation:
C'est l'un des inconvénients ou inconvénients de Scrum: en raison de la petite taille du Sprint, il n'y a pas beaucoup de temps pour la documentation et je n'ai jamais vu de rédacteur technique dans une équipe Scrum. Le Scrum Master / BA ne peut pas et ne met pas toujours à jour les documents relatifs aux informations produit.
Le problème survient si de nouveaux membres rejoignent ou, dans le pire des cas, si les règles métier, les fonctionnalités changent et comment en garder une trace, car rechercher des informations dans les user stories 'Terminé' reviendra à chercher une aiguille dans une botte de foin.
La solution est d'avoir une tâche distincte créée dans un sprint chaque fois que possible (principalement dans les périodes creuses ou lorsque la charge de travail est très moindre) pour la documentation afin que vous puissiez revoir les documents et les mettre à jour ou faire le Scrum Master ou le BA les mettre à jour.
Un QA est la bonne personne pour aider à mettre à jour les documents parce que vous êtes celui qui teste, vérifie les user stories et connaît les fonctionnalités à l'intérieur et à l'extérieur. Faites-le vous-même s'il n'y a pas de BA et si votre Scrum Master est occupé à se mettre à jour.
# 6) Revue de Sprint / Démo de Sprint:
La plupart du temps, il arrive que le QA soit celui qui est choisi pour donner la démo au PO et aux parties prenantes. mais sinon, persuadez votre Scrum Master de le faire. Un QA est une bonne personne pour donner la démo car il / elle a testé la user story à l'intérieur et à l'extérieur.
Un QA peut faire une démonstration du point de vue métier car il connaît les fonctionnalités, les flux et les règles métier. Préparez-vous bien pour la démonstration et essayez de répondre à toutes les questions du PO et des parties prenantes. Cela vous aidera à devenir le point de contact pour eux en l'absence du Scrum Master et du BA.
# 7) Agissez comme un BA:
Ce n'est pas une tâche régulière et n'est même pas attendue d'un AQ, mais essayez d'obtenir ce rôle lorsqu'une chance est lancée car un AQ est la meilleure personne pour être BA. Par exemple, essayez de réfléchir et de visualiser si les flux, les fonctionnalités ou les règles métier peuvent être modifiés d'une manière qui profitera au client.
Pensez et recherchez les tendances actuelles dans l'interface utilisateur, l'apparence et la convivialité de l'application et comment elle peut être béatifiée, rendue plus conviviale, etc. Si l'équipe est bloquée sur un problème, impliquez-vous et essayez de donner un Solution. Cela donnera un coup de pouce à votre rôle et sera un facteur pour contribuer à votre évolution de carrière.
Les chances surviennent lors des appels avec le PO lorsque certains problèmes sont discutés ou en révision / démo où vous pouvez donner des suggestions.
Conclusion
Scrum est une méthodologie très différente de la méthode normale de la cascade, et le Scrum Master est un facilitateur. N'attendez donc pas de lui qu'il définisse vos activités à votre place.
Dans Scrum, il n’ya pas de limite de début et de fin au rôle d’un contrôle qualité. L'assurance qualité a besoin et doit être impliquée dans chaque activité du tout début à la fin, de la pré-planification jusqu'à la révision / démo du sprint et doit participer à toutes les activités.
Cela aidera à comprendre le produit ou l'application car (comme je l'ai déjà dit) il n'y a pas de documentation appropriée disponible lorsque vous travaillez dans Scrum. On attend de vous que vous soyez responsable, motivé et proactif. N'attendez donc pas que quiconque vienne vous dire ce que vous êtes censé faire ou comment.
Vous devez prendre des initiatives par vous-même, aider l'équipe de toutes les manières possibles, maintenir une relation saine, garder une trace des choses en cours dans l'équipe et surtout être clair sur vos tâches dans un sprint donné.
Ici, il n'y a pas de gestionnaire qui vous surveillera ou gardera une trace de vos activités. Soyez toujours prêt avec un coup de main pour votre équipe et vous obtiendrez le meilleur des opportunités.
N'hésitez pas à exprimer vos réflexions / suggestions sur cet article informatif dans la section commentaires ci-dessous.
lecture recommandée
- Rôle des analystes commerciaux dans SCRUM et pourquoi un contrôle qualité est-il le meilleur pour ce rôle?
- Quiz Agile Scrum en ligne: Testez vos connaissances sur Agile Scrum
- Installation de votre application sur l'appareil et démarrage des tests à partir d'Eclipse
- Kanban vs Scrum vs Agile: une comparaison détaillée pour trouver les différences
- Comment fournir des fonctionnalités logicielles de grande valeur dans un court laps de temps à l'aide du processus Agile Scrum
- Manifeste Agile: Comprendre les valeurs et principes Agile
- Tri des défauts dans Scrum: comment est-il organisé dans une configuration Scrum
- Meilleurs outils de test de logiciels 2021 (Outils d'automatisation des tests QA)