Lisiane est testeuse de système il y a presque deux ans et, pour exercer ses fonctions, elle utilise des méthodologies agiles. Aujourd’hui, elle partage avec nous sa vision professionnelle sur ce thème, à chaque fois plus discuté dans le domaine des TI.

 

« Que sont, en fait, les méthodologies agiles, quel motif justifie leur si grande utilisation et comment impactent-elles le secteur des tests logiciels ? »

Méthodologies agiles – Qu’est-ce ?

Bon nombre d’entre nous dans le domaine de la technologie d’information et, en particulier, ceux engagés dans les cycles de développement de logiciel, ont déjà travaillé avec les dénommées « méthodologies agiles ». Également connues sous le nom de « agile methodologies » ou, simplement, « agile », elles sont liées à la manière dont nous développons les logiciels. Quoiqu’aujourd’hui l’utilisation du terme soit généralisée, la motivation à la base de son existence est simple : faire ce que nous faisons de la meilleure manière possible. Le célèbre Manifeste pour le développement agile de logiciels présente alors quatre principes que je cite :

Les individus et leurs interactions plus que les processus et les outils ;

Des logiciels opérationnels plus qu’une documentation exhaustive ;

La collaboration avec les clients plus que la négociation contractuelle ;

L’adaptation au changement plus que le suivi d’un plan.

Cela ne veut pas dire que les autres points cessent d’être importants, mais l’accent, cependant, doit être mis sur l’efficacité de la production du logiciel et, à cet effet, l’interaction, la fonctionnalité, la collaboration et l’adaptabilité deviennent plus importantes, dans la mesure où elles facilitent les processus sans perte de qualité.

 

Taux élevé d’utilisation de méthodologies agiles – pourquoi ?

Bien que l’utilisation des méthodologies agiles soit devenue populaire, et se maintienne en pleine croissance, nous constatons que, lors des décennies précédentes, des actions ont été effectuées pour trouver les meilleures techniques de développement de logiciels. La grande question c’est qu’en pleine ère technologique, celle dans laquelle nous vivons, avec une vaste communication, nous avons valorisé l’efficacité et la rapidité du développement du logiciel avec une intensité croissante. Nous sommes en pleine ère du « click », soit, lorsque nous cliquons sur une touche nous achetons un produit ou nous contractons un service. De ce fait, survient également le besoin de développer un logiciel le plus rapidement possible. En revanche, de nombreuses entreprises utilisent le modèle dit « modèle en cascade » qui, avant que les méthodologies agiles soient devenues populaires, dictait les règles du cycle de développement du logiciel. Pour expliquer d’une forme simple, imaginons que le développement du modèle en cascade est semblable à un escalier sur lequel nous ne pouvons passer à la marche suivante qu’après avoir monté la précédente.  Quoique doté de nombreux avantages, justement en vertu de sa solidité et de sa grande richesse concernant les rubriques de spécifications, ce modèle finit par compliquer le flux des processus, ce qui fait que les personnes engagées ressentent d’extrêmes difficultés pour faire face à n’importe quel imprévu. En outre, le temps dispensé pour la phase de planification est très long, puisqu’il requiert une analyse exhaustive, prévoyant chaque étape du cycle. Si nous comparons le modèle actuel et l’ancien, nous saisissons la raison de la préférence pour les méthodologies agiles.

 

Comment les méthodologies agiles impactent-elles le domaine des tests logiciels ?

Les méthodologies agiles possèdent des outils et des principes utiles dans n’importe quel secteur, du marketing aux ressources humaines, voire au design, car elles s’adaptent aux particularités de chaque secteur, et il est toujours possible d’innover et de rendre les processus plus efficaces. Par conséquent, il est normal que, dans de nombreux cas, le domaine de tests logiciels soit également affecté, encore plus tenant compte de sa relation étroite avec le cycle de développement du logiciel, l’emploi du terme « tests agiles » lié au propre cycle n’étant pas rare. S’agissant d’une nouvelle façon d’agir dans les processus de développement, il est également naturel qu’il y ait des variations dans la manière de mettre en œuvre les tests agiles, qui varieront en fonction de l’organisation des domaines, des projets et des équipes au sein d’une entreprise.

 

En pratique, comment sont les tests agiles ?

