Aidez-moi à comprendre le fonctionnement de l'assurance qualité dans Scrum [fermé]

Question

Apparemment, nous utilisons la méthodologie de développement Scrum. Voici généralement comment ça se passe:

Les développeurs se démènent pour essayer d'accomplir leurs tâches. Généralement, les tâches prennent la majeure partie du sprint. L'assurance qualité empêche Dev de publier quelque chose qu'il peut tester, Dev envoie finalement un code de bug à l'AQ un ou deux jours avant la fin du sprint et passe le reste du temps à corriger les bogues détectés par l'AQ. L’assurance qualité ne peut jamais terminer les tâches à temps, les sprints sont rarement disponibles à temps et Dev et l’assurance-qualité ont quelques jours misérables à la fin du sprint.

Comment la mêlée est-elle censée fonctionner lorsque les tâches de développement réalisables prennent la majeure partie du sprint?

Merci à tous pour votre participation à la discussion. Comme il s’agit d’une question assez ouverte, il ne semble pas qu’il y ait une "réponse". - il y a beaucoup de bonnes suggestions ci-dessous. Je vais essayer de résumer certains de mes "emporter à la maison". points et apporter des éclaircissements.

(BTW - Est-ce le meilleur endroit pour mettre ceci ou devrais-je le mettre dans une "réponse"?)

Points sur lesquels réfléchir / agir:

