Que faire lorsque l’équipe de test est un goulot d’étranglement?

Il arrive souvent que l’on dise dans les entreprises que les tests sont la cause du retard des projets. Je ne suis évidemment pas d’accord avec cela plus plusieurs raisons (détaillées dans différents articles), néanmoins il arrive que sur certains projets, le nombre de testeurs soit insuffisant par rapport au nombre de développeurs et aux tâches qui lui sont assignées.

Par exemple : Le temps nécessaires au testeur représente 50% du temps de développement, par contre il n’y a que 1 testeur pour 5 développeurs… le test devient donc, avec une vision totalement objective, un goulot d’étranglement.

Comment faire pour régler ce problème ?

Une solution évidente est le recrutement et l’augmentation le nombre de testeurs.

Cette solution a néanmoins certaines limites :

·        Il faut trouver les personnes à recruter ce qui peut prendre plusieurs mois (processus de recrutement, préavis…)

·        La montée en compétence sur le projet peut également prendre du temps

·        Cela coûte de l’argent supplémentaire, ce que le projet n’a pas forcément.

Conclusion : La solution du recrutement ne fonctionne pas si le projet est urgent ou s’il n’a pas non plus les fonds suffisants.

Quelle autre solution avons-nous ?

Pour cela il faut se pencher sur des pratiques agiles (ex : Scrum) et repenser le travail à effectuer par les testeurs.

En Scrum, chaque membre de l’équipe ne fait pas forcément ce pour quoi il est le meilleur mais ce pour quoi il est le plus utile. Un testeur peut aider pour les spécifications ou le développement si le besoin du projet à l’instant t est celui-là et qu’il a les connaissances pour le faire.

Il faut donc dépasser les clivages et les attributions usuelles des testeurs si l’on veut trouver une solution alternative, rapide à mettre en place et peu coûteuse.

Quelles sont les attributions habituelles des équipes de test :

·        Conception des tests

·        Mise en place de la stratégie et des processus de test

·        Exécution des tests

·        Rédaction des rapports de test

·        Automatisation des tests systèmes

·        Maintenance des cas de test

·        Gestion des bugs

·        …

Il faut alors se demander quelles sont les tâches où l’apport des testeurs est le plus important. Les voici :

·        La conception des tests

·        La mise en place de la stratégie et des processus

Viennent ensuite :

·        La rédaction des rapports de test (qui peuvent être automatisés

·        La gestion des bugs

·        La maintenance des cas de test

Enfin les tâches où le testeur à le moins de valeur ajoutée par rapport à un développeur sont :

·        L’exécution des tests (Si un cas de test est bien écrit, n’importe quelle personne du projet doit être capable d’exécuter un test)

·        L’automatisation des tests (c’est une tâche très proche du développement, un développeur peut même être plus efficace qu’un testeur)

Pour alléger la charge de travail de l’équipe de test on peut donc envisager de « délester » cette équipe des tâches où elle a le moins de valeur ajoutée, en commençant donc par l’automatisation et l’exécution des tests puis plus si nécessaire.

Il faut toujours garder à l’esprit que la vitesse de développement d’un projet est celle de l’équipe la moins rapide (et donc celle du goulot d’étranglement). Diminuer la vitesse de développement de l’équipe de Dev pour augmenter celle de l’équipe de test lorsque cette dernière ne peut supporter la charge de travail est bénéfique pour le projet.

Conclusion : Cette solution est plus rapide à mettre en place et moins coûteuse pour le projet. Néanmoins cela ralentit la « vitesse » de développement des développeurs qui peuvent se retrouver sur d’autres tâches. A moyen et long terme la solution de recrutement est donc plus efficace.

Néanmoins, cette solution de changement de répartition des tâches est régulièrement mise en œuvre sur les projets agiles (rarement sur des projets type Cycle en V). Les projets en mode agile ne sont pas pour autant à l’abri de telles problématiques. En effet, ce n’est pas parce que l’on se dit agile, que l’on fait des sprints et des daily meetings que la philosophie de cette agilité est présente au sein des projets.

Je tiens également à préciser que cette problématique est vraie dans les 2 sens. Si le goulot d’étranglement devient l’écriture des spécifications ou le développement de l’application les testeurs devront prendre une part de ces tâches afin d’aider sur le projet.

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

Publié par

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s