Dans mes articles j’ai parlé de beaucoup d’aspects du test comme l’automatisation, des particularités du Scrum, des bonnes pratiques plus récemment d’intégration et de déploiement continu…
Tout cela est très bien, malheureusement pas toujours adapté au contexte (ce qui a souvent été remonté dans les commentaires) et dans le test comme partout il faut savoir s’adapter au contexte.
A quoi bon avoir des tests de régression alors que le projet sur lequel on va travailler ne durera qu’un mois et qu’il ne sera pas maintenu (par exemple : une application offline pour mobile) ?
Comment mettre en place des processus complexe pour assurer une excellente qualité alors que le budget des tests est proche de 0 car la qualité souhaitée pour l’application est faible?
Comme je l’ai déjà écrit de nombreuses fois, être pragmatique est une des principales qualités d’un bon testeur, cela commence par savoir s’adapter à chaque contexte. Ce contexte dépend de nombreux facteurs, en voici quelques-uns :
· L’existant : l’équipe déjà en place, les outils déjà utilisés.
· La faculté de livraison : Toutes les 30 minutes ? Tous les 3 mois ?
· La qualité souhaitée – le budget alloué aux tests : plus de l’argent est alloué aux tests plus il est aisé d’améliorer l’efficacité des campagnes de test.
· La durée de vie du projet : certaines décisions ont des bons retours sur investissement uniquement à moyen ou à long terme.
· Le mode de développement du projet : une méthode incrémentale (ex : Scrum) ou cycle en V
Une stratégie de test ne sera efficace que si l’on prend en compte ces facteurs.
Exemple : implémenter l’automatisation
· L’existant : Si l’équipe de test n’est pas technique alors il faut penser au KDT si on veut vraiment automatiser. Automatiser c’est souvent former et investir dans des outils.
· La faculté de livraison : si la faculté de livraison est élevée avec des livraisons possible tous les jours l’automatisation devient quasiment nécessaire car les tests sont amenés à être exécutés très souvent, par contre si on ne peut livrer une version que tous les 3 mois l’automatisation devient moins prioritaire.
· La qualité souhaitée – le budget : Si on travaille sur un projet où la fiabilité est très importante (ex : application embarquée sur un satellite) alors l’automatisation permet de multiplier les exécutions et d’être sûr qu’il n’y aura pas de différence entre les différentes campagnes à part les modifications du code (et de l’environnement). Dans le cas où le budget est faible l’automatisation n’est peut-être pas intéressante car son implémentation est coûteuse (écriture coûteuse, maintien coûteux, potentiellement implémentation de nouveaux outils et formations des membres du projet)
· La durée de vie du projet : Un projet de 3-4 mois n’est pas un candidat idéal à l’automatisation (même si cela n’est pas éliminatoire), en effet le retour sur investissement ne sera pas forcément assuré car l’implémentation de l’automatisation peut prendre la moitié du temps total du projet. Par contre sur un projet d’un an ou plus l’automatisation devient beaucoup plus pertinente.
· Le mode de développement du projet : L’automatisation est une question de plus en plus insistante depuis le développement des méthodes incrémentales comme la méthode Scrum. La raison est simple, la multiplication des exécutions des tests car le produit s’enrichit régulièrement. L’automatisation est donc vivement recommandée en Scrum (et obligatoire pour du déploiement). Par contre pour tout projet en cycle en V il est moins intéressant d’automatiser car le nombre d’exécution sera moindre.
Exemple 1: Application de lancer de dés sur android :
· Existant : 2 développeurs JAVA => petite équipe, compétences techniques suffisantes mais demande un gros investissement
· Faculté de livraison : 1 fois toutes les 2 semaines => la livraison peut être régulière mais pas intensive
· Qualité souhaitée : qualité moyenne, l’important c’est de ne pas avoir de bugs critiques => l’automatisation peut être pertinente dans le cadre des tests vitaux
· Durée de vie du projet : 1 mois => l’automatisation n’est pas pertinente par rapport à ce critère
· Mode du développement du projet : Cycle en V
Dans ce cas l’automatisation n’est pas pertinente à mettre en place.
Exemple 2 : site web d’un quotidien national
· Existant : une équipe de 6 développeurs, Sélénium est disponible => équipe de taille moyenne avec les compétences techniques, un outil pertinent déjà en place, l’automatisation est donc intéressante d’après ce critère
· Faculté de livraison : déploiement continu souhaité, pour en arriver là l’automatisation est quasiment obligatoire
· Qualité souhaitée : qualité moyenne, l’important c’est de pouvoir lire les articles, l’automatisation peut être envisagée
· Durée de vie du projet : plusieurs années (pas de fin prévu), le retour sur investissement de l’automatisation peut être très important
· Mode de développement du projet : Kanban, méthode incrémentale l’automatisation est recommandée
Dans cet exemple l’automatisation semble obligatoire.
La question ne se pose pas uniquement pour l’automatisation mais bien pour tout processus (comme la mise en place d’un suivi des tests, de la mise en place de différentes campagnes de tests, ou d’indicateurs d’efficacité des campagnes).
Attention certaines pratiques sont, de mon point de vue, toujours bonnes à mettre en place, tout simplement car le retour sur investissement est quasiment immédiat. Je pense par exemple aux tests statiques, aux plans de test, une bonne gestion des bugs ou des tests exploratoires…
Conclusion :
Il est impossible d’arriver dans une équipe avec une solution clé en main qui fonctionne tout le temps. Lorsque l’on arrive dans une équipe il faut d’abord connaitre les besoins de l’équipe et du projet, si on ne passe pas par cette phase on fera face à des conflits pour au final, arriver à une solution par forcément optimale.
Articles sur le Scrum : Le testeur dans la méthode Scrum, Les défis du Scrum, Implémenter US
Articles sur l’automatisation : Tests autos vs Tests Manuels, KDT, Automatiser?
Bonnes pratiques : L’écriture des cas de test, Test Plan, Tests statiques, La visibilité des tests
Déploiement continu : Déploiement continu
