Croyances vs réalités

L’herbe est toujours plus verte de l’autre côté!

J’aime beaucoup ce proverbe car ce que l’on n’a pas est souvent idéalisé et engendre de nombreuses croyances erronées. Le but de cet article est de démonter certaines de ces croyances.

·        Un unique testeur peut être en charge de tous les tests

Le test logiciel regroupe maintenant un trop grand nombre de métiers différents pour que quelqu’un ait l’ensemble des connaissances requises. Il y a des tests managers des testeurs automaticiens, analystes de test, spécialistes des environnements de tests, des tests de performances, des processus…

·        Une application testée est une application sans défaut

Je reviens très souvent sur ce cliché mais il a la vie dure. Les tests ont pour but de donner une visibilité sur la qualité d’une application. Lorsque le niveau de qualité souhaité est atteint alors l’application est publiée. Cela ne veut pas dire qu’il ne reste pas d’anomalies ! Il ne faut pas non plus oublier que l’erreur est humaine et que le testeur peut également faire des erreurs et ne pas remarquer certaines anomalies impactantes (par exemple avec une mauvaise estimation d’un risque)

·        Pour bien tester il suffit d’automatiser

L’automatisation seule ne sert à rien ! Ce n’est pas parce que des tests sont automatisés qu’ils sont exécutés. Ce n’est pas parce qu’ils sont automatisés qu’ils sont pertinents ! Ce n’est pas parce qu’ils sont exécutés qu’ils sont analysés. L’automatisation est (très) pratique voire nécessaire dans certains modes de projets, néanmoins cela n’est pas une garantie de qualité !

·        L’automatisation des tests IHM permet de couvrir tous les autres niveaux d’automatisation

Cette idée reçue a été contredite lors de la présentation de Cyril Tardieu à la STLS. Beaucoup d’entreprises veulent se servir de l’automatisation des tests IHM pour couvrir plusieurs niveaux de test. Le problème c’est que les tests IHM sont très cher à développer et à maintenir si on les compare aux autres (intégration, tests unitaires…).

Voici la pyramide présentée pour les tests automatisés (image prise sur cet article) :

·        Si les tests unitaires sont bons alors tout est bon

Si c’était le cas les autres tests n’existeraient pas. Les tests unitaires testent une partie de l’application. Hors, une application ce n’est pas un ensemble de parties indépendantes mais bien un ensemble de parties travaillant conjointement. Les interactions avec les autres parties sont essentielles et doivent donc être testées.

Pour faire simple, une application est comme un puzzle ce n’est pas parce qu’une pièce est bonne (tests unitaire) qu’elle est au bon endroit et qu’elle s’emboite bien avec celles à ses côtés (intégration). Ce n’est pas parce que le puzzle représente bien une image de pyramide (tests système) que cette image de pyramide est celle que les utilisateurs veulent (tests d’acceptation).

·        Il n’y a pas de différences entre les tests systèmes et tests métiers

Là encore cette idée est fausse. En effet ce n’est pas parce que l’on répond aux spécifications que le logiciel répond au besoin. C’est d’ailleurs pour cela que les tests d’acceptations existent et se multiplient avec, par exemple, des phases de bêta test.

Pour revenir à mon exemple précédent : le puzzle avec un pyramide. Si le client est une entreprise d’Amérique du sud dont le business est le tourisme. Si le puzzle livré représente la pyramide de Gizeh, alors ce puzzle ne sera pas vendable et ce même si elle représente bien une pyramide, que le nombre de pièce, le coût de fabrication et la qualité de l’image sont ceux souhaités !

·        On peut implémenter du déploiement continu sur toutes les applications

Au mieux la livraison continue peut potentiellement l’être.

Le déploiement continu est, quand il est bien mis en place, quelque chose de fantastique. On a vu un exemple avec la mise en place du safety check par Facebook en 2 heures. Néanmoins aussi bien que cela soit, le déploiement continu ne peut pas être implémenté partout pour plusieurs raisons.

La première est la maturité des tests de l’application. Certes cette maturité peut augmenter mais il ne faut jamais oublier que déploiement continu = livraison en production.

La seconde, la plus limitante, est que pour faire un déploiement continu il faut avoir la possibilité d’accéder à cette production. Par exemple, sur les stores des applications natives mobiles (Play et App store), il faut d’abord avoir une validation pour pouvoir publier sa nouvelle version. Dès lors, une multiplication des déploiements dans la journée est impossible.

·        Pour augmenter sa productivité il suffit de rajouter des développeurs

J’en parle dans mon dernier article. La productivité ce n’est pas le nombre de ligne de code que l’on produit. Ce n’est pas en ajoutant des développeurs, ni même tout autre profil, que l’on augmentera la productivité. Non, pour augmenter sa productivité il faut, à partir d’un certain moment, avoir des processus (test, merge, déploiement…) fiables et bien définis.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles