Dans de nombreuses organisations, le déploiement en production des changements de code passe par une étape de tests manuels réalisés par des utilisateurs (des “tests d'acceptation utilisateur”), en charge de vérifier le bon fonctionnement et la non régression du produit. Ce sont généralement des personnes internes et expertes du métier, mais pas expertes du test. Ce travail s’ajoute à leur “vrai” travail. Idéalement, elles n’ont pas de temps à y accorder.
Cette approche à souvent des effets néfastes:
Par lassitude, les tests sont négligés, voire abandonnés.
Les utilisateurs reprochent aux développeurs de reporter les tests sur eux.
Chacun fait confiance à l’autre pour tester, et au final personne ne teste vraiment.
En cas de problème ou de défaut, développeurs et utilisateurs-testeurs s’accusent mutuellement.
On déploie moins souvent en production, en croyant que ça va économiser de l’effort et abaisser certaines peurs.
On limite les tests aux zones qu’on croit avoir impacté, et on prend le risque de détecter certains problèmes seulement en production, là où c’est le plus douloureux.
Ces tests manuels ralentissent progressivement la livraison de valeur, ne protègent pas suffisamment des risques de défauts, et encouragent la déresponsabilisation.
Pour délivrer régulièrement et fréquemment de la valeur aux utilisateurs, les développeurs, et leur environnement, doivent prendre conscience que le test fait partie du développement. Certaines approches placent même le test en premier, pour guider le développement (TDD, BDD). Ainsi les notions de spécification et de test se confondent, ce qui met en capacité les développeurs d’écrire du code fonctionnel testé, de qualité supérieure, réduisant significativement le besoin de vérification manuelle supplémentaire.