Influence des méthodologies de développement sur la pratique du test

Cycle en « V », méthodes « agiles », quel impact sur la méthodologie de test ?

La question est parfois posée de savoir si la méthodologie de test est impactée par le choix d’une méthode de développement.

Sur le fond, la réponse est clairement négative : quelle que soit la méthode retenue pour organiser le projet de développement, dès lors qu’un niveau de qualité est requis pour autoriser la mise en service d’une application, il faudra toujours être en mesure d’affirmer le niveau de qualité requis et de justifier le niveau de qualité atteint pour décider d’une mise en service à risque maîtrisé.

  • affirmer le niveau de qualité requis nécessite une stratégie de test destinée à définir le périmètre à tester, les différents types de tests à mener, la priorité des tests en fonction du risque apprécié sous le double éclairage des exigences fonctionnelles et non-fonctionnelles,
  • Justifier le niveau de qualité atteint impose de produire la preuve du résultat de l’exécution de tests formalisés dans un plan cohérent et conforme aux termes de la stratégie de test.

En revanche, la méthodologie retenue pour le développement peut avoir un impact non négligeable sur les conditions de mise en œuvre des tests, en matière d’organisation des opérations et des équipes, de compétences requises, de recours aux outils spécifiques du test et de plate-forme technique.

Ainsi, des projets menés selon une approche de « cycle en V » s’accommodent bien d’une organisation fortement structurée en phases de test successives, fournissant les preuves les plus détaillées de la qualité atteinte.

A l’opposé, le recours à des méthodes dites « agiles » imposera des choix différents où la compétence et la réactivité des équipes, ainsi que la richesse, la disponibilité et la robustesse des environnements de test devront garantir le même niveau de qualité, tout en affranchissant le processus des lourdeurs d’une organisation plus figée et des contraintes d’exhaustivité détaillée des livrables matérialisant l’activité.

Cycle en « V »: des projets lourds, coûteux et peu ouverts au changement

Formalisés dans les années 1980, les projets organisés selon un « cycle en V » donnent la priorité à la rigueur de la structure, au respect des délais, au formalisme et à la complétude d’une documentation détaillée de toutes les activités. Ils nécessitent une organisation forte sinon lourde. La mise en place et le suivi du projet absorbent un effort important en contrôle et révision des plannings, des budgets, des affectations, etc.

Cycle en "V"

Ces projets se caractérisent par trois grandes phases : la réflexion, la réalisation et le contrôle.

  • la phase de réflexion vise à tout concevoir et préparer de façon minutieuse, avant le début du codage. Cette phase inclut bien évidemment l’expression des besoins et exigences et les différents niveaux de conception. Elle inclut aussi les étapes de préparation des différentes phases de test, en particulier l’élaboration des plans de test,
  • la phase de réalisation comprend le codage des composants à réaliser,
  • la phase de contrôle organise l’exécution des tests dans un ordre précis.

Une telle rigueur dans l’organisation vise l’absence d’écarts entre le besoin exprimé, la conception qui en est tirée et le logiciel réalisé, ainsi qu’une traçabilité détaillée et complète, au travers de livrables fortement documentés.

Outre l’importance de l’effort consacré à l’organisation et à la documentation, les principaux reproches adressés à ces projets sont l’effet tunnel et l’inaptitude au changement.

L’effet tunnel se traduit par l’absence de sollicitation des équipes métier entre la fin de l’étape d’expression des besoins et le début des tests d’acceptation, en fin de projet. Entre ces deux repères, la durée peut être très longue, en particulier pour les projets importants. De ce fait :

  • la détection d’écarts dus aux imperfections de l’expression du besoin sera tardive et pourra conduire à des demandes de changement aussi tardives qu’impératives, donc coûteuses et génératrices de désorganisation du projet,
  • le retour tardif des équipes métier pour les tests de fin de projet se fera souvent au prix d’une phase de réappropriation parfois longue et potentiellement accompagnée d’erreurs de compréhension, pouvant avoir un impact négatif sur la qualité des tests effectués et sur l’organisation de leur déroulement.

De plus, toute demande de changement en cours de projet peut imposer de remonter aux phases de conception pour en vérifier la faisabilité et l’impact sur le reste de l’application, ainsi que modifier les documents concernés avant d’autoriser le codage du changement demandé. Plus la demande sera tardive dans le projet, plus le changement sera coûteux et imposera des arbitrages parfois douloureux.

Plus récemment, le recours au découpage des projets en lots réduit l’importance de l’effet tunnel et augmente un peu la capacité à prendre en compte les changements en cours de projet, mais c’est au prix d’un alourdissement de l’organisation du projet et des charges afférentes.

L’approche « Agile »

Initiées dans les années 1930-1940, les recherches d’efficacité de la production par des méthodes itératives et incrémentales ont été appliquées à des projets informatiques dès la fin des années 1950. La forte expansion de l’informatique d’entreprise a conduit, dès la fin des années 1980, à l’émergence de méthodes de développement basées sur les mêmes principes (Spirale, RAD, RAD2, DSDM, Scrum, FDD, XP, etc.).

Au début des années 2000, le « manifeste Agile » fédère ces tendances autour de quatre principes directeurs, énoncés sous forme de préférences.

Il prend toutefois soin de préciser que, si la valeur des seconds termes n’est pas à mettre en doute, les premiers seront privilégiés.

L'approche agile

