Tests logiciels : 3 conseils pour mener à bien un projet informatique

Lors de l’explosion du client serveur dans les années 90 les entreprises n’avaient pas encore des équipes projets dédiées, voire des rôles identifiés. Fort des années d’expérience et avec le recul nous le savons tous : il est impossible de mener à bien un projet informatique sans appliquer une méthode de conduite de projet, qu’elle soit issue d’une méthode connue ou le résultat de l’expérience acquise.

Dans les années 90 nous étions plus dans les méthodologies de type MERISE ou RAD (Rapid-Application Development : aboutissant au premier postulat Agile ;-) ). Le contexte était bien différent. Pour caricaturer : les développements étaient réalisés en “mode forfait”. Le développeur tapait du code le matin et l’après-midi il effectuait les tests. Ces méthodes étaient en partie responsable de l’échec de plus de 70% des projets informatiques.

Avec l’évolution des organisations et des méthodes de développement, les projets informatiques ont vu arriver des équipes dédiées aux tests trop souvent externes au projet informatique concerné, pour pallier au manque de qualité des livrables. Le revers de la médaille : ces équipes de test sont « mutualisées » et doivent donc intervenir sur plusieurs projets sans être partie prenante du projet. Inéluctablement la connaissance de la partie métier, l’implication et la concentration nécessaire sont diluées. Il n’y avait pas d’expert sur la connaissance profonde du “pourquoi” ? A quoi vont servir les besoins exprimés ? Quels sont les objectifs fixés ? C’était du test « technique ou mécanique » : on se contente de vérifier que les résultats attendus correspondent à l’expression du besoin, mais sans implication réel dans un contexte global.

Lorsque l’on mettait à disposition une partie du projet en test, l’équipe de test devait déjà passer un temps considérable pour comprendre comment tester le développement. Aujourd’hui, impérativement, avant même d’écrire une ligne de code au regard d’une expression de besoin il faut être capable d’imaginer ou de se projeter sur le : comment va-t-on faire pour tester ? 

Arrivée de la méthodologie AGILE

La méthodologie AGILE a fait une entrée en force en bousculant tous les codes de la méthodologie MERISE, qui consiste à réadapter les objectifs du projet au fur et à mesure de l’avancement, en restant dans le délai et le temps initialement prévu.

Comme l’a dit Charles Darwin : « Ce n’est pas l’espèce la plus forte qui survit. Ni la plus intelligente. Mais celle la plus réactive au changement. »

Et cet adage s’applique parfaitement aux projets informatiques. Les “informaticiens” ne sont plus les seuls concernés par les projets de développement. Désormais on intègre le product owner, le chef de projet, l’architecte, le(s) développeur(s) et dans certaines organisations on y inclut enfin le QA. On crée des équipes réduites incluant les testeurs. 

Et il y a une énorme différence entre intervenir parallèlement sur plusieurs projets dissociés des équipes techniques ou bien inclus dans l’équipe projet. La bonne réussite d’un projet c’est une communication, constante, fluide et claire.

La réussite d’un projet passe impérativement par, à minima :

1. La communication : pour fluidifier la communication il faut la structurer. Des réunions régulières permettent de faire un point sur les projets. Attention tout de même à ne pas tomber dans la procrastination. Une réunion doit être constructive et cela passe par commencer et terminer à l’heure ! 19%* des raisons d’échec d’un projet.
2. Organiser et prévoir le plan de tests conjointement avec les équipes de développement. 28%* des raisons d’échec d’un projet.
3. Avoir une vision au fil de l’eau du projet. En méthodologie AGILE il y a une multitude de variables tout au long de la phase de vie du projet. Comme le QA est au cœur du projet, il au fait de ce qu’il se passe et il est capable d’adapter le plan de tests en fonction de la stratégie de test. Dans 40%* des cas d’échecs le projet n’a pas su absorber un changement de périmètre.

Cela permet d’avoir une symbiose entre les développements qui sont réalisés et le plan de test élaboré. Suivant l’approche, les tests pourront être implantés de façon beaucoup plus pertinente. La méthodologie AGILE implique une évolution du périmètre du développement au fur et à mesure des SPRINT (Un sprint est une courte période de temps de durée fixe durant laquelle vont s’enchaîner un certain nombre d’activités pour se terminer par la livraison d’un incrément de produit qui fonctionne).

Pour conclure.

Les rapports et études approfondies sur le monde des tests ne font pas légion. Le dernier rapport fiable date de 2011. Ce dernier démontre que les entreprises qui réussissent la majorité de leurs projets détectent les problèmes précocement. Cette association est toute aussi présente pour les projets stratégiques que pour l’ensemble du portefeuille de projets. Et pour détecter les problèmes le plus tôt possible il faut des équipes dédiées et une organisation des plans de tests méthodique. On ne pourra que vous conseiller de mettre à disposition de votre projet une équipe de projet dédiée du début à la fin et qui travaillera selon la méthodologie AGILE en y intégrant les interlocuteurs qualité. C’est le gage, à minima, de donner toutes les chances de réussite à votre projet.

Étude : Lien vers le rapport