SOA : l’alignement IT-métier passe aussi par la stratégie de test

Une architecture orientée services est par nature complexe à tester. Afin de bien gérer les risques, la répartition de l'effort de test sur ses éléments doit toujours être alignée sur les enjeux métiers.

La question fondamentale à toute démarche de test est la suivante : quels sont les risques encourus et quelles mesures doivent être prises pour éliminer ces risques ? Dans le cas d'une architecture orientée services, alignée sur des objectifs métiers, la stratégie mise en oeuvre pour répondre concrètement à cette question sera sensiblement différente - et plus complexe - que dans le cas d'un projet SI traditionnel.

Un service utilisé par plusieurs autres services ou processus métier doit être d'une qualité irréprochable. Pour tester ce service, vous devez déployer un effort supplémentaire. Mais par qui le faire financer ? Plusieurs parties prenantes sont concernées. Le fournisseur du service semble être le candidat le plus évident car il se doit d'assurer la qualité de ce qu'il met à disposition de ses clients. Ceux-ci ont justement tout intérêt à disposer d'un service de haute qualité, puisqu'il leur délivre de la valeur, et il semble également logique de leur demander de participer à l'effort de test... à hauteur du bénéfice que chacun peuvent en tirer.

Un des principes de la SOA est de toujours d'avoir une bonne raison métier de faire les choses, et la phase de recette est également soumise à ce principe. L'augmentation du nombre de services, de leur taux de réutilisation par des applications ou d'autres services oblige à opérer des choix sur le niveau de profondeur des tests. Le risque est que l'équipe de qualification veuille tout tester à tous les niveaux. Les niveaux et les types de tests sont déjà nombreux sur les applications traditionnelles : unitaires, intégration, non-régression, performance, etc... Ces mêmes aspects sont à appliquer également à la couche service.

On ne peut logistiquement pas tout tester et cela n'est économiquement pas souhaitable, le coût de la réduction des risques marginaux étant supérieur à celui de la réalisation de ceux-ci. Il faut faire un choix en fonction des risques et des priorités du métier.

Les différents interlocuteurs métier impactés par une architecture orientée service doivent donc être impliqués fortement dans la définition de la stratégie de tests. Ils auront pour responsabilité de définir explicitement les niveaux de risques métiers et les priorités de test sur les composants fonctionnels. Ces informations seront agrégées par l'équipe en charge de la recette avec leur pendant sur les risques techniques et la correspondance avec les composants d'implémentation afin de rédiger un plan de test global.

Il reste encore à définir le planning des tests. Qualifier une architecture SOA implique souvent, pour tester un service, de disposer d'un autre service qui est utilisé par le premier. Mais ce service est-il déjà disponible, testé et d'un niveau de qualité suffisant ? Pour tester une architecture SOA, il est obligatoire d'aligner la planification de ce test avec celle du développement ou de la mise en oeuvre des services.

Aucun planning de test n'est figé dans le marbre. En plus des retards éventuels de livraison, les interlocuteurs métier et le responsable de recette constateront au fil des itérations successives du processus de test, que certains risques ont été exagérés, d'autres sous-estimés ou négligés. La stratégie et les efforts associés ainsi que la planification devront être adaptés à ces nouvelles données. Ici également, un dialogue continu est nécessaire.

La qualification d'une architecture SOA nécessite donc une phase de réflexion amont importante, l'implication forte des clients ou commanditaires métier et un dialogue continu y compris avec les équipes de développement. L'évaluation des risques et des bénéfices permet de prioriser et de gérer l'effort de test en fonction de la qualité attendue car la SOA est qualifiée sur la base de quatre : les résultats attendus, le risque courus, le temps disponible et le coût.

Autour du même sujet