Examen par les pairs pour les tests, tout comme les examens de code

Quelqu'un pratique-t-il le processus de "révision du code" pour les tests fonctionnels? Trouvez-vous cela utile? La façon dont mon employeur actuel pratique SCRUM, nous incluons les tests fonctionnels dans le cadre de nos activités «indispensables» dans un sprint donné.

Nous pratiquons également SCRUM. Et de la même manière que vous, nous incluons également les tests fonctionnels dans notre définition comme fait.

D'après mon expérience, je trouve cela incroyablement utile. Nous avons considérablement réduit le nombre de bogues dans notre code en forçant simplement les tests fonctionnels.

Une deuxième bonne chose à propos de l'examen du code, c'est qu'il vous donne une autre vue sur la fonctionnalité réelle, et pour vous assurer à 100% qu'elle est conforme à ce que le client / client voulait. Il y a eu quelques fois où quelqu'un passait en revue le code et les fonctionnalités où la personne est allée ... "Attendez, ce n'est pas bien ..." et il s'est avéré que la personne qui implémentait le code avait simplement mal compris quelque chose.

Mon Dieu, oui (j'essaie de ne pas utiliser d'explétifs sur SO; p). L'examen par les pairs de vos tests fonctionnels consiste essentiellement à examiner vos besoins et votre analyse, c'est extrêmement important, et si vous utilisez un langage BDD comme le concombre, vous pouvez également impliquer des non-programmeurs!

C'est génial lorsque nos utilisateurs finaux découvrent des problèmes avec nos tests fonctionnels et cela les fait se sentir très impliqués dans le processus de développement "Je peux aussi lire le code !!"

Cela me semble parfaitement logique. Tout code que vous écrivez doit être consulté par quelqu'un d'autre, même s'il n'est utilisé qu'en interne et ne sera jamais exécuté par le client.

Avec les méthodologies qui mettent tant de poids dans les tests, la révision des tests devient beaucoup plus importante, peut-être nécessaire, parfois plus importante que la révision du code lui-même, car on suppose souvent qu'il peut être remplacé par tout code répondant au même automatisé. résultat du test.

Vérifier que les tests sont corrects est un aspect, qu'ils sont suffisamment complets et précis / représentatifs est également très important.

Rater ce point est l'une des choses qui font que ces méthodologies semblent bâclées aux examinateurs externes.

Vous pouvez faire des inspections de paires!

Les inspections de paires sont:

Un examen des documents de manière active et informelle dans le cadre du cycle de rédaction et de production de documents.

Les raisons pour lesquelles cela fonctionne bien avec les tests sont les suivantes:

1. Vous pouvez fréquemment inspecter des exigences ou des documents avec plus d'une paire d'yeux.
2. Vous pouvez impliquer plus que de simples développeurs: essayez BA avec Test Lead, BA avec PM, BA avec Dev.
3. Vous pouvez définir des réunions de durcissement dans le cadre d'un processus Agile - Assurez-vous d'être sérieux avec des engagements solides de la part des membres de l'équipe.
4. Vous pouvez utiliser ces inspections de paires dans le cadre d'un exercice d'établissement de relations et d'un exercice de communication avec vos parties prenantes. Lancez la conversation!

Nous examinons les tests fonctionnels par les pairs au moins avec désinvolture, et il est fortement encouragé dans notre organisation de faire tout réviser le code.

Je recommanderais de choisir votre évaluateur en fonction de vos objectifs pour l'examen. Les tests codés peuvent être mieux examinés par un développeur (pour la qualité du code principalement) et un autre testeur (pour la couverture des tests principalement). Les tests sans code (utilisant un harnais, par exemple, des tests basés sur les données) peuvent être mieux examinés uniquement par un autre testeur. Les évaluations par les pairs sont également un excellent moyen d'encourager les testeurs à apprendre les uns des autres.