La journée type du testeur

On me pose régulièrement la question : « Qu’est-ce qu’une journée type pour un testeur? ». Pour être honnête le terme « testeur » est trop complexe et regroupe trop de métier pour que l’on ait cette « journée type »… Et j’ai envie de dire Heureusement, car sinon, ce métier serait vraiment monotone !

Pour rappel j’ai déjà parlé du métier de testeur dans mon premier article, abordé les différents métiers du test et vous propose des interviews afin de mieux comprendre la diversité de ces métiers.

Je vais tout de même tenter, dans cet article, de vous présenter des journées types pour les testeurs, en fonction de la méthode de développement (Cycle V et Agile), et de l’étape du projet pour le cycle en V.

Cycle en V

On peut découper un cycle en V en 3 phases pour les testeurs. Ces phases sont :

• La préparation de la campagne
• La campagne
• L’après campagne

Chacune de ces phases va correspondre à une ou plusieurs activités spécifiques qui vont rythmés les journées des testeurs et donc proposer des journées types.

La journée type de la préparation d’une campagne peut être vue comme cela :

• Travailler sur le plan de test (10-15%)

Cette partie est probablement la plus importante. On y identifie les risques, le périmètre les méthodes de conception… On se synchronise également avec l’ensemble de l’équipe projet. Pour plus d’informations je vous invite à lire cet article.

L’essentiel du temps passer sur ce plan de test est passé au tout début du projet. Le plan de test étant un document vivant, l’équipe peut régulièrement revenir dessus.

• Concevoir les tests en fonction du plan de test (et donc des risques définis) (20-25%)

Dans cette partie on définit, en fonction de la stratégie adoptée, quels seront les tests à exécuter. Le testeur va donc utiliser des techniques de conception de test (plus d’informations dans les articles de Benjamin Butel) qui peuvent être définies dans le plan de test, orienter l’effort de test en fonction des risques identifiés et définir leur ordre d’exécution.

Dans cette partie on peut également sélectionner les cas de tests de régressions qui seront exécutés pour la campagne.

• Ecrire les cas de test (40-60%)

La partie la moins intéressante d’un point de vue intellectuelle mais aussi une partie essentielle où la rigueur est particulièrement importante. Après avoir conçu les tests il faut les écrire… Et bien les écrire afin qu’ils soient fiables, compréhensibles ne laissant pas de place à l’interprétation.

Cette partie peut régulièrement prendre la moitié du temps de préparation.

• Préparer les environnements de tests, les données… (10-15%)

Cette dernière partie est très importante et permet de commencer la campagne dans de bonnes conditions. En effet, il faut s’assurer avant le début de la campagne que les environnements seront disponibles. Qu’ils auront les données souhaitées afin que nos tests soient valides.

Il faut également mettre les tests à exécuter dans des campagnes afin de pouvoir aisément faire des bilans. Vous pouvez remarquer ici que je dis « des bilans ». Ce pluriel est voulu, particulièrement en Cycle en V où les campagnes peuvent durer plusieurs semaines. De mon point de vue c’est une faute professionnelle de ne pas informer régulièrement l’équipe projet de l’avancement des tests, de la couverture des risques et fonctionnalités. Cette information régulière permet de ne pas avoir d’effet tunnel mais aussi de pouvoir adapter sa stratégie en fonction des événements !

La journée type de campagne peut être vue comme cela :

• Exécution des cas de test (50-60%)

Dans l’ordre prévu en amont.

• Analyse des cas de test en échec (15-20%)

Un cas en échec n’est pas forcément dû à une anomalie ! Et même si c’est le cas, afin de résoudre l’anomalie il faut bien la documenter, la connaitre, trouver sa cause racine, le moyen de la reproduire, définir sa priorité et sa criticité…

• Suivi des anomalies (25-30%)

Le suivi des anomalies signifie :

L’ouverture de la fiche d’anomalie suite à une analyse d’un cas en échec lorsque c’est nécessaire.

Le renseignement de ces dernières afin de faciliter le travail des personnes qui devront l’investiguer.

