La validation ne découvre pas la demande
Si le travail de rédaction et de réalisation a été fait correctement, la majorité des ajustements a déjà eu lieu avant d’arriver ici. Une validation qui fait remonter des comportements oubliés n’est pas une bonne validation : c’est le signe que la conception était incomplète.
C’est la raison pour laquelle nous investissons autant sur les cas de test au moment de rédiger le ticket.
Qui valide quoi, et comment
La réponse ne se cherche pas à cette étape. Elle est déjà écrite dans le ticket, sous forme de liste d’actions. Se poser la question maintenant reviendrait à admettre que le principal intéressé n’a pas été consulté à la conception.
- validation simple : une ligne dans la checklist
- validation en plusieurs temps : une checklist de validation dédiée, avec chaque étape assignée à la bonne personne
Cette checklist mélange volontairement des natures d’étapes différentes : une vérification technique sur la merge request, le contrôle que les cas de test sont bien implémentés en tests automatiques, puis une validation sur recette et une sur production. C’est cette liste qui définit le périmètre exact de la validation et rien d’autre.
Quand le ticket passe à valider
Le ticket passe À valider quand le code est complètement finalisé et qu’il a passé la revue de code.
Qui notifie que la validation peut commencer dépend de l’organisation du projet :
- la personne en charge de la demande déploie elle-même en intégration ou recette : c’est elle qui notifie
- une autre personne déploie : elle notifie à la suite de sa livraison
Dans tous les cas, si la validation bloque, c’est la personne assignée au ticket qui relance et qui s’assure que la personne en charge de la validation a tous les éléments nécessaires.
Où se déroule la validation
Les tests réalisés sur le poste de la personne qui a fait le travail relèvent de la mise au point, pas de la validation. La validation se déroule donc toujours sur un autre environnement :
- sur l’environnement d’intégration pour la validation interne
- sur l’environnement de recette pour la validation client
- en production quand la recette ne permet pas de reproduire complètement la situation
Comment valider
Quand un test fait apparaître une erreur, le premier réflexe est de vérifier auprès de la personne assignée qu’il ne s’agit pas d’une incompréhension. Si le retour est confirmé, il est ajouté à la checklist de retours du ticket, qui reçoit le label Retour recette et repart en À faire .
Ce label a un effet concret : il indique une finalisation, et le ticket sera donc traité avant les nouveaux développements.
Même après avoir constaté une erreur, il faut poursuivre la validation le plus loin possible. L’objectif est de remonter l’ensemble des retours en une seule fois. Une validation interrompue au premier problème provoque autant d’allers-retours qu’elle a laissé de points non testés.
Tracer les retours
Un retour se trace au minimum sous la forme d’une ligne dans une checklist de retours, complétée si besoin par un paragraphe dans la description du ticket. Dans ce cas, la description reçoit un titre de niveau 3 portant le nom de la checklist, et un titre de niveau 4 par ligne concernée.
Le nom d’une checklist de retours est toujours préfixé par Retours. C’est ce qui garantit la traçabilité de
l’origine de chaque demande de correction.
- cas simple : une seule checklist
Retours - cas avancé : une checklist par phase de test, par exemple
Retours Intégration,Retours Point projetavec sa date, puisRetours Recette
Quand les retours du client arrivent en plusieurs fois, chaque salve crée une nouvelle checklist datée. L’objectif est de pouvoir traiter par lots et faire valider chaque lot. Si le client complète un lot de retours précédent quelques jours plus tard, son retour rejoint la checklist de ce lot, même si la date ne correspond plus.
Un retour sur un retour
Le principe reste le même : on avance par lots. Si le retour porte sur le traitement d’un retour précédent, il rejoint la checklist de ce retour, pas une nouvelle.
Un ticket a passé les tests d’intégration, avec ses retours tracés dans
Retours Intégration.À la présentation de l’écran au point projet suivant, le client demande d’ajuster la disposition : nous créons une checklist
Retours Point projetdatée du jour.Un développeur traite ce retour et déploie en intégration. À la validation de cette livraison, la demande n’a pas été correctement traitée : la correction est ajoutée dans la checklist du point projet, pas ailleurs.
Les phases de recettage client
Lorsque l’on arrive à la fin de la construction d’un lot, chaque ticket a été validé unitairement et il est à présent possible de réaliser des tests de bout en bout pour vérifier que tout fonctionne correctement ensemble. C’est la phase de recettage du lot, et il est possible d’avoir des retours portant sur des tickets déjà Terminé .
Ne pas rouvrir les tickets terminés. Le travail demandé a été fait et validé sur le périmètre du ticket d’origine. Ce recettage est une nouvelle demande : elle se traite dans un ou plusieurs nouveaux tickets, selon le volume des retours.
Validation interne et validation client
Un ticket est généralement validé en interne avant d’être soumis au client, mais les deux relèvent de la même phase. La colonne À valider contient donc des tickets à valider en interne et d’autres à valider par le client, certains n’étant jamais validés par un client.
Pour que l’avancement reste lisible, tout tient dans la checklist : les étapes y sont décrites, assignées, et suivies. Chacun notifie la personne qui doit intervenir ensuite lorsqu’il a fini sa part. Le développeur notifie la première, et ainsi de suite jusqu’à la dernière, qui passe le ticket en Terminé .
La suite du parcours, du passage en Terminé à la clôture en point projet, est décrite dans le cycle de vie d’un ticket.