L’exécution seule…

L’exécution seule est un gros problème dans le métier du test et ce pour plusieurs points:

·        C’est la caricature du métier : on croit souvent qu’un testeur ne fait qu’exécuter des tests. cette réduction est la même que si l’on disait qu’un recruteur ne faisait que faire passer des entretiens…

·        Elle n’apporte aucune valeur : Qui est capable de me donner la qualité d’un logiciel si je dis simplement que 25% des cas sont en échec ? (remarque : rien qu’en sachant qu’il y a 25% d’échec je suis allé au-delà d’une exécution simple, j’ai regardé les résultats… Même ça, ce n’est pas toujours fait)

·        Elle est dangereuse ! Et je pèse mes mots. Elle est dangereuse car elle donne l’impression que du travail est effectué et accroit la confiance sur la qualité de l’application alors qu’en fait on n’a aucune visibilité. Je ne dirais pas combien de fois ai-je entendu : « c’est bon, il y a des tests qui tournent toutes les nuits »

·        C’est une perte de temps et d’argent. Perte de temps car même si les tests sont automatisés et se lancent à intervalle régulier il faut du temps pour mettre ce système en place. C’est également une perte d’argent car cela consomme du temps machine, de l’énergie et même, dans le pire des cas (quand les tests sont manuels) des jours homme !

Je me suis donc demandé « pourquoi » ! Pourquoi ce phénomène est si répandu dans les entreprises ?

Les réponses que j’ai trouvées sont :

·        Pour certaines personnes cela n’est pas aberrant. Merci les préjugés !

·        Les tests sont souvent une des premières coupes de budget sur une application.

·        Par manque de temps dans les équipes.

·        Car il y a trop de tests (ou qu’ils ne sont pas maintenus).

·        Il n’y a pas encore eu de bug majeur ou critique en production suite à ces pratiques (mais cela ne serait tarder !)

Voici donc des réponses pour se battre contre ce phénomène (en répondant à chaque point):

·        Faire connaitre le métier du test. Rappeler que tester ce n’est pas que l’exécution et qu’il y a beaucoup de choses  à côté et que c’est justement ce qui fait la valeur du test et des testeurs.

·        Le retour sur investissement des tests est réel. Néanmoins si coupe il y a il ne faut absolument pas garder tous les tests si l’on n’est pas capable d’analyser les tests. Il vaut mieux 100 tests, stables fiables et analysés que 1000 non analysés. Dans ce cas-là le métier du test est particulièrement important car il faut savoir faire des sélections, hiérarchiser les cas et donc optimiser la couverture.

·        La réponse est la même que pour le point précédent. Si on manque de temps il faut faire un tri ! Ce tri doit être fait dans les cas de tests, pas dans les phases (exécution, analyse, gestion des bugs…) du test !

·        Là encore le tri est nécessaire.

·        Le but des tests est justement d’éviter des problèmes en production. Autant limiter au maximum les chances de bugs en production, c’est quand même la base du métier ! Mieux vaut prévenir que guérir.

J’ai malheureusement trop souvent fait face à des situations où l’analyse des tests n’était pas faite. Cela a toujours fini avec des gros trous dans les couvertures de test. Des décisions prises au « doigt mouillés » car trop de tests en échecs… Cela a toujours fini par des bugs majeurs (ou même critiques) qui auraient pourtant été détectés si les tests avaient été analysés !

Je finirai par cette phrase :

La fin de l’exécution des tests c’est le vrai début du travail de testeur sur une campagne de test !

N’hésitez pas à rejoindre le groupe Le métier du test

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.