User acceptance testing : le guide du fondateur non technique

Comment décider si le logiciel livré par votre prestataire est vraiment terminé, quoi tester quand vous ne lisez pas le code, et comment définir « terminé » avant que la première ligne soit écrite.

Un fondateur avec qui nous travaillons nous a transféré un jour un e-mail d’une ligne de son développeur : « Toutes les features sont prêtes, on peut lancer. » Il avait payé un portail client pendant quatre mois. Avant de virer la dernière tranche, il nous a posé une question simple : comment je sais que c’est vrai ?

Il ne lisait pas le code. Il ne savait pas distinguer une suite de tests qui passe d’une capture d’écran de cette même suite. Ce qu’il avait, c’était le sentiment que « on peut lancer » était l’avis du développeur, pas un fait qu’il pouvait vérifier. Cet écart, entre quelqu’un qui vous dit que le travail est terminé et vous qui savez qu’il l’est, c’est exactement l’écart que comble le user acceptance testing.

Le user acceptance testing (UAT) est la vérification finale avant qu’un logiciel passe en production, où de vrais utilisateurs confirment que le produit fait ce dont l’entreprise a réellement besoin, dans des conditions réelles. Il ne s’agit pas de trouver des bugs dans le code. Il s’agit de répondre à une question : est-ce que cette chose fait le travail pour lequel on a payé ? Pour un fondateur non technique, l’UAT est l’heure la plus importante que vous passerez sur un projet, parce que c’est la seule partie du processus que vous êtes qualifié pour mener sans savoir programmer.

Ce qu’est vraiment le user acceptance testing

La plupart des définitions que vous trouvez en ligne sont écrites pour des ingénieurs QA, alors elles enterrent la partie qui compte pour vous. Une fois dépouillé, l’UAT, c’est ceci : une personne qui représente l’entreprise utilise le logiciel comme le ferait un vrai client ou employé, face à une liste écrite de ce qu’il est censé faire, et ne valide que lorsque chaque point fonctionne.

Le « user » dans user acceptance testing est le cœur du sujet. L’organisme de normalisation de l’industrie du logiciel elle-même, l’ISTQB, définit le test d’acceptation comme celui qui établit s’il faut accepter un système, ce qui est une façon polie de dire qu’il existe pour répondre à une question métier par oui ou par non. Les tests précédents vérifient si le code se comporte comme les ingénieurs le voulaient. L’UAT vérifie si ce que les ingénieurs voulaient correspond à ce dont l’entreprise avait besoin. Ce sont des questions différentes, et la seconde est la vôtre. Un développeur peut construire un tunnel de paiement impeccable qui applique le mauvais taux de taxe pour votre marché. Le code est correct. Le produit est faux. Seul quelqu’un qui comprend le métier le repère, et ce quelqu’un, c’est généralement vous.

C’est pourquoi l’UAT est le travail du fondateur, pas du prestataire. Quand vous externalisez le build à une software house ou à un freelance, vous pouvez externaliser l’ingénierie, l’architecture, même la gestion de projet. Ce que vous ne pouvez pas externaliser, c’est le jugement sur la question de savoir si le résultat sert votre entreprise. Cela reste entre les mains de celui qui détient le résultat métier.

UAT contre QA : qui teste quoi

Les fondateurs confondent les deux en permanence, et la confusion coûte de l’argent. Voici la séparation nette.

Le quality assurance (QA) est la responsabilité du développeur. C’est le test interne, mené par les gens de l’équipe de build, qui vérifie que le logiciel fonctionne comme spécifié : les boutons répondent, les données s’enregistrent, l’API renvoie ce qu’elle doit, rien ne casse sous la charge. Les bons prestataires font cela avant même de vous montrer le produit. Si un écran renvoie une erreur à l’instant où vous l’ouvrez, le QA a échoué, et ça, c’est leur affaire.

Le user acceptance testing est votre responsabilité. Il arrive après que le QA est passé, et il vérifie quelque chose que le QA ne peut pas : si « fonctionne comme spécifié » correspond à « fonctionne pour l’entreprise ». Le QA du prestataire confirme que le générateur de factures produit un PDF. Vous seul confirmez que le PDF porte la raison sociale de votre entreprise, les bonnes conditions de paiement et le détail de TVA dont votre comptable a besoin.

