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

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.

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.

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.

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é.

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.

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.