Les 10 lois immuables des tests

Il y a 10 lois qui régissent tout ce que Peter sait sur les tests. Ce n’est pas toujours joli (et ce n’est pas toujours gentil) mais ils sont toujours vrais.

J’ai des opinions sur les tests, motivées par ces 10 lois. Je suppose que je ne sais pas que ces lois sont vraiment « immuables », mais elles sont vraies depuis environ 80 ans et elles continueront d’être vraies tant que les utilisateurs continueront à vouloir plus de fonctionnalités et que les développeurs continueront à les fournir en utilisant code. Donc : Assez proche pour moi.

Mais il existe un moyen de modifier bon nombre de ces lois.

Les lois

1. Le nombre de bogues mesure ce qui agace le plus nos utilisateurs.

Les bogues ne sont pas une mesure de la qualité (qui est mesurée par des éléments tels que l’adéquation à un objectif, une livraison fiable, le coût et d’autres éléments). Mais les bugs sont quoi ennuyent le plus nos utilisateurs. Si vous ne me croyez pas, considérez ceci : plus de 60% des utilisateurs supprimer une application si elle se fige, plante ou affiche un message d’erreur. Signal Punk.

2. Les bogues existent parce que nous les écrivons dans notre code : la complexité va à l’encontre des bonnes intentions.

Nous savons tous d’où viennent les bogues : les développeurs qui écrivent du code (activé par les utilisateurs qui souhaitent de nouvelles fonctionnalités). Les bogues sont la preuve visible que notre code est suffisamment compliqué pour que nous ne le comprenions pas entièrement. Nous n’aimons pas créer de bogues et souhaitons ne pas le faire et avoir développé certaines capacités d’adaptation pour résoudre le problème… mais nous écrivons toujours des bogues dans notre code.

3. Les bogues (comme les tchotchkes) s’accumulent au fil du temps – chaque fois que nous ajoutons ou modifions des fonctionnalités, pour être précis.

Tout le monde a un Tante Edna où le résultat inévitable de sa sortie est qu’elle ramène à la maison quelque chose de nouveau à mettre sur une étagère. Le résultat inévitable de la création de logiciels est plus de bogues (et, oui, plus/meilleures fonctionnalités). Comme les tchotchkes de tante Edna, sans une action positive (arrêter tante Edna à la caisse enregistreuse saute à l’esprit), les tchotchkes et les bugs s’accumulent avec le temps. Lorsque les bogues s’accumulent, l’application devient inutilisable ou, à tout le moins, inutilisée (voir Loi 1).

4. Les tests sont le seul outil auquel nous ayons confiance pour trouver des bogues.

Et c’est pourquoi nous avons des tests. Alors que d’autres moyens d’éliminer les bogues ont été suggérés (<cough> logiciel prouvé correct </cough>,
<cough> logiciel contractuel <cough>), ils n’ont jamais compris.

5. Tout ce que vous ne testez pas a au moins un bogue, probablement plus.

Cette loi n’est évidemment que le résultat de la trois lois précédentes. J’ai toujours été contre l’idée de logiciel zéro défaut comme non seulement historiquement sans fondement (ce n’est jamais arrivé) mais physiquement impossible (cela ne peut pas être fait). Les bogues dans les choses que vous ne testez pas sont toujours des bogues – ce sont juste les bogues que vous ne connaissez pas.

6. Les tests ne sont pas une tâche à valeur ajoutée.

Si « tester » signifie « réduire les bogues », alors cela place les tests dans la catégorie « travail nécessaire » : ce que nous devons faire pour apporter de la valeur (c’est-à-dire, de nouvelles fonctionnalités). C’est parce que les seules personnes qui peuvent décider de ce qui a de la valeur sont les personnes qui utilisent notre logiciel, et ce qu’elles veulent, ce sont de nouvelles fonctionnalités. Si nous pouvions créer un logiciel sans bogue sans test, nos utilisateurs ne s’en plaindraient pas.