La règle pratique que nous donnons aux fondateurs : si la défaillance est « le logiciel est cassé », c’est du QA, renvoyez-le sans cérémonie. Si la défaillance est « le logiciel fonctionne mais ce n’est pas ce dont nous avons besoin », c’est de l’UAT, et c’est une conversation sur le périmètre, pas un rapport de bug. Savoir dans quel panier tombe un problème vous dit si vous avez droit à une correction gratuite ou si vous demandez un nouveau travail. Nous avons écrit plus longuement sur la façon dont le périmètre s’étend sans que personne ne le remarque dans notre article sur le feature creep, et l’UAT est là où cette tension éclate.

L’erreur qui transforme l’UAT en bagarre

Voici le piège. La plupart des fondateurs non techniques entendent les mots « user acceptance testing » pour la première fois à la fin du projet, quand le prestataire dit « nous sommes prêts pour votre validation ». À ce stade, il est déjà trop tard pour bien le faire, parce que l’UAT n’a aucun sens sans critères d’acceptation, et les critères d’acceptation doivent exister avant que le build commence.

Les critères d’acceptation sont les conditions écrites, précises et vérifiables qui définissent « terminé » pour chaque feature. Pas « construire un système de connexion ». Plutôt : « un utilisateur peut s’inscrire avec un e-mail et un mot de passe, reçoit un e-mail de confirmation en moins de deux minutes, peut réinitialiser un mot de passe oublié et est bloqué après cinq tentatives échouées ». Voilà quelque chose que vous pouvez tester. « Un système de connexion », c’est quelque chose dont on peut débattre.

La raison pour laquelle cela compte tant pour les fondateurs qui n’ont pas écrit la spécification eux-mêmes : si « terminé » n’a jamais été défini par écrit, alors à la fin du projet « terminé » devient ce que le prestataire dit que c’est, et vous n’avez aucune base pour le contester. Nous avons vu des fondateurs perdre ce débat en temps réel. Le développeur dit que la feature est complète. Le fondateur sent qu’elle ne l’est pas. Aucun des deux ne peut pointer un document. Le fondateur paie, parce que l’alternative est une bagarre avec celui qui détient son code.

Définissez les critères dès le départ et la dynamique s’inverse. Maintenant « terminé » est une checklist que les deux parties ont approuvée, et l’UAT consiste seulement à parcourir la checklist. C’est pourquoi les critères d’acceptation appartiennent à deux documents avant que quiconque écrive du code : votre document d’exigences logicielles, où chaque feature reçoit ses conditions vérifiables, et votre contrat de développement logiciel, où l’acceptation est liée au paiement final. Si votre contrat libère la dernière tranche à la « livraison » plutôt qu’à l’« acceptation », corrigez cela avant de signer. Le mot pèse lourd.

Un playbook UAT que vous menez sans écrire de code

Vous n’avez pas besoin de savoir comment le logiciel est construit pour mener un test d’acceptation rigoureux. Vous devez être organisé et un peu têtu. Voici la séquence que nous remettons aux fondateurs.

1. Testez face aux critères, pas face à votre humeur. Ouvrez les critères d’acceptation que vous avez écrits plus tôt. Allez feature par feature, condition par condition. Pour chacune, la réponse est binaire : elle fait ceci, ou elle ne le fait pas. Résistez à l’envie de tester « le ressenti ». Les ressentis sont réels, mais c’est une conversation à part ; pour l’instant, vous vérifiez des faits face à une liste.

2. Utilisez de vraies données et de vrais scénarios. C’est là que les fondateurs trouvent les problèmes qui comptent. Ne testez pas l’outil de facturation avec « Société Test » et un montant d’un euro. Faites passer les vrais chiffres de votre plus gros client. Faites passer le cas limite que vous savez compliqué : le remboursement, le paiement partiel, le client dans une autre région. Un exemple concret tiré d’un build que nous avons audité : le logiciel gérait parfaitement les nouveaux abonnements et cassait complètement sur les résiliations, parce que personne n’avait testé une résiliation. Le critère disait « gérer les abonnements ». Résilier, c’est gérer un abonnement. C’est parti en production cassé parce que l’UAT n’avait testé que le chemin heureux.

3. Testez sur les appareils que vos utilisateurs utilisent vraiment. Si la moitié de vos clients sont sur mobile, testez sur mobile, pas seulement sur le portable où le développeur a fait sa démo. « Fonctionne sur ordinateur » n’est pas « fonctionne ».

4. Notez chaque défaillance avec précision. « Le truc bugue » n’aide personne. « Quand je clique sur Envoyer dans le formulaire de contact avec une adresse Gmail, rien ne se passe, et la page n’affiche pas d’erreur » est un rapport sur lequel un développeur agit le jour même. La précision fait la différence entre une correction cette semaine et un aller-retour qui en prend trois.