• Vous devez vous assurer que les tâches du développeur sont aussi petites que possible (granulaires).
• La durée du sprint doit être adaptée à la durée moyenne de la tâche (par exemple, un sprint avec une tâche d'une semaine doit durer au moins 4 semaines)
• L’équipe (y compris l’assurance qualité) doit s’efforcer de faire une estimation plus précise.
• Envisagez de faire un sprint QA séparé en parallèle, mais décalé si cela fonctionne mieux pour l'équipe
• Tests unitaires!

Answer 1

Mon avis est que vous avez un problème d’estimation. Il semble qu'il manque le temps nécessaire pour tester chaque fonctionnalité et seule la partie de construction est prise en compte lors de la planification du sprint.

Je ne dis pas que c'est un problème facile à résoudre, car il est plus courant que tout. Mais les choses qui pourraient aider sont:

• Envisagez l’assurance qualité en tant que membres de l’équipe de développement et incluez-les dans la planification et l’estimation plus proches du sprint.

• Les tâches de développement pouvant être relâchées ne doivent pas occuper la majeure partie du sprint. Fonctions de travail complètes devraient. Essayez de rassembler des métriques sur le temps de développement par rapport au temps d'assurance qualité pour chaque type de tâche et utilisez ces métriques lors de l'estimation des sprints futurs.

• Vous devrez peut-être consulter votre arriéré pour voir si vous avez des fonctions à grain très grossier. Essayez de les diviser en petites tâches faciles à estimer et à tester.

En résumé, il semble que votre équipe n'ait pas trouvé quelle est sa vitesse réelle, car certaines tâches ne sont pas prises en compte lors de l'estimation et de la planification du sprint.

Mais au final, l’inexactitude des estimations est un problème de gestion de projet difficile que vous rencontrez dans les projets agiles ou basés sur des chutes d’eau. Bonne chance.

Answer 2

Un peu tard pour la fête ici, mais voici ma position basée sur ce que vous avez écrit.

Scrum est une méthode de gestion de projet et non de développement. Mais il est essentiel, à mon avis, d’avoir un processus de développement en place. Sans celui-ci, vous passez la majorité de votre temps à réagir plutôt qu'à construire.

Je suis un gars d'essai-premier. Dans mon processus de développement, je construis d’abord des tests pour appliquer les exigences et les décisions de conception. Comment votre équipe les applique-t-elle? Ce que j'essaie de dire ici, c'est que vous ne pouvez tout simplement pas "jeter des choses par-dessus la clôture" et vous attendre à autre chose qu'à un échec. Cet échec sera soit dû à l'équipe de test (en ne testant pas très bien et donc en laissant passer les problèmes), soit aux développeurs (en ne construisant pas le produit qui résout le problème). Je ne dis pas que vous devez d'abord passer des tests - je ne suis ni un militant ni un évangéliste des premiers essais - mais je dis que vous devez mettre en place un processus pour produire un code de qualité, testé et prêt à être produit lorsque vous atteignez la fin d'une itération.

J'ai été exactement là où vous êtes dans cette méthodologie de développement que j'appelle la méthode de la spirale de la mort . J'ai construit un logiciel pour le gouvernement (américain) pendant des années dans un tel modèle. Cela ne fonctionne pas bien, cela coûte beaucoup d'argent, cela produit un code tardif, un code médiocre et ne fait rien pour le moral. Vous ne pouvez pas faire de progrès lorsque vous passez tout votre temps à réparer les bugs que vous auriez pu éviter de créer. J'ai été absolument battu par cette affaire.

Vous ne voulez pas que le QA trouve vos problèmes. Vous voulez les mettre au chômage, vraiment. Mon objectif est de rendre la QA sidérée, car tout fonctionne. Certes, c'est un objectif. En pratique, ils vont trouver des trucs. Je ne suis pas super humain. Je fais des erreurs.

Retour à la planification ...

À mon poste actuel, nous travaillons avec Scrum, nous n’appelons pas ça comme ça. Nous ne sommes pas dans les étiquettes ici, mais nous produisons du code de qualité à temps. Tout le monde est à bord. Nous disons à QA ce que nous aurons prêt à tester et quand. S'ils frappent deux semaines plus tôt, ils peuvent parler à la main. Tout le monde connaît le calendrier, tout le monde sait ce que sera la version et tout le monde sait que le produit doit fonctionner comme annoncé avant de passer au contrôle qualité. Alors qu'est-ce que cela signifie? Vous dites à QA "ne vous inquiétez pas de tester XYZ - il est défectueux et ne sera pas réparé avant la version C". et s’ils testent cela, vous leur rappelez cette déclaration et leur dites de ne pas perdre votre temps. Dure, peut-être, mais parfois nécessaire. Je ne veux pas être impoli, mais tout le monde a besoin de connaître "les règles". et ce qui devrait être testé et qu'est-ce qu'un «problème connu»?

Votre direction doit être à bord. Si ce n'est pas le cas, vous aurez des problèmes. QA ne peut pas exécuter l'émission et le groupe de développeurs ne peut pas non plus l'exécuter complètement. Tous les groupes (même s'il ne s'agit que d'une personne par groupe ou d'un type portant plusieurs chapeaux) doivent être sur la même page: le client, l'équipe de test, les développeurs, la direction et toute autre personne. La communication représente généralement plus de la moitié de la bataille.

Peut-être que vous en mordez plus que ce qui peut être accompli pendant un sprint. C'est peut-être le cas. Pourquoi faites-vous cela? Pour respecter un horaire? Si tel est le cas, la direction doit intervenir et résoudre le problème. Si vous donnez un code de bug QA, attendez-vous à ce qu'il le rejette. Mieux vaut leur donner 3 choses qui fonctionnent que 8 choses qui ne sont pas finies. L’objectif est de produire un ensemble de fonctionnalités qui soit complètement implémenté à chaque itération, et non d’assembler un tas de choses à moitié faites.

J'espère que cela sera reçu comme il se doit - à titre d'encouragement et non de diabolique. Comme je l'ai mentionné, j'ai été où vous êtes et ce n'est pas amusant. Mais il y a de l'espoir. Vous pouvez faire tourner les choses dans un sprint, peut-être deux. Peut-être que vous n’ajoutez aucune nouvelle fonctionnalité dans le prochain sprint et corrigez simplement ce qui est brisé. Vous devrez décider cela en équipe.

Encore un petit plug-in pour écrire le code de test: je me suis trouvé beaucoup plus détendu et beaucoup plus confiant dans mon produit depuis que j'ai adopté l'approche «écrivez les tests d'abord». Lorsque tous mes tests sont réussis, j’ai un niveau de confiance que je ne pourrais tout simplement pas avoir sans eux.

Bonne chance!

Answer 3

Il me semble qu’il existe un problème d’allocation des ressources dans les scénarios nécessitant des tests fonctionnels d’AQ afin de «réaliser» une fonctionnalité donnée dans un sprint. Personne ne semble avoir abordé cette question dans les discussions de mêlée sur l'assurance qualité que j'ai trouvées jusqu'à présent, et la question initiale est presque la même (du moins liée), alors je voulais offrir une réponse partielle et élargir un peu la question.

En ce qui concerne la question initiale spécifique concernant les tâches de développement prenant tout le sprint - il semble que l’avis général d’alléger ces tâches ait du sens si les tests fonctionnels effectués par l’AQ font partie de votre définition de "terminé". Étant donné un sprint de 4 semaines, s'il faut environ une semaine pour tester plusieurs fonctionnalités de plusieurs développeurs, il semble alors que les tâches de développement prenant environ 3 semaines, suivies d'une semaine de décalage de tâches de test d'une semaine environ, constituent la solution. L’assurance qualité commencera bien sûr dès que possible si nous reconnaissons que, du dernier ensemble de fonctionnalités fournies, il y aura un décalage d’une semaine environ. Je me rends compte que nous souhaitons fournir des fonctionnalités à l'assurance qualité dès que possible afin que vous n'ayez pas ce scénario semblable à une cascade dans un sprint, mais la réalité est que le développement ne permet généralement pas d'obtenir une fonctionnalité réelle et intéressante pour l'assurance qualité avant 1 à 3 semaines plus tard. le sprint. Bien sûr, il y a des morceaux ici et là, mais le gros du travail est de 2 à 3 semaines de développement, puis environ une semaine d’essais.

Voici donc le problème d’allocation des ressources et mon extension à la question: dans le scénario ci-dessus, le contrôle qualité a le temps de tester les fonctionnalités planifiées d’un sprint (3 semaines de tâches de développement, laissant la semaine dernière pour tester les fonctionnalités fournies. dernier). Supposons également que l’AQ commence à avoir des fonctionnalités testables après une semaine de développement - mais qu’en est-il de la première semaine pour l’AQ et de la quatrième semaine pour le développement?

Si le test fonctionnel d'assurance qualité fait partie de la définition de "fait" pour une fonctionnalité dans un sprint, alors il semble que cette inefficacité soit inévitable. L’AQ sera en grande partie inactive au cours de la première semaine et le développement, au cours de la quatrième semaine. Bien sûr, il y a des choses qui remplissent naturellement ce moment, comme la correction de bugs et la vérification, la conception / planification, etc., mais nous modifions essentiellement nos ressources à une capacité de 75%.

La réponse évidente semble être le chevauchement des sprints pour le développement et l’assurance qualité car la réalité est que l’assurance qualité est toujours en retard par rapport au développement. Les démonstrations destinées aux propriétaires de produits et aux autres personnes suivraient le sprint QA car nous souhaitons tester les fonctionnalités avant de les afficher. Cela semble permettre une utilisation plus efficace du développement et de l'assurance qualité, car nous n'avons pas autant de temps perdu. En supposant que nous voulions garder les développeurs en développement et tester les tests, je ne vois pas de meilleure solution pratique. J'ai peut-être manqué quelque chose et j'espère que quelqu'un pourra m'éclairer à ce sujet - sinon, il semble que cette approche rigide de la mêlée soit imparfaite. Merci.

Answer 4

Espérons que vous corrigez cela en vous attaquant à moins de tâches de développement à chaque sprint. Ce qui conduit aux questions suivantes: Qui est les objectifs du développeur? Pourquoi Dev ne parvient-il toujours pas à atteindre ces objectifs?

Si les développeurs ne fixent pas leurs propres objectifs, ils sont toujours en retard. Et ce n'est pas la façon idéale de pratiquer Scrum. Il ne s’agit que d’un développement progressif avec de gros produits à livrer, dans des délais impartis, sans aucune responsabilité des développeurs.

Si les développeurs ne peuvent pas définir leurs propres objectifs parce qu'ils ne savent pas assez, alors ils doivent être plus impliqués à l'avance.

Scrum dépend de quatre principes de base, décrits dans le Manifeste Agile .

1. Les interactions importent - cela signifie que les développeurs, le contrôle qualité, la gestion de projet et les utilisateurs finaux doivent parler davantage et se parler les uns aux autres. Le logiciel est un processus de codage des connaissances dans le langage obscur des ordinateurs. Pour encoder la connaissance, les développeurs doivent avoir la connaissance. [Pourquoi pensez-vous que nous l'appelons "code"?] Scrum n'est pas une "écriture de spécification - jet sur le tableau arrière" méthodologie. C’est ANTI "& spec; write spec - jet sur le tableau"

2. Travailler avec le logiciel est important - cela signifie que chaque pièce créée doit aboutir à une version fonctionnelle . Pas un ensemble de corrections de bugs pour le contrôle de la qualité, mais un logiciel fonctionnel.

3. Collaboration client: cela signifie que dev doit travailler avec les analystes, les utilisateurs finaux, les propriétaires d’entreprise, ainsi que tous ceux qui peuvent les aider à comprendre ce qu’ils construisent. Les délais n'ont pas autant d'importance que la prochaine chose remise au client. Si le client a besoin de X, c'est la tâche la plus prioritaire pour tout le monde. Si le plan de projet indique la construction Y, c'est une charge de malarkey.

4. Répondre au changement - cela signifie que les clients peuvent réorganiser les priorités des sprints suivants. Ils ne peuvent pas réorganiser le sprint en cours (c'est fou) mais tous les sprints suivants sont candidats à un changement de priorité.

Si le client conduit, les délais deviennent moins artificiels. "Jalons du projet". et plus "nous avons besoin de X d'abord, puis de Y, et cette chose de la section Z, nous n'en avons plus besoin. Maintenant que nous avons W, Z est redondant. "

Answer 5

Les règles Scrum indiquent que tous les éléments Sprint doivent être "entièrement testés et potentiellement implémentables". à la fin du sprint pour être considéré comme terminé. Les sprints se terminent TOUJOURS à l’heure, et l’équipe n’obtient pas de crédit et n’a pas le droit de présenter quoi que ce soit dans l’examen du sprint qui ne soit pas complet - et cela inclut le contrôle qualité.

Techniquement, c’est tout ce dont vous avez besoin. Une équipe s’engage dans un certain volume de travail, le soumet finalement à l’assurance-qualité deux jours avant la fin du sprint et l’assurance-qualité n’est pas terminée à temps. Le résultat du sprint est donc nul, ils doivent se présenter devant le client et admettre qu'ils n'ont rien à montrer avant un mois de travail.

La prochaine fois, vous pariez qu'ils vont chercher moins de travail et trouveront le moyen de le faire passer à l'assurance de la qualité pour qu'il soit terminé à temps.

Answer 6

Speaking as a QA who has worked on Agile projects for 2.5 years this is a really difficult issue and I still don't have all the answers.

I work as part of a "triplet" (two developers who pair program + one QA) and I am involved in tasking out stories and estimating in planning meetings at the beginning of two week iterations. As adrianh mentioned above it is essential for QAs to get their voice heard in the initial sprint planning. This can be difficult especially if you are working with Developers with very strong personalities however QAs must be assertive in the true sense of the word (i.e. not aggressive or forceful but respectfully seeking to understand the Truth/PO and Developers/technical experts whilst making themselves understood). I advocate producing QA tasks first during planning to encourage a test driven mentality - the QA may have to literally put themselves forward to get this adopted. It is opposite to how many people think software development works but pays dividends for several reasons;

1. QA is heard and not relegated to being asked "so how are you going to test that?" after Devs have said their piece (waterfall mentality).

2. It allows QA to propose ideas for testing which at the same time checks the testability of the acceptance criteria while the Truth/PO is present (I did say it is essential for them to be present in the planning meeting didn't I?!) to fill in any gaps in understanding.

3. It provides the basis for a test driven approach - after the test approach has been enunciated and tasked the Devs can think about how they will produce code to pass those tests.

4. If steps 1 - 3 are your only TDD activity for the rest of the iteration you are still doing a million times better than the scenario postulated by Steve in the first post; "Developers thrash around trying to accomplish their tasks. Generally the tasks take most of the sprint to complete. QA pesters Dev to release something they can test, Dev finally throws some buggy code out to QA a day or two before the sprint ends and spends the rest of the time fixing bugs that QA is finding"

Needless to say this comes with some caveats for the QA;

1. They must be prepared to have their ideas for testing challenged by Devs and Truth/PO and to reach a compromise; the "QA police" attitude won't wash in an Agile team.

2. QA tasks must strike a difficult balance to be neither too detailed nor too generic (tasks can be written on a card to go on a "radiator board" and discussed at daily stand up meetings - they need to be moved from "in progress" to "completed" DURING the iteration).

3. QAs need to prepare for planning/estimation meetings. Don't expect to be able to just turn up and produce a test approach off the top of your head for unseen user stories! Devs do seem to be able to do this because their tasks are often far more clear cut - e.g. "change x module to interface with z component" or "refactor y method". As a QA you need to be familiar with the functionality being introduced/changed BEFORE planning so that you know the scope of testing and what test design techniques you might apply.

4. It is almost essential to automate your tests and have these written and "failing" within the first two or three days of an iteration or at least to co-incide with when the Devs have the code ready. You can then run the test/s and see if they pass as expected (proper QA TDD). This is how you avoid a mini waterfall at the end of iterations. You should really demo the test to the Devs before or as they start coding so they know what to aim for.

5. I say 4 is "almost essential" because the same can sometimes be successfully achieved with manual checklists (dare I say scripts!) of expected behaviour - the key is to share this with Devs ahead of time; keep talking to them!

With regards to point 2 above on the subject of the tasks, I have tried creating tasks as granular as 1/2 hour to 2 hours in size each corresponding to a demonstrable piece of work e.g. "Add checks for incorrect password to auto test - 2 hrs". While this helps me organise my work it has been criticised by other team members for being too detailed and has the effect at stand ups of me either moving multiple tasks across to complete from the day before or not being able to move any tasks at all because I have not got onto them yet. People really want to see a sense of steady progress at daily stand ups so it is more helpful to create tasks in 1/2 day or 1 day blocks (but you might keep your own list of "micro-tasks" to do towards to completion of the bigger tasks that you use for COMMUNICATING overall progress at the stand-up).

With regards to points 4 and 5 above; the automated tests or manual checklists you prepare early should really cover just the happy paths or key acceptance criteria. Once these pass you can have planned an additional task for a final round of "Exploratory testing" towards the end of the iteration to check the edge cases. What the Devs do during that time is problematic because as far as they are concerned they are "code complete" unless and until you find a bug. Some Agile practitioners advocate going for the edge cases first although this can also be problematic because if you run out of time you may not have assured that the acceptance criteria have been delivered. This is one of those finely balanced decisions that depends on the context of the user story and your experience as a QA!

As I said at the beginning I still don't have all the answers but hope the above provide some pointers born out of hard experience!

Answer 7

Sounds like your development team might not be doing enough testing on their own, before the release to QA. If all your unit tests are passing, the QA cycle should be relatively smooth sailing, no? They'll find some integration errors, but there shouldn't be very many of those, right?

Answer 8

I think that there are several problems here. First, I think that perhaps the developer tasks aren't either fine grained enough, or perhaps not estimated well, or perhaps both. The whole purpose of the sprints in Scrum is to be able to demonstrate workable code at the end of the sprints. Both of the problems that I mentioned could lead to buggy code.

If developers are release buggy code towards the end of the sprint, I would also look at:

• Are the product owners really holding the dev members accountable for getting their tasks done. That's the job of the PO and if that's not happening, then the developers will slack.
• Are the devs using any kind of TDD. If not, that might help matters greatly. Get the developers in the habit of testing their code. We have this problem where I work, and my team is focused on doing the TDD in the important areas so that we don't have to have someone else do it later
• Are the task/user stories too generic? Wiggle room in the task breakdowns will cause developers to be sloppy. Again, this is somewhat of a PO problem.

One idea that I've heard batted around in the past is to use a QA person as scrummaster. They will be present for the daily standups and can get sense of where things are at with the developers. They can address issues with the PO (assuming that the PO can adequately do their job).

I can't help but feel that you need more coorporation between QA and your scrum teams. It sounds like testing only happens at the end, which is a problem. Getting QA to be a part of the team will help identify things that can be tested earlier and better.

I also feel like you have an issue with the product owner. They must be in there making sure that everyone is driving the right direction. they should be making sure that there is good cooperation, not only between QA and devs, but between the devs themselves.

Answer 9

"How is scrum supposed to work when releasable Dev tasks take up most of the sprint?"

As you've found out - it doesn't work terribly well :-) The process you're describing doesn't sound much like Scrum to me - or at least not like Scrum done well.

I'm unsure from what you've described whether the QA folk are part of the team - or a separate group.

If they're a separate group then this is probably a big part of the problem. They won't be involved in the team's commitment to completion of tasks - and the associated scope negotiation with the product owner. I've never seen an agile group succeed well without their being QA skills in the team. Either by having developers with a lot of testing/QA skills - or by having an embedded QA person or three on the team.

If they are on the team then they need to get their voice heard more in the initial sprint planning. By now it should be clear to the product owner and team that you're overcommitting.

I'd try a few things if it were me:

• Get QA/testing folk on the team if they're not there already
• Have a good long chat with the product owner & the team over what counts as "done". It sounds like some of the developers are still in the pre-scrum mindset of "handed over to QA"" == done.
• Break down the stories into smaller chunks - makes it easier to spot estimation mistakes
• Consider running shorter sprints - because little and more often is easier to track and learn from.

You might also find these tips about smoothing down a scrum burndown useful.

Answer 10

We solved this problem as follows: - Every item in the product backlog must have fit criteria or acceptance criteria, without those, we don't start a sprint - A tester is part of our team, for every product backlog item, he creates test tasks (1 or more, based on the acceptance criteria) together with an estimation, and a link to the item to test - During the daily scrum, all tasks that are finished are placed in a 'To Test' column - We never do tasks that take longer than 16 hours; tasks that are estimated longer, are split up

Answer 11

Split the tasks into smaller tasks.

Also, QA can create test cases for Dev to test against.

Answer 12

One idea to consider is to have QA work one iteration behind the main development. That works well in our environment.

Answer 13

Here I would say that, One size does not fit all. Every team deals QA differently. It so much depends on the project you are working on, either it's a small one or big one. Does it need extensive regression, User acceptance and exploratory testing or you have quite few scenarios to test. Let me restate that in Agile, generalist are preferred on specialist. What is that? Because there is time during the project when you don't have anything to Test, so at that time you might be doing something else. Also you might be doing testing even though you are a hard-core programmer.

How do we handle it? We have regular 2 week sprint. Testing start after a week on the task completed by developers during the week. Now tester keep adding issues to our Issue tracker and developers who are done with their sprint tasks start picking those bugs. By the end of the sprint we mostly get done with our sprint task and all critical and major bugs.

So what does tester two in the first week of the sprint?

Well, There are always things to test. We have testing tasks in the backlog, that may include some exploratory testing. Many people don't value Exploratory testing but that is extremely important to build quality products. Good testers create task for themselves and find the possibilities where things go wrong and test them.

Hope that helps!