testing-agile-method

Comment concilier pratiques de tests et méthodes Agile lors du développement d’une solution Web Analytics ? Nos ingénieurs travaillent depuis plusieurs années sur des cycles de développement axés sur l’amélioration continue. Petite immersion dans les coulisses de la R&D d’AT Internet. 

 

Postulat : l’exigence de qualité  

En tant qu’éditeur de logiciels, nous souhaitons fournir à nos clients des produits qui vont apporter de la valeur à leur activité, et non des contraintes supplémentaires. C’est dans cette optique que nous travaillons depuis plusieurs années à l’amélioration de notre cycle de développement, de nos exigences en termes de qualité logicielle et à la manière de concilier bonnes pratiques de test et l’utilisation des méthodes Agile, tout en respectant l’objectif de nos clients : collecter et exploiter au mieux leurs données digital analytics. 

Avant d’investir dans des efforts de test, le premier besoin est de savoir quels objectifs nous souhaitons atteindre en faisant des tests et en quoi ils consistent. Nous pouvons alors définir une stratégie de test claire et partager un même niveau d’information entre nos différents collaborateurs.  

 

Objectif 1 : identifier des défauts  

Il est vrai que les tests logiciels servent le plus souvent à détecter la présence de bugs dans le produit. C’est l’objectif le plus connu et le plus évident lorsqu’on teste un logiciel.

tests-bugs-detection

source: Applied Software Measurement, Capers Jones, 1996

 

Nous constatons depuis longtemps que le coût de correction des anomalies explose après la mise en production alors que, comme le montre cette étude, 85% des défauts sont introduits pendant la phase d’implémentation. Pourquoi alors ne pas les corriger tout de suite, tant que cela est peu coûteux pour nous et transparent pour nos clients ? Nous investissons donc pour atteindre cet objectif de détection mais pas seulement !

 

Objectif 2 : gagner en confiance

Les tests logiciels nous servent parfois à simplement acquérir un certain niveau de confiance sur la qualité de nos produits. En effet, lorsqu’on couvre avec pertinence une fonctionnalité par des tests, sans trouver de défaut, cela nous rassure et procure plus de confiance sur la livraison à venir (attention toutefois au principe « d’illusion de l’absence de défauts »). Des tests de non régression en succès rassurent aussi grandement au moment de livrer des nouveautés ou des corrections.

 

Objectif 3 : fournir de l’information

Les tests de tous types nous fournissent également, et quels que soient leurs résultats, des infos précieuses sur nos produits. Par exemple :

  • Des indicateurs non fonctionnels comme l’évolution de la performance au fil des livraisons
  • Des listes de régressions ou anomalies identifiées (known issues)
  • La mise en évidence d’indicateurs sur notre dette technique

Autant d’informations qui nous permettent de prendre les bonnes décisions au bon moment. Les tests sont essentiels pour ne pas avancer à l’aveugle, et permettent de se tenir prêt à réagir le mieux possible en cas de souci avéré.

Notez aussi que certains tests peuvent nous permettre de prévenir l’apparition des défauts dans le produit, avant la production du code lui-même. C’est le cas des phases d’INVEST des stories ou des revues d’architecture, par exemple.

 

L’approche Agile des développements

agile-method-illustration

L’utilisation des méthodes Agile vise à livrer régulièrement des incréments pleinement fonctionnels de nos produits, en ciblant la valeur que nous apportons à nos clients. Ce rythme a de nombreux avantages, parmi lesquels :

  • la flexibilité
  • l’adaptation continue aux besoins de nos clients
  • la possibilité de recueillir un feedback régulier de nos utilisateurs
  • l’amélioration continue des pratiques de nos équipes

Mais cette approche ne va pas sans quelques contraintes dans une démarche de test logiciel :

  • Le coût en temps des activités de tests manuels est incompatible avec la cadence imposée : la durée limitée d’un sprint ne permet pas d’étaler une phase de recette sur plusieurs jours voire semaines, et encore moins d’externaliser les activités de test.
  • Découvrir les résultats de test en fin de sprint représenterait un trop fort risque quant à la livraison prévue, nous avons besoin d’une visibilité au plus tôt dans le sprint.
  • La succession de livraisons au fil des sprints apporte également une forte contrainte sur la nécessité d’être alerté sans effort supplémentaire en cas de régression introduite sur une livraison passée.

Nous devons alors adapter notre stratégie pour automatiser judicieusement ce qui peut l’être et investir nos efforts de test aux bons endroits.

 

Notre pyramide de test Agile

Penchons-nous maintenant sur la (célèbre) « pyramide de tests Agile » que nous avons adaptée à notre contexte. Nous cherchons à optimiser le rapport effort/gain de nos activités de test en structurant les différents niveaux de test. Nous souhaitons obtenir un feedback régulier et au plus tôt pour nos développeurs. Pour cela, nous avons choisi cette approche :

Pyramide-test-agile
  • Un maximum de tests automatisés dans les couches basses, rapides à exécuter et qui coûtent moins cher à mettre en place (tests unitaires).
  • Des couches de tests intermédiaires automatisés également pour valider l’assemblage des composants et les restitutions dans les interfaces (tests système / d’intégration de systèmes / de solution).
  • Conserver une partie manuelle de test qui visera simplement à valider la livraison de la fonctionnalité (concordance du livrable avec le besoin initialement exprimé).

 

En finir avec « l’effet de bord »

Je me souviens du temps où les tests étaient perçus comme ennuyeux et coûteux, où les équipes devaient tout arrêter après la mise en production d’une nouveauté pour se consacrer à la correction d’un souci majeur en production : le fameux « effet de bord » que tout le monde attend secrètement sans savoir où il va apparaitre… Ce temps a laissé place à l’intégration des activités de test comme partie intégrante des développements pour fiabiliser le produit mais aussi pour rassurer tout le monde : les mises en production peuvent alors être moins stressantes et plus régulières. Quelle satisfaction de voir alors les équipes détecter et corriger les régressions dans le produit avant les clients !

 

C’est dans cet esprit que nous souhaitons continuer à proposer des produits d’une grande fiabilité sur lesquels les analystes peuvent se reposer en toute confiance. Ce travail est un chantier de longue haleine et mérite un effort continu. Nous sommes d’ailleurs en recherche d’esprits rigoureux, soucieux de la satisfaction client et avec un goût prononcé pour l’automatisation de tests. Alors, si cet article vous parle, n’hésitez pas !

Auteur

Fort de plus de 10 ans d’expérience en stratégie et implémentation de tests logiciels en environnement Agile, Alexandre est en charge de l’industrialisation des développements chez AT Internet. Son challenge au quotidien : accompagner nos équipes de développement dans la mise en place d’outils et méthodes afin de garantir à nos clients des livraisons régulières et de qualité.

Comments are closed.