Le mot : Pourquoi… Le meilleur ami du testeur !

C’est article est un article qui m’a demandé pas mal de travail et de réflexion. Lorsque j’ai commencé à travailler dessus il s’est fini par un article sur le but des tests.

Le sujet est en fait très large et, de mon point de vue, n’est pas uniquement lié au métier du test. Il n’est, pour moi, rien de plus démotivant que de se dire que ce que je fais ne sert à rien.

Le but de cet article sera donc l’utilisation de ce mot, cette question « Pourquoi ? » dans le test et de convaincre qu’il est un pilier fondamental du métier de testeur.

Tout commence par la stratégie de test et les plans de test.

Si l’on prend l’exemple des applications mobiles, la question « Pourquoi ?» se pose à plusieurs niveaux.

·        Pourquoi faire des tests ? La stratégie de ne faire aucun test est une stratégie!

·        Pourquoi cet OS ? Pourquoi pas un autre, quels utilisateurs ?

·        Pourquoi ces téléphones ? Quelle part de marché ? Quel % de notre cible ?

·        Pourquoi doit-on aller jusqu’à ce niveau de détail ? Quel niveau de qualité est souhaité ?

·        Pourquoi mettre en place ces processus ? A-t-on des problèmes suite à l’absence de ce processus ? Le retour sur investissement est-il présent avec ce processus pour notre projet ?

·        Pourquoi faire des tests exploratoires ? Qu’apportent-ils ?

·        Pourquoi ce mode de projet ? Les apports du Scrum sont-ils pertinents ? Faut-il choisir un cycle en V classique ?

·        …

Vient ensuite l’écriture des tests et leur exécution.

Ici les questions sont plutôt :

·        Pourquoi écrire ces tests comme cela ? est-ce que le test est bien compréhensible et non sujet à interprétation ?

·        Pourquoi écrire ce test ? Quel est l’apport de ce test à la campagne ? Que valide-t-il ? Fait-il doublon ?

·        Pourquoi écrire ce test ? Ce test a-t-il du sens ?

·        Pourquoi ce test ne sera pas un test de régression ? Ce test est-il sujet à des régressions ? Est-il une partie importante de la fonctionnalité ?

·        Pourquoi ce test sera-t-il un test de régression ? Ce test est-il sujet à des régressions ? Est-il une partie importante de la fonctionnalité ?

·        Pourquoi ce test sera-t-il un test vital ? Si ce test est en échec, cela met-il l’application en danger ?

·        Pourquoi ces processus de sélection des tests ? Quel est l’apport de ces processus ?

·        Pourquoi veut-on automatiser ? Y-a-til des contraintes de rapidité d’exécution ? Y-a-t-il retour sur investissement ?

·        Pourquoi l’automatisation de ce test et pas d’un autre ? Ce test sera-t-il souvent exécuté ? Evoluera-t-il souvent ?

·        Pourquoi exécuter ce test sur cet environnement ?

·        …

Il y a également la partie analyse et rapport qui est sujet à ce « Pourquoi »

Avec des questions comme :

·        Pourquoi ce test est en échec ? Est-ce un problème du test ? De L’environnement ? De l’application ?

·        Pourquoi est-ce un Bug ?

·        Pourquoi la criticité de ce bug est celle-ci ? Quel est son impact et sa probabilité d’occurrence ?

·        Pourquoi continuer l’analyse d’un bug avant de l’envoyer à un développeur ? Les informations collectées sont-elles suffisantes à la correction du bug ?

·        Pourquoi mettre cette information dans le bilan ? Qui est intéressé par cette information ?

·        Pourquoi cette information est à cet emplacement dans le bilan ? Plus l’information est accessible rapidement plus elle est importante et souhaitée par le plus grand nombre.

·        …

Mais ce n’est pas tout !

Il faut également se poser la question pourquoi dans les relations quotidiennes avec les autres membres du projet

·        Pourquoi convaincre de l’utilité de ces processus ?

·        Pourquoi le test est aussi important dans un projet ?

·        Pourquoi le testeur, membre du projet, souhaite comme tout membre que le projet soit une réussite ?

·        Pourquoi (et comment) lutter contre les préjugés ?

·        Pourquoi utiliser ces mots ? Une communication positive est souvent plus efficace qu’une communication négative qui porte le même message.

·        …

Bref, pour chaque action que l’on fait, chaque décision que l’on prend, il faut être capable de l’expliquer et de répondre à cette simple question « Pourquoi ? ».

En Scrum cela représente la partie « Afin de » dans les User Story : En tant que… Je veux que… Afin de…

Ce « Afin de », souvent négligé est particulièrement important il donne le but, la raison, le pourquoi cette fonctionnalité apporte quelque chose à l’application !

Conclusion :

On peut se poser la question: « Pourquoi cet article ? ». La raison principale est simple ! Pousser les testeurs à être curieux à se poser les bonnes questions et ne pas oublier que leur métier est un métier à part entière, non automatisable ! Le métier du testeur ce n’est pas que l’exécution des tests, c’est aussi beaucoup de réflexion !

N’oubliez jamais d’être curieux et de remettre en question ce que vous faites, de le challenger ! La curiosité et le pragmatisme sont 2 qualités fondamentales chez un testeur !