L'examen du code est en retard sur le cycle de livraison / test

14

Dans notre processus Agile, nous avons des sprints de 2 semaines. Les tâches sont livrées quotidiennement (versions quotidiennes) et l'équipe de test termine ses tests immédiatement le lendemain, voire le même jour.

Nous avons également des revues de code Dev, qui nécessitent un certain temps (1-2 heures), donc elles sont programmées 3 fois par semaine: lun-mer-ven. Les développeurs se réunissent et suggèrent comment améliorer / refactoriser le code.

Notre problème est qu'au moment où les éléments d'action apparaissent après une révision du code, la plupart des tâches ont déjà été testées. Les testeurs ne veulent pas retester ce qui a déjà réussi leurs tests. Ils ne se soucient pas des changements de développement internes.

Comprenons-nous mal le processus Agile? Les révisions de code sont-elles incompatibles avec un cycle de publication / test quotidien? Nous ne pouvons pas tenir des révisions de code tous les jours, car elles occupent tout le monde.

— gène b.
source

J'ai trouvé quelques suggestions qui pourraient être utiles - Examen du code dans les équipes Agiles - partie II (trouvé à partir d'une recherche Google très rapide - vous pourrez peut-être en trouver plus).

— Dukeling

1

Vos testeurs travaillent-ils sur des tâches "validées"? La définition de «libérée» de votre équipe inclut-elle la révision du code et la résolution des éléments d'action? Ou la révision du code a-t-elle lieu en dehors de la définition de terminé de votre équipe?

— Kent A.

1

Votre équipe de test ne dispose-t-elle pas d'une suite de régression automatisée?

— Telastyn

5

Comment faites-vous des «revues de code»? S'agit-il d'un long processus formel dans lequel les examinateurs doivent parcourir toute une liste de contrôle de paramètres de qualité (effort: plusieurs heures-personnes)? Ou s'agit-il simplement d'un autre membre de l'équipe qui examine le code et pose des questions si quelque chose semble ne pas fonctionner (effort: 10 à 30 minutes pour le codeur et le réviseur)? Pourquoi faites-vous des revues de code? Pour garantir la qualité du code? Pour attraper des bugs? Diffuser la connaissance du système entre plusieurs personnes? Votre mécanisme de révision du code aide-t-il à atteindre ces objectifs, ou s'agit-il simplement de bureaucratie que personne ne veut faire?

— amon

J'aime toutes les réponses, mais permettez-moi d'ajouter un point que je considère important. Vous demandez si vous interprétez mal Agile mais vous ne dites pas quelle méthodologie. Suivez-vous Scrum? Le plus important: avez-vous une définition de "Terminé"? Je demande parce que je trouve ça très ... étrange que vous envisagiez quelque chose de "livré" avant d'avoir fini de travailler dessus. On dirait que la révision de code est quelque chose de "supplémentaire" que vous faites simplement parce que.

— Lorenzo Dematté

8

Les testeurs ne veulent pas refaire le test, c'est un peu comme dire "les codeurs ne veulent pas refactoriser". Cela fait partie du travail. Le processus peut être reformulé comme ceci: les tâches sont créées. Le code est généré. Le code est testé. Le code est révisé. Des imperfections se trouvent dans le code. De nouvelles tâches sont créées pour corriger ces imperfections (par exemple, le code est refactorisé). Ces nouvelles tâches nécessitent de nouveaux tests.

— John
source

2

+1 Dans une méthodologie Agile à version quotidienne, ne rouvrez pas les tâches. Créez une nouvelle tâche pour résoudre les problèmes détectés et planifiez-la en fonction des priorités de votre équipe. Nouvelles tâches = nouvelle action d'assurance qualité (ce qui signifie probablement réexécuter les mêmes tests). Si l'AQ ne l'aime pas, il y a beaucoup d'autres carrières.

— Kent A.

Cela fonctionne clairement, mais cela semble inefficace.

— usr

7

Si vous allez revoir le code à un moment donné, il n'est pas plus cher de le faire tôt. Et il semble que vous ayez un processus de test coûteux, donc vous ne voulez pas tester deux fois. Par conséquent, il est moins coûteux de revoir le code avant de le tester. La révision du code après le test n'accélère pas le travail. Cela le ralentit et vous incite à fournir du code mal écrit mais testé avec succès. Au fil du temps, tout ce code non révisé rendra le travail de plus en plus lent. Ensuite, un concurrent plus efficace offre un meilleur produit à moindre coût et la partie est terminée.

Automatisez également les tests. Le test manuel date de 1970.

— Kevin Cline
source

5

Si vous avez du mal à obtenir des révisions de code dans le temps dont vous disposez actuellement avant le contrôle qualité, vous devriez envisager de rendre les révisions de code plus légères, comme la révision de code dans les équipes agiles, partie II, dont @Dukeling a parlé.

J'ai trouvé que même la chose la plus simple qui pourrait être appelée une révision de code offrait des avantages: avant de valider du code (ou d'introduire un DVCS), appelez un autre développeur et guidez-le pendant votre modification. Cela peut prendre cinq ou dix minutes. Le but de cette révision de code est "Est-ce que cela a du sens pour l'autre développeur?" Le but n'était pas de tergiverser sur les implémentations de conception ou de se conformer complètement aux idées personnelles de l'évaluateur sur la façon dont il aurait dû être écrit. Il a donné ces avantages:

Amélioration des connaissances partagées sur le fonctionnement du code
Pris du code confus ou potentiellement erroné parce que le fait d'expliquer le code était suffisant pour inciter l'auteur à repenser les choses
A aidé à faire évoluer progressivement les idiomes et le style de l'équipe, car cela facilitait l'explication des choses
Très peu de grognement de l'équipe

Les révisions de code plus approfondies fonctionnent mieux pour détecter les problèmes. Mais vous devez être en mesure de les faire et d'agir sur eux pour obtenir la valeur. Un processus léger que vous pouvez faire tout le temps peut être plus utile qu'un processus lourd qui ne cesse d'être repoussé, ou ajoute simplement des choses à l'arriéré.

— Alan Shutko
source

1

Une solution à ce problème est de faire une revue rapide du code par un autre pair une fois qu'une user story est terminée, afin qu'il n'y ait pas d'erreurs basiques / évidentes dans le code.

Mais cela doit se produire avant le cycle de test. Ensuite, il y aurait moins de changements de code après le test, lorsque vous effectuez des évaluations plus importantes avec toute l'équipe ensemble.

— Pélican volant à basse altitude
source

1

D'après les sons, les testeurs ne veulent pas retester parce que le test est un processus douloureux / coûteux.

L'automatisation des tests par les développeurs et les testeurs est un énorme bonus pour les équipes qui essaient de travailler de manière agile. Plus vos tests sont moins chers, plus faciles et plus reproductibles, plus vous pouvez les exécuter - et moins vous aurez de résistance à changer quelque chose.

Avez-vous refactorisé rapidement sur la base de certains commentaires des développeurs? Appuyez sur le gros bouton rouge qui exécute votre suite de régression / fumée et effectuez un rapide manuel une fois pour vérifier les problèmes visuels qui pourraient avoir surgi. Facile!

Une fois que vous êtes dans un endroit comme celui-ci, le nouveau test ne sera pas une corvée - ce sera une seconde nature.

— f1dave
source