L’affectation et les échanges nécessaires avec la ou les personnes à qui seront affectée l’anomalie

La phase de retest

S’assurer du bon suivi du « workflow » des anomalies.

La journée type de l’après-campagne peut être vue comme cela :

• La phase de rétrospective ou de post mortem afin de faire un bilan sur le projet test dans sa globalité

Dans cette phase, la pertinence du plan de test est évaluée. Un retour sur les problèmes rencontrés est fait et des actions sont prises afin d’améliorer les processus ou tout ce qui peut l’être.

• Un suivi de l’application en production est effectué.

Afin de s’assurer que certains risques n’ont pas été oubliés ou sous-estimés.

• L’archivage des tests qui ne seront plus exécutés

Les tests de validation qui ne seront plus exécutés doivent être conservés et archivés. Cette action est faite à la fin de la campagne.

• La mise à jour des campagnes de régression et de tests vitaux

Cette mise à jour peut être faite avec l’ajout de nouveaux test à automatiser mais aussi avec de la modification de données ou la suppression de certains tests afin de lutter contre le paradoxe des pesticides mais aussi d’optimiser ces campagnes.

L’agilité

La journée d’un testeur agile est à la fois plus simple et plus complexe à expliciter. Si on veut la résumer on peut dire que la journée type d’un testeur agile c’est un peu toutes les journée types du cycle en V (+ les activités liées à l’agilité) en partant du fait qu’une US serait à elle seule un projet « cycle en V » et que le testeur serait affecté à de nombreux projets (US) en même temps.

Une journée type en agile, si elle existe, sera beaucoup plus fragmentée en agilité qu’en cycle en V. De même elle dépendra beaucoup de la composition de l’équipe agile, des compétences de ses membres.

Je serai d’ailleur plus tenter de parler de « semaine type » tant les tâches à couvrir par le  testeur agile sont nombreuses et variées… Ces tâches ne peuvent que très rarement être toutes accomplies dans la même journée… mais qu’il pourra néanmoins couvrir régulièrement toutes (ou une partie) de ces activités.

Essayons néanmoins de définir la journée type d’un testeur agile en parlant de ses activités type :

• Assister aux cérémonies de l’équipe (15-20%)

Ces cérémonies servent à échanger et se synchroniser avec l’équipe. Elles permettent également de faire des rétrospectives afin d’améliorer les processus… Et d’estimer une charge de travail.

• Assurer une mise en place et un suivi de processus de test (20% au début du projet puis diminue à 5%)

C’est un vrai plus qu’apporte le testeur dans une équipe agile. C’est d’ailleurs en grande partie pour cela (et la stratégie de test à travers les plans de test) que les équipes agiles ont besoin de testeur. Car, soyons franc, exécuter des tests tout le monde sait faire. Néanmoins, pour exécuter les bons tests, optimiser l’effort consenti afin d’obtenir la qualité souhaitée un testeur est nécessaire… Et pour cela rien ne vaut la mise en place d’un processus adapté à l’équipe

• Mettre en place les plans de test (5%)

Un plan de test par User Story est une vraie bonne pratique… Et un apport important du testeur dans une équipe agile. Dans le cas où l’équipe n’accepte pas les plans de test, mettre en place une stratégie « tacite » ou de bons DoD est une action que le testeur agile peut prendre.

• Concevoir, écrire exécuter des tests et proposer des bilans. (25-35%)

La partie conception est la partie la moins « partagée » par le testeur, par partagée j’entends celle que les autres membres de l’équipe feront le moins. En effet l’écriture et l’exécution des tests, comme l’édition d’un bilan (si le bilan type est défini) peut être aisément fait par n’importe quel membre de l’équipe.

Enfin par écriture et exécution il faut évidemment penser manuel et automatisés… Les développeurs pouvant être de meilleurs automaticiens que le testeur.

• L’analyse des cas en échec et le suivi des anomalies. (5-10%)

Comme pour le cycle en V

• Faire ce pour quoi il est le plus utile à l’équipe. (x%)

Cela peut aller du développement à l’écriture de documentation ou de spécifications… Un testeur agile ne fait pas que du test !

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