Lancée au milieu des années 1990, la méthode SCRUM, propose une approche à trois niveaux, pour une livraison progressive d’un périmètre applicatif croissant, par itérations successives :

  • un niveau global définit le macro-planning, l’analyse générale des attentes (« backlog ») ainsi que les itérations à prévoir,
  • un niveau « itération », disposant en propre d’un « backlog » et d’un planning, vise à livrer une version finalisée de l’application et définit les séquences successives de mise en œuvre appelées « sprint ». Chaque sprint se conclut par une livraison partielle et opérationnelle de la version en cours,
  • un niveau local (le sprint), destiné à la mise en œuvre d’une fonctionnalité précise, intègre les activités d’analyse, de conception, de réalisation et de test.
La méthode SCRUM
La méthode SCRUM

Influence des approches « agiles » sur l’activité de test

Mettre en œuvre une méthodologie « agile » de développement, c’est prendre un engagement fort de livraisons rapides et fréquentes de versions successives de l’application, opérationnelles et a minima exemptes d’anomalies critiques. En contrepartie, le périmètre des livraisons est beaucoup plus restreint que dans les autres types de projet, notamment pour les sprints qui se terminent par la livraison d’une partie du périmètre de l’itération. En outre, l’agilité impose la prise en compte des changements demandés en cours de sprint.

Concernant la livraison des versions, partielles ou complètes, l’adoption de méthodes agiles est souvent soutenue par la mise en œuvre du mécanisme d’intégration continue qui vise à garantir que toute modification du code n’entraîne aucune régression, aussi bien au niveau du sprint qu’à celui de l’itération.

La pratique du test revêt plusieurs aspects caractéristiques :

  • le test intervient dès la phase de codage, par la mise en œuvre du « développement piloté par les tests » (Testdriven development – TDD). Le principe de cette méthode consiste à écrire les tests unitaires avant le code et à fabriquer (« usiner ») le code de telle sorte qu’il satisfasse les résultats attendus des tests. Par ce moyen, on renforce « à la source » la qualité du code produit,
  • une place importante est faite aux tests exploratoires, approche intuitive qui consiste à rechercher des anomalies en se plaçant comme utilisateur de l’application et sans se baser sur des scénarios de test prédéfinis. Cette pratique, complémentaire à celle des tests « scénarisés », exige du testeur à la fois la compétence dans le métier concerné et une créativité certaine pour se placer dans un maximum de situations possibles pour détecter rapidement les anomalies les plus évidentes d’un point de vue métier,
  • le poids important des tests de non-régression, du fait de l’intégration continue, impose à la fois la gestion au long cours de plans de tests « scénarisés », portant sur l’ensemble du projet et un recours massif à l’automatisation.

En matière d’organisation :

  • chaque sprint doit disposer de testeurs dédiés, participant aux étapes d’analyse et de design afin d’être en mesure d’élaborer la stratégie de test et le plan de test du sprint, mais aussi d’apporter la valeur ajoutée de leur expérience, notamment pour enrichir et sécuriser l’étape d’analyse des besoins,
  • le sprint étant lui-même un processus itératif, les différents composants du test (stratégie, cas, scénarios, résultats) doivent pouvoir être enrichis à chaque itération interne au sprint.
    Cette aptitude facilite la prise en compte des changements décidés en cours de sprint,
  • disposer en outre d’une équipe de test au niveau « itération », permettra de consolider stratégies, plans de test et résultats des différents sprints, de concevoir les tests spécifiques à la version et de les exécuter avant livraison, mais aussi de préparer le plan de test de non régression de la version suivante.

Au chapitre des compétences, une division du travail trop prononcée est un handicap : les testeurs « agiles » doivent au contraire être polyvalents afin d’assurer, sur le périmètre restreint du sprint, un large éventail de tâches allant de l’analyse des besoins et exigences, au codage de séquences automatisées en passant par le test exploratoire et la formalisation des tests « scénarisés » (cas et scénarios). Tester « agile » nécessite donc des profils rares car multi-compétents et expérimentés aussi bien dans l’approche « contrôle qualité » que dans la maîtrise des méthodes d’analyse et des outils de codage. Selon l’importance du sprint, on pourra envisager des équipes de deux ou trois testeurs se répartissant ces compétences. Dans cette optique, le but est que chaque testeur acquière, au fil des projets successifs, les compétences qui lui font défaut, afin de devenir progressivement multi-compétent.

La plateforme technique constitue un point crucial de la réussite des projets « agiles ». Outre les composantes et outils propres à l’intégration continue, elle devra comporter plusieurs environnements dédiés au développement et aux différents tests (intégration, validation et acceptation). Certains d’entre eux devront figurer l’environnement de production. De plus, elle devra porter des outils tels que le « framework » de développement piloté par les tests, la gestion de tests manuels, d’anomalies, les automates de test, ceux de génération de données de test, etc.

Par dessus tout, respecter un paradigme « agile » conduira nécessairement à construire progressivement un cadre opérationnel adapté, intégrant, autour d’une plate forme fortement outillée, des pratiques, des compétences, une organisation et un état d’esprit aptes à favoriser une réponse rapide à la demande des métiers, sans sacrifier pour autant la qualité du résultat.

Loin de produire une norme avec ses contraintes et ses lourdeurs, cette construction par l’expérience vise à l’émergence d’une culture, englobant les pratiques d’analyse, de design, de codage, de test et de l’intégration continue.