Tester c'est douter, la qualité coûte cher!

Qui n'a pas entendu le dicton Tester c'est douter. Certes ce dicton reste peu crédible. Bien que c'est une façon s'excuser de ne pas faire des tests sur le ton de la rigolade, personne croit vraiment que cela soit une bonne approche. Par contre La qualité coûte cher est déjà plus crédible dans l'oreille des gens. Pourtant cela est tout aussi faux.

Faux? Ah bon, vraiment? La qualité ne coûterait pas cher?
Non. Je dirais que c'est la non-qualité qui coûte cher. Et ce même à court terme! Visiblement, au regard des projets que je vois passer, tout le monde ne partage pas mon avis et pense que cela vient en partie d'un regard différent que l'on porte sur nos projets;

D'abord dev puis test

Si on aperçoit le coût de dev séparément de sa validation, si on divise l'écriture du code et l'écriture des tests une fois le code fini, on va voir un coût de dev. Puis un coût d'écriture des tests. Puis le coût de validation manuelle. Dans ce monde la qualité a un coût très mesurable, c'est déjà l'ensemble de l'écriture des tests. C'est aussi tout éventuel refactoring énoncé lors du dev. Dans ce système on cherchera naturellement à réduire les coûts qui n'ont pas un intérêt évident. Soit en caricaturant faire le dev vite fait mal fait, sauter les tests au profit d'une autre story. Certes on garde les tests manuels car sinon il y aurait trop de bugs en prod.

Test au fil de l'eau (~TDD)

Si au contraire on rend visible le temps passé entre début de dev et le tampon de validation de la part du PO et des testeurs, voire jusqu'au stabilisation en prod pour les plus modernes des chaines de livraison continue. Alors une méthode de dev qui supprime les retours des testeurs et PO deviendra beaucoup plus intéressante. En effet le fait de spécifier à travers des exemples deviendra naturelle pour éviter les erreurs d'interprétation, ces exemples deviennent au fur et au mesure du dev des tests automatisés et la validation manuelle après-dev se réduira au stricte minimum. Il n'y a plus d'erreurs de compréhension à détecter à la fin, car elles sont toutes relevées en amont du moindre ligne de code.

Dans le premier mode de travail la qualité, en termes d'écriture de tests après dev, a un coût difficile à rentabiliser. Dans le deuxième cas les tests sont naturelles et rentabilisés par conception de mode de travail.

C'est notre regard sur le système qui dictera le façon que nous l'optimiserons. Si nous voulons un changement de fonctionnement il faut trouver un nouveau regard.