5. Séparez « cassé » de « ce n’est pas ce que je voulais ». Classez chaque défaillance dans les deux paniers précédents. Cassé revient comme un défaut, corrigé sans frais. « Ce n’est pas ce que je voulais mais ça correspond au critère » est une demande de changement, ce qui signifie un nouveau périmètre et peut-être un nouveau budget. Être honnête sur ce qui relève de quoi empêche la relation avec votre prestataire de devenir conflictuelle.

6. Validez par écrit, critère par critère. Quand une feature passe, consignez-le. Quand la liste entière passe, c’est votre acceptation, et c’est le déclencheur du paiement final auquel votre contrat devrait être lié. Ne validez pas l’ensemble dans un seul e-mail pour en finir. La checklist est votre marge de manœuvre et votre archive.

Menez ces six étapes et vous aurez fait quelque chose que la plupart des fondateurs ne font jamais : vous avez remplacé « je pense que c’est bon » par « voici ce que j’ai vérifié ». Cela vaut plus que n’importe quelle connaissance technique qui vous manque.

Quand l’UAT vous dit que quelque chose ne va pas

Parfois le test échoue et le prestataire renvoie la balle. Il dira que le point en échec n’était pas dans le périmètre, ou que c’est un cas limite, ou que le corriger est en supplément. De temps en temps, il a raison. Souvent, le désaccord est exactement la raison pour laquelle vous avez écrit des critères à l’avance, alors revenez au document et voyez ce qu’il dit. Si les critères le couvraient, c’est un défaut. S’ils ne le couvraient pas, vous avez appris quelque chose sur votre propre spécification, et vous négociez maintenant un changement, pas un litige d’opinion.

Si l’UAT fait remonter des problèmes assez profonds pour que vous commenciez à douter du build entier, c’est un signal différent et plus grave. Une seule feature cassée est une correction. Un schéma de features qui tournent techniquement mais ratent de façon constante le besoin métier signifie en général que la spécification et le builder n’ont jamais vraiment été alignés, et aucune dose de test d’acceptation ne rapièce cela. C’est le moment de faire intervenir une lecture indépendante du code avant d’y verser plus d’argent. Nous avons expliqué comment faire dans notre guide de la technical due diligence.

La version saine de cette relation n’est pas un prestataire qui passe chaque test du premier coup. C’est un prestataire qui a pris son QA assez au sérieux pour que votre UAT trouve des écarts d’adéquation au métier, pas des plantages, et qui traite votre checklist comme le contrat qu’elle est. Les bons veulent les critères dès le départ autant que vous devriez les vouloir. Cela les protège aussi.

Questions fréquentes

Qu’est-ce que le user acceptance testing en termes simples ?
C’est la vérification finale, menée par quelqu’un qui représente l’entreprise, qui confirme que le logiciel terminé fait ce dont l’entreprise a réellement besoin avant la mise en production. Il teste l’adéquation à l’usage, pas la qualité du code.

Quelle est la différence entre QA et UAT ?
Le QA, c’est l’équipe de build qui confirme que le logiciel fonctionne comme spécifié. L’UAT, c’est vous qui confirmez que la spécification était la bonne pour l’entreprise. Le QA attrape « c’est cassé ». L’UAT attrape « ça fonctionne mais c’est faux ».

Quel est un exemple de user acceptance testing ?
Faire passer les vrais chiffres de votre plus gros client dans un nouvel outil de facturation, y compris un remboursement et un paiement partiel, et confirmer que chaque facture affiche la raison sociale, les conditions de paiement et les taxes correctes. Si chaque condition de votre liste écrite passe, la feature est acceptée.

Qui devrait mener l’UAT dans une startup ?
Celui qui détient le résultat métier, généralement le fondateur ou celui qui a écrit les exigences, éventuellement avec un ou deux vrais utilisateurs. Il ne devrait pas être mené par le prestataire qui a construit le produit ; cela en annule le but.

Combien gagne un testeur UAT ?
Cette question vient de gens qui se renseignent sur les carrières QA, pas de fondateurs qui achètent du logiciel. Pour vous, l’UAT n’est pas un poste salarié sur un petit build ; c’est une responsabilité que vous portez en tant qu’acheteur. Sur des produits plus gros, des testeurs dédiés existent, mais l’acceptation métier reste celle de l’entreprise.

Quand les critères d’acceptation doivent-ils être écrits ?
Avant que le build commence, à l’intérieur de votre document d’exigences, et référencés dans votre contrat. Des critères écrits après la livraison sont presque inutiles, parce qu’à ce stade « terminé » est ce que le prestataire dit que c’est.