Partageant un peu de ma propre expérience, je peux exemplifier un type de mise en œuvre. D’abord, imaginons une entreprise traditionnelle, même si elle adopte des méthodologies agiles. Suivant le flux de travail normal, une réunion est organisée pour définir ce qui sera développé, quelles sont ses exigences et comment les tâches seront fragmentées. Les programmeurs développeront leurs responsabilités séparément et, dans de nombreux cas, ce qui a été développé est un fragment à peine perceptible au niveau du code. Après le développement de toutes les tâches, et avec le produit final prêt pour la livraison, les testeurs pourront alors commencer la validation de ce qui a été développé. Après le test, le produit est livré au client et le processus se répète avec un nouveau produit.

Supposons néanmoins que le testeur rencontre un problème avec le produit : il y a un bouton, qui doit exister, mais il n’a été ni spécifié ni développé. Dans ce flux, il n’y a plus de temps pour parler avec le client, ni avec l’analyste, pour spécifier, développer et tester à nouveau. Même avec une méthodologie agile, le processus s’empêtre à cause des restrictions imposées et des divisions créées dans le travail de chacune des parties engagées. À vrai dire, dans la plupart des cas, ce flux fonctionne bien et des problèmes comme celui-ci peuvent être facilement résolus avec le client, engageant l’équipe à fournir la fonctionnalité dans le produit suivant. Toutefois, en partant du principe que l’on peut toujours mieux faire et offrir une plus grande efficacité, imaginons la mise en œuvre de tests agiles dans ce processus.

En comparant avec le processus décrit ci-dessus, imaginons qu’au lieu d’attendre le produit final pour commencer les tests, le testeur puisse simplement faire la vérification immédiate de la tâche effectuée par le programmeur, pratiquement en temps réel. De cette façon, la tâche du programmeur ne reçoit pas le statut « terminé » tant qu’elle n’est pas également validée par le testeur. Ainsi, une fois toutes les tâches terminées et le produit prêt pour la livraison, une nouvelle phase de test commence, dans laquelle les tâches ont été validées préalablement, seul un testage d’intégration final restant à faire.

Revenons à la situation dans laquelle un bouton important pour le fonctionnement du produit n’a pas été inclus dans le développement. En identifiant le problème, le testeur peut rapidement initier un dialogue avec l’analyste et les programmeurs, inclure la tâche dans le flux de développement et, si nécessaire, réajuster les priorités, résolvant le problème. Dans cette forme de travail, les parties engagées n’agissent pas individuellement, mais ensemble. Le testeur est toujours au courant des détails des exigences, fournis par l’analyste et, à son tour, le programmeur sait ce qui a déjà été validé par le testeur, et de cette manière, la communication avec le client est transparente.

Ainsi en gardant à l’esprit les principes qui guident les processus agiles, l’accent étant mis sur les interactions des parties engagées, nous livrons un produit fonctionnel et de qualité, avec l’accord du client et, tout cela, avec une grande adaptabilité aux imprévus intrinsèques au processus de développement du logiciel.

 

Qu’en concluons-nous ?

Il y a des cas où la mise en œuvre des tests agiles est très positive et, grâce à mon expérience professionnelle, je peux facilement identifier quelques points positifs et négatifs :

Négatifs :

– normalement, il faut un environnement approprié aux tests, ce qui exige du temps exclusivement pour la maintenance de cet environnement ;

– des testeurs dotés d’une connaissance plus approfondie de la programmation sont requis, étant donné que le testage est effectué, fréquemment, au niveau du code ;

– un haut niveau d’intégration est requis entre analystes, programmateurs, testeurs et toutes les autres parties engagées dans ce projet, y compris le client lui-même, et selon la dimension équipe/projet, ceci n’est pas toujours facile à obtenir.

Positifs :

– mis en œuvre correctement, un test agile confère une qualité plus élevée au produit fourni ;

– l’information circule d’une façon plus transversale entre les parties engagées dans ce projet ce qui réduit le nombre d’équivoques par manque de communication ;

– le nombre de bogues ouverts est considérablement moindre puisqu’ils sont déclarés et résolus encore en phase de développement ;

– les connaissances du testeur lui-même sont augmentées au niveau technique puisqu’il devra avoir accès aux projets.

Subséquemment, nous constatons que concernant les méthodologies agiles, ou tests agiles, il n’y a pas de modèle magique qui résoudra tous les problèmes, et ceci est un fait ! Mais, comme nous le savons bien, chaque projet est unique et possède ses caractéristiques et particularités.  Le plus important, lorsque nous parlons de méthodologies agiles, c’est de ne pas suivre chaque pas ou principe « à la lettre », mais si rechercher l’amélioration continue de nos processus de travail. « Rien ne va si mal qui ne puisse être mis en marche et rien ne va si bien qui ne puisse être amélioré. »

 

Lisiane Engel

Testeuse de systèmes – PrimeIT