Souvent, trop souvent, une phase d’UAT1 se retrouve dans les processus des équipes de développement logiciel, notamment dans les grands groupes.
Pour ces équipes, cela leur semble l’évidence même :
Que les métiers savent mieux que nous ce dont ils ont besoin, et
Qu’il faut faire tester par les utilisateurs (toujours ces mêmes métiers donc) pour valider le travail.
Dans cet article, je vais expliquer en quoi cette manière de voir les choses est fondamentalement faussée. Mais avant cela, je vais commencer par illustrer tous les problèmes de cette approche, en quoi c’est un frein majeur à la performance. Je conclurai en donnant des pistes pour faire autrement.
Les problèmes de l’approche UAT
Sans même philosopher de la pertinence ou non de l’UAT, le problème majeur est que cela introduit une dépendance envers des personnes externes à l’équipe au cœur du son flux de travail de l’équipe.
C’est directement antinomique avec le principe d’une équipe qui travaille en cycles courts. Voici ce que l’on constate généralement, tous des scenarios que l’on voudrait éviter :
On fait des sprints à durée variable, car on ne sait pas combien de temps durera la validation avant de pouvoir mettre en production. Au moins, cela permet d’avoir une vision honnête de ce qu’il se passe d’un point de vue utilisateurs…
Ou alors, on fait des sprints à durée fixe, mais on exclut alors la mise en production de la Definition of Done. L’équipe considère que son travail est “terminé” non pas lorsque le problème utilisateur est résolu, mais lorsqu’elle a codé une solution, qu’elle soit bonne ou mauvaise. Et s’il faut retravailler la solution… Se pose alors la question insoluble de s’il faut ou non compter ce travail dans la vélocité des sprints suivants pendant lesquels ont lieu ces corrections.
Dans tous les cas, on ne travaille pas au fil de l’eau à faire du déploiement continu. Au contraire, cela encourage voire force à faire des gros morceaux, que l’on validera en une seule fois. Au mieux, on fait donc un déploiement par sprint… Et de manière plus réaliste, sûrement un déploiement tous les quelques sprints. Ce qui finalement est logique quand on n’intègre pas le déploiement dans la Definition of Done. 🤷
Même constat pour une équipe qui ne fonctionne par en sprints : ça dérape, ça prend du temps, on fait des grosses releases plutôt que des déploiements au fil de l’eau.
Quoi qu’il arrive, de grosses releases impliquent des tests plus difficiles et coûteux, plus de régressions, plus de retravail, moins de satisfaction, une dynamique d’équipe moins optimiste… Bref, tout s’aligne vers moins de performance.
Cas particulier 1 : l’agence qui pose contractuellement la réactivité du client
Pour être complet et équitable dans mon analyse, je me dois tout de même de parler de quelques cas particuliers où l’approche marche plutôt bien.
Le premier cas particulier est celui d’une agence qui pose clairement que le client doit être réactif, à chaque étape clé, pour donner ses retours sur le travail livré. Dit autrement, on lui impose d’être là en Sprint Review ou de faire des tests dans un environnement dédié à intervalles donnés, planifiés en avance — sous peine de pénalités financières autrement !
Concrètement, on reste dans le même modèle, mais on met en place des éléments qui vont drastiquement contraindre la dépendance externe à l’équipe de sorte à ce que cela reste gérable.
Ma première remarque sur le sujet pourrait être de se demander si, dans ce mode de fonctionnement, la personne qui fait les validations est bien externe à l’équipe ? Ou si justement on ne pourrait pas considérer que, d’une certaine manière, le cadre contractuel force l’intégration de cette personne dans l’équipe.
Dans tous les cas, cela ne fonctionnera qu’à ces trois conditions :
Ces dimensions contractuelles et financières qui permettent de forcer la participation de la personne et d’éviter que cela ne soit un point de blocage de l’équipe.
Autre élément également lié au contexte agence : le client est considéré comme pertinent pour valider de la pertinence du travail fait.
Dernier point et non des moindres : l’excellence technique est un prérequis absolu. Si l’on soumet régulièrement pour validation une solution bourrée de régressions, le client refusera de jouer le jeu — à raison.
Cas particulier 2 : “continuous delivery, release on demand” avec les Feature Flags
Un autre cas particulier qui permet de faire fonctionner l’UAT, c’est d’utiliser les Feature Flags2 afin de pouvoir décorréler mise en production et mise en service.
L’UAT n’est alors plus un prérequis pour la mise en production, l’équipe met en production de son propre chef sans dépendance externe. L’UAT fait partie du processus préliminaire à l’activation en production qui enclenche la mise en service, selon une temporalité toute autre.
Ce concept poussé jusqu’au bout s’appelle “continuous delivery", release on demand” :
L’équipe fonctionne en livraison continue, en mettant en production les plus petits incréments possibles, et idéalement chaque jour
Côté demandeurs, métiers, marketing ou autres, on est en total contrôle de la mise à disposition aux utilisateurs
Cela va sans dire, cette approche nécessite également une véritable excellence technique et une totale maîtrise des effets de bord potentiels.
C’est d’ailleurs une telle évidence que la plupart des équipes n’imaginent même pas que cela soit possible de fonctionner ainsi : parce qu’elles sont actuellement incapables de mettre en production facilement, rapidement et sans régression. Quand on n’a jamais connu ça, on pense que c’est impossible. C’est normal.3
Quoi qu’il arrive, il me semble intéressant de noter que les deux cas particuliers ont l’excellence technique comme prérequis fort. Quoi qu’on fasse, on n’y coupe pas ! 😉
Le principe d’UAT ne tient pas debout
Après avoir expliqué les conséquences négatives du principe d’UAT, revenons au pourquoi les équipes en font. J’avais évoqué en introduction les raisons suivantes :
Les métiers sauraient mieux que l’équipe ce dont ils ont besoin, et
Il faudrait faire tester par les utilisateurs (toujours ces mêmes métiers donc) pour valider le travail.
Ces hypothèses sont erronées. A minima elles méritent d’être nuancées, et ainsi laisser entrevoir que l’UAT n’est pas la seule solution.
La vérité est en prod’
Qui sait ce qu’il faut construire ?
Ultimement, la réponse, c’est… Personne. Même les utilisateurs eux-mêmes ne savent pas réellement.
Bien sûr, je ne suis pas en train de dénigrer la pertinence de donner une vision, des études marketings ou de l’expertise métier. Tous ces éléments sont extrêmement pertinents et utiles.
Mais rien ne remplacera jamais l’observation des vrais comportements des vrais utilisateurs sur le vrai environnement de production avec les vraies données et les vraies configurations.
J’aime bien résumer ce constat avec cette phrase : “La vérité est en prod’.”
Cela ne veut pas dire que cela ne sert à rien de faire des tests avant de mettre en production. Cela ne veut pas dire non plus que les métiers n'ont aucune valeur et qu’on n’a pas besoin d’eux.
Cela veut dire que, quoi que l’on fasse, il ne faudra jamais oublier de vérifier les résultats en production, et que rien n’aura plus de poids que ces derniers.
Qu’attend-on réellement de l’équipe ?
Une autre manière d’analyser le principe d’UAT, c’est de réfléchir en termes de responsabilités et par extension de voir quelle dynamique d’équipe cela encourage-t-il.
Cela revient à se poser cette question : qu’attend-on de l’équipe ?
Avant d’aller plus loin, je tiens à préciser que mon propos n’est absolument pas de suggérer que les métiers seraient superflus ou que l’équipe devrait se passer de ces derniers.
Par contre, il y a souvent des dynamiques contre-productives, comme les équipes DSI en posture d’exécutant vis-à-vis des métiers. Mais attention ! Quand cela arrive, ce n’est pas toujours la faute aux métiers qui les positionneraient ainsi. Bien au contraire, c’est même généralement les équipes DSI qui se positionnent en tant que tel, d’elles-mêmes, alors que les métiers aspireraient à avoir un véritable partenaire en face.4
Prenons cet angle pour analyser le sujet de l’UAT. Si cela part d’un bon sentiment, il est important de réaliser ce l’UAT encourage ou renforce cette dynamique où les équipes DSI sont des exécutants vis-à-vis des métiers. On s’interdit de mettre en production quoi que ce soit qui n’a pas eu le go des métiers : ainsi, on laisse reposer toute la responsabilité sur les épaules des métiers.
Je m’attends à ce que pas grand monde ne soit d’accord avec moi, car ce n’est pas l’intention qui est derrière — ce que je ne remets pas en cause. Néanmoins, j’invite à prendre du recul et à observer la situation de manière dépassionnée, pour réaliser qu’indépendamment de l’intention c’est bien la dynamique qui est créée.
Paradoxe même de cette situation, la perspective de changer cette dynamique peut faire peur : car cela implique un changement de responsabilités qui n’est pas anodin.
La pertinence des métiers est dans la définition des cas de test, pas dans leur exécution
Je redis que mon but n’est pas que les équipes DSI se passent des métiers. Cela n’aurait aucun sens. Il est par contre crucial de créer une relation différente avec les métiers, de continuer de s’appuyer sur ces derniers mais pas pour les mêmes choses.
Concrètement, la valeur des métiers est justement dans leur connaissance métier. C’est bien leur connaissance métier que l’on veut extraire et non directement les faire tester.
J’explique plus loin dans cet article, à propos du Shift Left, comment actionner ce changement de dynamique. Toujours est-il qu’il n’est nullement nécessaire que les métiers testent eux-mêmes.
Eviter la facilité
Bien sûr, impliquer les métiers dans la définition des tests mais pas dans leur exécution, cela nécessite de véritables compétences et excellences techniques et méthodologiques. La triste réalité, c’est qu’on voit trop souvent une forme de facilité qui s’en remet intégralement à l’UAT, plutôt que de juger soi-même de la pertinence des tests et surtout d’en assumer les conséquences ensuite.
Sans en faire une généralité, force est de constater que de trop nombreux développeurs trouvent normal de livrer du code qui ne fonctionne pas. Comme souvent, c’est surtout qu’ils n’ont jamais connu de contexte où ce n’était pas ainsi.
Pourtant, cela ne devrait pas être le cas. On devrait toujours livrer du code qui marche !!!
Les approches alternatives que je vous partage ci-dessous font, au contraire, cette hypothèse que l’on peut livrer du code qui marche — en s’y prenant bien.
Comment faire autrement que l’UAT
On vient de voir que le principe d’UAT, en plus de poser des problèmes, n’avait pas réellement de sens sur le fond. Alors, comment faire ? Quelles sont les alternatives ?
Comment faire si on s’interdit de mettre en place une phase de validation avec les utilisateurs ou les métiers ?
Les réponses s’appellent : Shift Left et Shift Right. Ces deux approches sont complémentaires.5
Leur point commun est qu’elles font en sorte de ne plus avoir de phase de validation formelle avant mise en production qui dépend de personnes externes à l’équipe, ce qui est le reproche principal de l’UAT en termes d’impact sur la performance.
Il y a plein d’autres avantages à appliquer ces approches 😉 et je vous invite fortement à vous y intéresser quoi qu’il arrive !
Shift Left : travailler avec les métiers en amont plutôt qu’en aval
Dans un processus de développement logiciel typique, l’effort de test se situe après le développement et avant la mise en production.
Le Shift Left consiste à décaler vers la gauche l’essentiel de cet effort de test, avant et pendant le développement plutôt qu’après. Dans notre cas de figure, cela se manifeste en particulier par ces deux approches : 6
Lors des différents affinages ou refinements pour spécifier les fonctionnalités via les scénarios de test et les jeux de données. On peut par exemple s’outiller avec des approches telles que le Behavior-Driven Development et l’Example Mapping. 7 S’il y a toujours une phase d’exécution des tests qui suit le développement, celle-ci se réduit à peau de chagrin car le gros de l’effort est fait en amont sur la conception de ces derniers.
En automatisant les tests, autant les tests d’acceptation que l’on aura défini précédemment via l’approche BDD, que les tests de non-régression. Ces tests peuvent alors être lancés à foison pour un coût dérisoire. L’essentiel de l’effort passé sur ces tests est concentré sur leur écriture via des tests automatisés.
Cela peut sembler difficile à mettre en place. On est généralement persuadé que les métiers ne voudront jamais lâcher la main sur la validation avant mise en production. De mon expérience, j’ai plutôt vu ceci :
Spécifier le plan de test détaillé en amont du développement et demander une validation là-dessus, c’est avant tout faire preuve de professionnalisme. Inutile d’avoir peur ou honte de proposer de faire ainsi.
Les métiers ne voudront pas lâcher la main sur la validation s’il y a un historique de versions bourrées de bugs, auquel cas la confiance est clairement brisée. Dans ce cas, n’essayez pas de les convaincre de faire autrement : la confiance ne se décrète pas. Donnez-leur simplement des versions sans bug. Au bout d’un moment, ils arrêteront de tester d’eux-mêmes. Ils auront bien mieux à faire !
Voici mon dernier conseil : une phrase puissante qui m’a beaucoup servi pour impliquer pleinement les métiers dans ce travail de spécification du plan de test en amont du développement. L’idée est de commencer par préparer une première version du plan de test, au mieux des possibilités de l’équipe. Puis de la soumettre à un métier en lui demandant :
Voici la liste exhaustive des cas de test que nous avons imaginé.
Dans l’hypothèse où nous exécutons tous ces cas de test nous-mêmes, et où tous les résultats sont OK, est-ce que pour toi on peut pousser cette fonctionnalité en production sans que tu n’aies à vérifier quoi que ce soit d’autre ?
Implication garantie 👌
Shift Right : surveiller les comportements réels après mise en production plutôt que dans un environnement artificiel avant
Cette fois, le Shift Right consiste à décaler vers la droite l’effort de test, après la mise en production plutôt qu’avant.
Si le Shift Left vise à mieux gérer le travail de validation avant mise en production, le Shift Right vise à aller vérifier en production la véritable adéquation avec le terrain plutôt que d’essayer de s’en assurer dans un environnement forcément artificiel, autre que la production.
Cette fois-ci, il est donc question de mettre en place du monitoring pour pouvoir suivre le comportement de la solution et de ses utilisateurs en production. On peut compléter par de l’alerting pour réagir au plus tôt lorsque des incohérences sont détecter.
Il est également question de faire des tests A/B en validant en production si un changement apporte les bénéfices attendus ou non, plutôt qu’avec des représentants des utilisateurs dans un environnement contrôlé de pré-production.
Avec ces pratiques, on résout directement le problème des métiers qui ne sont que des représentants des vrais utilisateurs, en instrumentant directement la prod’. Cela rend caduque d’avoir une phase d’UAT, puisque l’on peut avoir ainsi un feedback bien plus pertinent.
Pour conclure
Dès lors que le flux de travail de votre équipe est en attente de personnes externes, ce qui en bloque la fluidité, ne l’acceptez pas comme une contrainte naturelle et normale avec laquelle il faut vivre. Au contraire c’est certainement un signal qu’il faudrait travailler autrement.
Avec des approches comme le Shift Left et le Shift Right, les bénéfices de ces approches vont bien au-delà de la fluidification du flux de travail. Par contre, cela nécessite souvent de véritables changements de paradigme et c’est pourquoi leur mise en place n’est pas toujours une évidence pour les équipes.
Il n’y a pas d’échappatoire : tout commence par l’excellence technique.
UAT est l’acronyme de User Acceptance Testing. Dans un cycle de développement logiciel, il s’agit d’une phase où l’on fait tester les utilisateurs pour bien confirmer que la solution répond à leur besoin.
Par extension, on peut parler d’UAT pour désigner un environnement, similaire à l’environnement de production en termes de données, prévu pour y mener des activités d’UAT.
Dans un grand groupe et sa DSI, on a tendance à détourner légèrement le sens d’UAT en faisant tester par des référents ou des experts métiers plutôt que par des utilisateurs finaux de la solution. Ce détail devrait déjà mettre la puce à l’oreille sur le fait que derrière l’UAT est une approche naïve : on ne sait pas comment faire valider par des utilisateurs en amont de la production (ou on ne trouve pas que cela soit faisable ou réaliste en pratique) alors on teste autre chose à la place, potentiellement en perdant de vue l’intention d’origine au passage.
L’UAT n’est pas une recette. La recette se veut fonctionnelle, presque technique : on valide que chaque élément de la solution, chaque fonctionnalité, est bien présente et fonctionne comme spécifiée. L’UAT se focalise sur la résolution du problème. Cet autre point devrait également mettre la puce à l’oreille sur la naïveté de l’approche UAT : rien n’est plus important que de s’assurer que le besoin des utilisateurs est bien satisfait, or l’UAT est généralement la dernière phase avant mise en production ; c’est-à-dire que l’on lève le plus tard possible le plus grand risque du projet. 🙈
Le concept de Feature Flags porte divers noms dans l’industrie comme par exemple le Feature Flipping. Cela consiste à livrer du code qui est inactif, permettant ensuite d’activer ou de désactiver ce code sans faire de nouveau déploiement. C’est le même genre de mécanisme qui permet de faire des tests A/B.
Si tu découvres ce concept, nous l’avions expliqué dans ce Scrum Life : (explication à 04:18)
Je précise, s’il le fallait, que c’est bel et bien possible. Je pourrais parler de mes propres expériences ou pointer du doigt de nombreux retours d’expériences via des articles ou des conférences. Je préfère parler du DORA qui partage chaque année un rapport sur la performance des équipes de développement logiciel avec un benchmark du pourcentage du niveau de performance des différents répondants.
Bref, c’est une réalité, totalement atteignable. Loin de moi de dire que c’est facile, il faut s’en donner les moyens.
Si tu ne connais pas le DORA, j’en parlais dans cet article récent :
J’évoquais cette dynamique de comment se positionner en tant que partenaire dans mon précédent article :
Dans cet ancien Scrum Life, je faisais un tour rapide du métier de testeur agile. J’y explique, entre autres choses, ces concepts de Shift Left et de Shift Right :
Il existe d’autres manières de faire du Shift Left mais elles s’adressent plus au rôle du testeur intégré dans l’équipe agile, qu’à l’UAT qui implique des métiers externes à l’équipe.
C’est pourquoi je décide de ne pas détailler ces derniers dans cet article, mais j’en parle par exemple dans la vidéo ci-dessus sur le rôle de testeur agile.
Ces concepts sont plein de nuances, je faisais le lien avec la fait de faire émerger la spécification dans ce Scrum Life :
Et pour découvrir l’Example Mapping :
