Les résultats des vérifications restent liés au travail concerné, et chaque exécution est enregistrée dans un seul journal. Chacune dispose d'un emplacement dédié :
- Les constatations d'une tâche. Elles sont répertoriées dans la section Qualité de la tâche au sein de l'Usine, avec leur état actuel : toujours ouvertes, en cours de correction, corrigées ou acceptées.
- Les échecs de test qui ne sont rattachés à aucune tâche. Un test navigateur planifié ayant échoué, par exemple, attend dans l'Usine sous l'onglet Révision. Corrigez-le pour en faire une tâche, ou acceptez-le en indiquant une raison.
- Les vérifications qui ne peuvent pas s'exécuter. Si un projet ne dispose pas de cadre de tests unitaires, par exemple, la ligne Tests unitaires dans le Contrôle qualité l'indique, et son action Corriger génère une tâche pour mettre en place ce cadre.
- Exécutions. Chaque exécution, avec sa durée et son coût, est listée dans les Paramètres sous l'onglet Activité.
Des schémas récurrents dans le travail
Une constatation sur une seule tâche n'est qu'un détail. La même constatation sur trente tâches constitue un schéma, et c'est là que se prennent les décisions utiles.
Ce qu'il faut rechercher :
- Des constatations qui se répètent. Le même problème sur de nombreuses tâches correspond soit à une dette technique méritant un travail spécifique, soit à une vérification ne respectant pas vos conventions.
- Des constatations que personne ne résout. Une catégorie systématiquement acceptée indique une vérification qui ne justifie pas sa présence.
- Concentration. Un projet générant le plus de constatations indique où chercher.
Exécutions
L'Activité liste toutes les exécutions au sein de l'organisation : agents, tâches, vérifications qualité et tests. Filtrez-la par résultat, type, projet et période, puis ouvrez une exécution pour consulter ses vérifications, résultats et sorties.
Le schéma utile ici est celui des échecs qui se répètent à la même étape sur des tâches sans lien entre elles : il s'agit d'un problème de configuration du projet plutôt que d'un problème de code, et la réexécution des tâches ne le corrigera pas. Consultez Configuration de la compilation et des tests.
Transformer les schémas en travail.
Une constatation récurrente peut devenir une tâche. C'est l'objectif de la repérer : « ce schéma apparaît dans quarante fichiers » constitue un travail à effectuer, et non une condition permanente du code.
Lorsqu'une condition doit être surveillée en continu plutôt que vérifiée manuellement, une automatisation peut la détecter et ouvrir un travail de remédiation.
Optimiser plutôt que tolérer.
Si les constatations sont trop nombreuses, les vérifications sont mal calibrées et non votre code est exceptionnellement défectueux.
Une vérification déclenchée à chaque modification décrit votre base de code plutôt que des problèmes. Soit la règle ne correspond pas à vos conventions, soit elle décrit une dette technique que vous avez choisi d'accepter. Dans les deux cas, la vérification doit être modifiée – consultez Politiques et portes qualité.