Comment tester une chaine d’applications ?

Il y a deux ans, on m’a proposé la mission suivante : réduire le temps d’intégration des composants d’une chaîne d’application à un mois, ce qui sous-entend disposer d’une capacité à tester efficacement l’ensemble de cette chaine. Je prends enfin le temps de vous parler de cette expérience, de l’organisation et outils des utilisés.

Une chaîne d’application, qu’est-ce que c’est ?

Une chaîne d’application permet de fournir un service, sous forme de fonctionnalités. Le design de ces fonctionnalités fait que les flux d’information doivent traverser plusieurs applications logicielles, généralement maintenues par des équipes différentes.

Pourquoi tester une chaîne d’applications ?

Dans cette mission, les différents équipes impliquées dans la chaîne d’applications disposaient toutes de tests automatisés, d’un bon niveau de maturité. Ces tests ne couvraient que les applications localement. Il n’y avait pas de tests de l’ensemble de la chaîne. Cela conduisait à différents comportements des équipes :

  • Une réticence à intégrer les dernières mises à jour des autres applications
  • Des anomalies inévitables dont la responsabilité n’incombait à personne et qui étaient générateurs de tensions entre les équipes.

Tester une chaîne d’applications est bien-sûr une nécessité. Cela n’est cependant pas simple à organiser (les personnes) et à construire (les outils).

Comment tester une chaîne d’application ?

Cadrage de la demande

Cette mission a débuté avec le cadrage de la demande :

  • Clarification de la demande
  • Identification des acteurs
  • Evaluation des moyens

La demande consistait à agir sur le nombre d’anomalies au niveau de la chaîne et permettre une intégration des composants de la chaîne avec un délai maximum d’un mois après leurs publications (il pouvait s’étaler jusqu’à trois ans dans certains cas).

Les acteurs de cette initiative :

  • Les responsables de chaque application
  • Le commanditaire (n+1 des responsables)
  • Une personne des opérations (expert des outils de déploiement)
  • Le coach
  • Le groupe des outils et méthodes

Les moyens ont été évalués en fonction du temps que chaque acteur pouvait consacrer au sujet ainsi qu’un budget pour faire évoluer les outils existants. De mon côté, j’ai demandé à ce que tous les acteurs forment un groupe de travail et se réussissent pendant 4 mois toutes les deux semaines. Ma contribution a principalement été de la facilitation sur cette mission.

Le kick-off de cette initiative a permis à ce que tous les acteurs en comprennent le sens : pourquoi tester une chaîne d’application était nécessaire, ce que cela permettait à chacun de gagner.

Suite au kick-off, les solutions ont rapidement émergées :

  • Un rapatriement automatique des applications connexes pour les tester localement avec chaque application.
  • L’enrichissement des jeux de tests d’une application basé sur les anomalies détectés via les autres applications.

L’intention était de détecter au plus tôt les différences liées à l’évolution d’une autre application afin d’accélérer l’adaptation des applications entres elles.   

Construction de la solution technique

Étant donné la consommation en cascade des flux d’information par les applications (la problématique aurait été bien plus complexe si chaque application avaient des dépendances avec toutes les autres), il a été possible de définir la stratégie de test suivante :

Soit les applications A, B, C et D appartenant à la même chaine d’application. A est une application front-end, tandis que B, C et D enrichissent successivement le flux d’information pour finalement le retourner à A.

Test de l’application D

D était dans notre cas une bibliothèque informatique, utilisée par cette chaine d’application mais aussi par de nombreuses autres applications de l’entreprise. Elle disposait d’une bonne couverture de tests unitaires mais aussi de tests de non régression, de charge et de performance. Il n’a pas semblé pertinent de créer de nouveaux types de test. Par contre,  un canal de remonté d’anomalie a été mis en place avec leurs jeux de test associés provenant de l’application C.

L’application D bénéficiait déjà d’un usine logicielle permettant de créer, tester et publier chaque jour une nouvelle version. Un aménagement a été fait pour que cette usine publie dans un espace partagé et informe les autres applications qu’une nouvelle version était disponible.

Test de l’application C