Le seul moment où les tests commencent à passer à la catégorie à valeur ajoutée est lorsque nous testons une transaction utilisateur de bout en bout et, même dans ce cas, probablement uniquement lorsque l’utilisateur est impliqué dans l’élaboration du test.

7. Ce que nous faisons, c’est gérer le risque.

Étant donné que l’objectif d’une tâche nécessaire est de réduire le temps et les coûts afin que plus de temps/d’argent puisse être consacré à des tâches à valeur ajoutée, il n’y aura jamais assez de temps/d’argent pour produire un logiciel sans bogue. L’automatisation des tests de régression, par exemple, est intéressante car elle nous permet de nous rapprocher de tout tester tout en réduisant les coûts. Mais, même ainsi, nous n’avons jamais assez de temps/d’argent et sommes toujours hiérarchiser. La base de nos priorités est le risque : combien coûterait la correction d’un bogue dans ce domaine s’il entrait en production ?

8. Il est facile de trouver des bogues au début ; plus tard, c’est plus difficile.

Pour citer Jane Austen à tort, « C’est une vérité universellement reconnue, qu’un bogue trouvé tôt est moins cher à corriger qu’un bogue trouvé plus tard. » Ce n’est pas que la correction d’un bogue soit toujours gratuite : nous ne pouvons pas corriger un bogue à moins de comprendre pourquoi il existe, et nous avons des bogues précisément parce que nous ne comprenons pas entièrement notre code (voir Loi 2 : les bogues existent parce que nous les écrivons).

Mais corriger un bogue tard dans le processus est à la fois difficile et coûteux, car un autre code dépend désormais du logiciel bogué. Non seulement cela augmente automatiquement le coût, mais cela bouleverse nos horaires car il s’avère qu’après tout ce temps, nous sommes toujours étonnamment mauvais pour estimer dans quelle mesure les corrections de bogues se répercutent sur notre logiciel.

Alors on commencer à tester plus tôt afin que nos coûts de test d’intégration – les seuls tests qui aient une valeur pour nos utilisateurs (voir Loi 6) – soient gérables.

9. Vous ne pouvez pas commencer assez tôt.

Combien de temps pouvez-vous commencer à tester ? Vous pouvez commencer par valider vos besoins.

Comme toute bonne loi, « commencer tôt » est vrai partout. Si vous avez testé un peu de code, par exemple, il n’y a aucune raison pour que vous ne puissiez pas commencer à le tester en charge – vous avez tous les ressources nécessaires. Et si vous n’allez pas commencer à tester, souvenez-vous de la loi 5 : tout ce que vous ne testez pas aura au moins un bogue, probablement plus.

Nous avons même des outils qui nous permettent de remonter dans le temps et de créer d’anciens logiciels compatible avec les tests automatisés.

10. Toutes les personnes impliquées dans l’assurance qualité (utilisateurs, analystes, testeurs, développeurs) sont engagées dans une guerre éternelle contre le chaos.

La définition habituelle des tests signifie qu’il ne s’agit pas d’ajouter de la qualité : au mieux, il s’agit d’éliminer les défauts et, compte tenu des contraintes de temps et de ressources, de gérer les risques en production et d’éviter le chaos dans le processus de développement. Puisque les bugs sont inévitables et s’accumulent inévitablement (Lois 2 et 3), les testeurs se défendent contre cela.

Changer les lois

Mais il ne doit pas en être ainsi. Les testeurs peuvent vraiment devenir les gardiens de la qualité et être considéré comme ajoutant de la valeur à la fourniture de fonctionnalités (et même en ajoutant de nouvelles fonctionnalités plus efficace). Et il ne serait pas juste de dire tout cela sans mentionner le merveilleux livre de Lisa Crispin et Janet Gregory Tests agilesce qui a influencé ma réflexion sur les tests plus que toute autre source unique.

Comme je l’ai dit autre part, les tests peuvent devenir une assurance qualité et peuvent passer de « quelque chose que nous devons faire » à « quelque chose que nous voulons faire ». Et ce serait très précieux.