Pour l’application C, il a été proposé qu’elle testerait en continue les évolutions de l’application D afin de détecter des modifications d’interface entre C et D ainsi que des différences fonctionnelles, qu’elles soit souhaitées ou anormales.

Pour tester en continue l’application D, l’application C s’est « abonnée » à la publication des nouvelles versions de D produites chaque jour. Ainsi, dès qu’une nouvelle version de D était disponible, l’usine logicielle de C la récupérait, l’intégrait à l’environnement de test de C et la testait avec la dernière version officielle de C disponible (pas la version du jour de C pour éviter que la différence se cache dans C ou D).

Dans l’exemple ci-dessus, l’usine logicielle de l’application C utilise une copie de la version stable C.5.0 et la dernière version de développement de D disponible. Ainsi, les différences qui vont apparaitre ne seront que la conséquence d‘évolutions sur l’application D. A noter que le version de développement de C utilise quant à elle la dernière version stable de D.

La copie du code source de la version stable C.5.0 (une branche de développement créée dans le seul objectif de détecter les régressions liées aux évolutions de la dernière version de D) va évoluer au fur et à mesure des adaptations nécessaires à D, qu’il s’agisse de modification d’interfaces ou bien de modifications des données de test pour cette version spéciale de C. Toutes les modifications nécessaires pour recevoir les changements de D donnent lieu à des user stories pour l’intégration de la future version stable de D.

Il est à rappeler que l’équipe C travaille surtout sur la version en développement de C. Son objectif est de produire rapidement une nouvelle version stable (C+D). Elle surveille en parallèle l’évolution de D et le régression potentielle, via l’usine logicielle créée à cet effet.

L’usine logicielle de la version de développement de C, qui utilise une version stable de D, publie quotidiennement un package C+D (C.5.0.0.9 + D.2.0.0.0 par exemple). C’est cet ensemble qui sera utilisé par les autres applications de la chaine pour mener leur tests.

Test des applications B et A

Les applications B et A vont utiliser le même principe que C pour récupérer la dernière version de développement de l’application connexe. Ainsi, B va récupérer l’ensemble C+D (C dev + D stable) pour mener ses tests sur une branche spéciale de B, basé sur la dernière version stable de B. A va récupérer l’ensemble B+C+D (B dev + C stable + D stable) pour mener ses tests sur une branche spéciale de A, basé sur la dernière version stable de A

Les outils qui ont été utilisés dans cette expérience sont :

  • Jenkins, comme usine logicielle
  • Nexus, comme gestionnaire des composants issus des versions en développement de A, B, C et D

Deux stratégies de notifications ont été testées pour informer de la publication d’une nouvelle version disponible :

  • Flux RSS généré par l’application Nexus.
  • Signal généré par une usine logiciel pour en informer une autre

Même si les deux stratégies fonctionnent, la deuxième solution, plus simple à mettre en place, a été retenue.

Remontée des anomalies et constitution de nouveaux jeux de test

En complément de la stratégie de test de la chaine d’application, il a été proposé qu’une régression, provenant d’une autre application, devait donner lieu à la création de données de test. Ainsi, quand l’application C détecte une anomalie provenant de D, l’équipe en charge de C doit aider à concevoir des tests pour reproduire cette anomalie au niveau de D. L’équipe D pourra intégrer ces nouvelles données de tests avec un label associé à l’application C pour faciliter l’organisation des jeux de test.

Conclusion

Les équipes ont acquis la capacité de détecter quotidiennement une régression produite par une autre application de la chaine. Elles sont désormais bien plus à l’aise pour s’adapter aux nouvelles versions des autres applications.

Cette initiative aura permis de sensibiliser tous les acteurs à la stratégie de test et aux solutions à concevoir ensemble. Elle aura été source d’apprentissage pour les équipes travaillant sur les autres chaines d’application dans l’entreprise. Elle aura permis découvrir de nouvelles pratiques et de faire évoluer les outils pour rendre possible le rapatriement de package d’applications pour les tester localement. Cette stratégie n’est pas une alternative aux stratégies de test locales des applications. Elle les complète en ajoutant la détection de régressions provenant d’un écosystème applicatif dynamique.

photo credit: marcoverch Dominoschlange via photopin (license)

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s