Le leadership dans le test : L’assurance des processus métier en entreprise
Note de l’éditeur : Bienvenue dans la série Leadership In Test de l’expert en tests logiciels et consultant Paul Gerrard. Cette série est conçue pour aider les testeurs ayant déjà quelques années d’expérience—en particulier ceux qui font partie d’équipes agiles—à exceller dans leurs rôles de lead test et de gestion.
Dans l’article précédent, nous avons examiné les outils nécessaires pour un test et une collaboration efficaces. Dans cet article, nous abordons la phase finale des tests et la façon de vérifier que vos systèmes répondront aux attentes.
Abonnez-vous à la newsletter The QA Lead pour être averti dès que de nouveaux articles de la série sont publiés. Ces publications sont des extraits du cours Leadership In Test de Paul, que nous vous recommandons vivement pour approfondir ce sujet et bien d’autres. Si vous vous inscrivez, utilisez notre code promotionnel exclusif QALEADOFFER pour économiser 60 $ sur le prix total du cours !
Nous arrivons aux deux derniers articles de la série Leadership In Test. Jusqu’ici, nous avons couvert comment planifier et gérer un projet de test du début à la fin et de nombreux outils et processus impliqués.
Pour cet article, je souhaite aborder l’Enterprise Business Process Assurance (EBPA) : de quoi s’agit-il et comment l’aborder. Nous aborderons :
- Qu’est-ce que l’Enterprise Business Process Assurance ?
- Comprendre l’intégration et les tests des systèmes
- Tests horizontaux : l’approche de test E2E
- Risques d’intégration et tests E2E
Il y a beaucoup à voir, alors commençons sans attendre.
Qu’est-ce que l’Enterprise Business Process Assurance ?
Toute organisation mettant en œuvre de nouveaux systèmes a connu des problèmes lors de leur première utilisation. Les systèmes qui ne correspondent ne serait-ce qu’un peu à l’infrastructure et aux processus métiers existants peuvent causer des perturbations et être difficiles à corriger.
Les pratiques itératives, agiles et plus collaboratives sont utiles, mais les défis de l’intégration à l’échelle de l’entreprise ne peuvent être relevés que par une phase finale de test.
Nous appelons cette phase finale Enterprise Business Process Assurance (EBPA). La réussite dépend d’une ou plusieurs phases de tests qui permettront de démontrer que les systèmes, les processus métiers et les données sont intégrés et délivrent les services promis.
Il existe peu d’articles académiques sur le sujet, alors même que les dernières étapes de chaque projet de grande envergure sont dominées par cette activité. Pour éclairer notre stratégie EBPA, commençons par examiner de plus près les types d’intégration et de tests des systèmes auxquels vous serez confrontés.
Pour les projets d’envergure entreprise, la complexité augmente de façon exponentielle. C’est pourquoi choisir un logiciel de gestion de bases de données de niveau entreprise peut changer la donne dans vos efforts d’ingénierie qualité.
Comprendre l’intégration et les tests des systèmes
Intégration verticale
D’un point de vue technique, l’intégration représente la connexion entre les différentes couches de l’architecture technique. Les tests d’intégration pour les développeurs consistent principalement à vérifier que les données saisies via l’interface utilisateur lors d’une transaction de mise à jour sont bien stockées en base de données.
Dans l’autre sens, les données stockées sont vérifiées pour s’assurer qu’elles peuvent être correctement affichées dans l’interface utilisateur sur demande. Les connexions et parcours à travers l’architecture technique peuvent être vus comme des chemins verticaux ou des tests d’intégration verticale.
Intégration horizontale
Les utilisateurs finaux ne perçoivent pas l’architecture technique avec toute sa complexité. Ils voient le système comme une succession de fonctionnalités, utilisées par différents utilisateurs dans ce que l’on pourrait appeler un parcours utilisateur.
Ces parcours suivent le fil des processus métiers des utilisateurs et accèdent, à chaque étape, à différents systèmes et fonctionnalités via l’interface utilisateur.
Les équipes agiles travaillent sur des histoires à plus petite échelle et ne voient pas le grand ensemble. Généralement, les développeurs ne peuvent pas retracer et tester des parcours utilisateurs plus longs, car ils ne disposent pas des environnements ou des données nécessaires. Ainsi, les organisations comptent généralement sur des tests à plus grande échelle et sur des équipes de testeurs pour les valider.
Les parcours utilisateurs couvrent naturellement à la fois le processus métier et les fonctionnalités du système. De cette façon, les tests horizontaux mettent à l’épreuve l’intégration entre les systèmes et le processus métier.
Les tests d’intégration verticale adoptent une perspective plus technique ; les tests horizontaux adoptent une perspective utilisateur ou processus métier.
Utilisons maintenant ces concepts pour construire un modèle qui nous aidera à comprendre et à planifier l’EBPA. Nous ferons référence aux approches d’intégration horizontale et verticale dans le modèle.
Un modèle pour l’intégration et les tests
L’intégration est un concept souvent mal compris. Le processus d’intégration commence en réalité presque dès que le codage débute. On pourrait dire que l’intégration commence dès que nous avons deux lignes de code — la deuxième ligne de code devant être intégrée à la première. L’intégration se termine lorsque tous les tests fonctionnels prennent fin, lors de l’acceptation utilisateur.
Concentrons-nous sur un exemple utilisant des modules commerciaux prêts à l’emploi (COTS) et des modules de planification des ressources d’entreprise (ERP).
L’éditeur de logiciels qui crée des modules COTS ou ERP a réalisé des tests unitaires et fonctionnels. Lorsque ces composants arrivent, on peut généralement supposer qu’ils fonctionnent et s’intègrent techniquement. Mais il existe toujours un risque que des composants intégrés provenant de différents fournisseurs interagissent de manière imprévue.
De plus, si les composants sont personnalisés, leur comportement sera modifié et cela risque à nouveau de provoquer des effets secondaires subtils (ou moins subtils) ailleurs. Il reste donc nécessaire d’effectuer une intégration verticale pour vérifier l’échange de contrôle et de données dans la pile technologique, ainsi qu’une intégration horizontale entre les composants et le processus métier.
Nous représentons les quatre activités d’intégration dans un modèle à quatre quadrants avec deux axes. Sur l’axe X, nous avons l’échelle du système testé – soit un seul composant ou sous-système de manière isolée, soit les systèmes intégrés dans le contexte du processus métier.
Le côté droit du modèle est ombré en bleu et représente l’EBPA. Tester notre système dans le contexte d’autres systèmes (SIT) et du processus métier (BIT) est ce que nous appelons l’Enterprise Business Process Assurance.
Examinons à présent chacun des quatre quadrants.
Test de module, fonctionnalité ou composant
Le module doit être testé fonctionnellement qu’il soit développé sur mesure ou soit un composant COTS. L’expérience utilisateur reste toujours importante et doit s’intégrer à une étape ou activité du processus métier.
Test d’intégration de sous-système
L’intégration est incrémentale. À mesure que les composants et fonctionnalités de bas niveau deviennent disponibles, ils sont intégrés dans un système de plus en plus large et testés jusqu’à ce que le système complet et cohérent soit prêt. Nous appelons cela le test d’intégration de sous-système.
Test d’intégration système (SIT)
Aucun système n’existe isolément, donc lorsque notre système est terminé, il faut l’intégrer avec d’autres systèmes. Nous installons notre système dans un environnement avec les systèmes en interface et nous testons ces systèmes fonctionnant comme un « système de systèmes » à travers ces interfaces. L’objectif à ce stade est d’adresser les risques techniques liés à l’intégration, ce que nous appelons le test d’intégration système.
Test d’intégration métier (BIT)
Il existe une dernière étape d’intégration qui vise à s’assurer que les systèmes réalisés s’intègrent avec les processus métier et les procédures (souvent manuelles) des utilisateurs de ces systèmes. En incluant les interfaces externes du système (si ce n’est pas déjà fait), nous validons que les systèmes et les processus métiers, en collaboration, offrent des parcours utilisateurs cohérents et efficaces, et qu’ils gèrent et transfèrent les données correctement et de manière homogène. On parle habituellement de test d’intégration métier.
Pour le reste de cet article, nous allons beaucoup nous concentrer sur l’aspect horizontal (EBPA) du modèle.
À lire également : 10 MEILLEURS OUTILS DE GESTION DES DONNÉES DE TEST
Test horizontal : l’approche de test E2E
L’intégration horizontale repose principalement sur ce que l’on appelle souvent le test de bout en bout (E2E).
L’E2E testing est une technique de conception de tests qui met en jeu une série de transactions connectées, couvrant typiquement plusieurs systèmes y compris notre ou nos systèmes à tester. Ces tests ont tendance à suivre les parcours utilisateurs à travers leurs processus métiers.
À partir d’un modèle du processus métier, on trace des chemins à travers ce processus pour créer une série utile de transactions qui simulent la façon dont les utilisateurs utiliseront le système en production.
Ces modèles peuvent prendre la forme de diagrammes familiers comme des organigrammes ou des diagrammes de couloirs, ou être des représentations plus techniques telles que des diagrammes de séquence ou de collaboration UML. (UML est le langage de modélisation unifié utilisé par de nombreuses organisations informatiques).
L’E2E testing permet d’adresser des risques spécifiques qui ne peuvent pas être traités facilement par les tests antérieurs sur les sous-systèmes ou les environnements reposant fortement sur des interfaces simulées et des données entièrement synthétiques.
Dans le domaine du Test horizontal, l’approche E2E est souvent complétée par des logiciels spécialisés. Pour une sélection de logiciels susceptibles de rationaliser ce processus, consultez ces solutions de gestion des tests les mieux notées
Acceptation
La notion d’« adéquation » est appropriée pour l’intégration composant-composant, l’intégration système-système et l’intégration systèmes-processus métier.
L’acceptation est généralement basée sur les résultats des tests de bout en bout horizontaux (E2E), car les parties prenantes métiers peuvent faire confiance à ces tests pour démontrer comment le nouveau système s’intègre et soutient leurs méthodes de travail. Les tests E2E horizontaux leur donnent l’assurance que le service livré fonctionnera.
Le processus d’acceptation des systèmes dépend habituellement, au moins en partie, de la réussite des tests E2E horizontaux. Cela s’explique par le fait que seuls les tests E2E font fonctionner le système dans un environnement réaliste et simulent une activité utilisateur réelle.
Dans de nombreuses organisations, il n’est possible de démontrer le fonctionnement des systèmes qu’aux étapes finales des tests, ce qui apporte l’assurance aux parties prenantes que le système fonctionnera comme attendu.
Si l’on vous demande de planifier un test d’acceptation, nous nous attendons à ce que la technique de test E2E joue un rôle important dans votre planification.
Risques d'intégration et tests E2E
Comme évoqué, les risques d’intégration concernent l’intégration système-système ou l’intégration système-processus métier.
Certaines organisations choisissent de diviser les tests qui adressent ces deux types de risques en tests d’intégration système (SIT) et tests d’intégration métier (BIT). Mais souvent, les risques et les tests sont fusionnés en une seule étape de test, intitulée test de bout en bout (E2E), Acceptation ou Test métier.
Quelle que soit la structure des tests, on fait largement usage de l’approche de test E2E décrite ci-dessus. Dans votre environnement, les risques que vous rencontrez peuvent être des variations sur ces thèmes et vous devrez peut-être ajuster l’objectif du test et votre approche de test en conséquence.
La liste des risques présentée ici doit être considérée seulement comme un point de départ et pour rappeler où concentrer vos efforts de test. Il est probable qu’il existe des risques spécifiques à votre organisation, secteur ou technologie qu’il faudra ajouter à cette liste initiale.
Dans le tableau ci-dessous, « systèmes » fait référence à l’ensemble des systèmes intégrés comprenant le/les nouveaux système(s) en développement, d’autres systèmes existants ou d’infrastructure, ainsi que des systèmes externes tels que des banques ou des organisations partenaires.
| Risque | Objectif du test | Méthode de test |
| Les systèmes ne sont pas intégrés (transfert de données). | Démontrer que les systèmes sont intégrés et effectuent correctement le transfert de données. | System Integration Test (SIT) |
| Les systèmes ne sont pas intégrés (transfert de contrôle). | Démontrer que les systèmes sont intégrés (le transfert de contrôle avec les paramètres requis est effectué correctement). | SIT |
| Les interfaces échouent lorsqu’elles sont utilisées sur une longue période. | Démontrer que les interfaces peuvent être utilisées en continu pendant une longue période. | SIT (Ces vérifications peuvent aussi être menées dans le cadre des tests de fiabilité et/ou de basculement) |
| Les systèmes ne sont pas intégrés (les données ne sont pas conciliées via les interfaces). | Démontrer que les systèmes sont intégrés (les données transférées via l’interface sont utilisées de façon cohérente, par ex. devise, langue, unités, délais, exactitude, tolérances). | SIT |
| Les systèmes ne sont pas synchronisés (les transferts de données ne sont pas déclenchés, déclenchés au mauvais moment ou plusieurs fois). | Démontrer que les transferts de données sont déclenchés correctement. | SIT |
| Les objets ou entités présents dans plusieurs systèmes ne sont pas conciliés entre les systèmes. | Démontrer que les états des objets métier sont représentés précisément dans tous les systèmes qui détiennent des données sur les objets. | Business Integration Test (BIT) |
| Les systèmes ne sont pas intégrés avec le processus métier (chaîne d’approvisionnement). | Démontrer que les systèmes s’intègrent avec les processus métiers et soutiennent la chaîne d’approvisionnement. | BIT |
| Les processus métier en back-end ne soutiennent pas les front-ends Web ou mobiles. | Démontrer que les processus de la chaîne d’approvisionnement sont efficaces et soutiennent l’objectif métier. | BIT |
| Des systèmes intégrés utilisés par les mêmes collaborateurs présentent des interfaces utilisateur ou des comportements incohérents pour des tâches similaires ou reliées. | Démontrer que les utilisateurs rencontrent un comportement cohérent sur l’ensemble des systèmes en réalisant des tâches similaires ou reliées. | BIT (Ces vérifications peuvent également être effectuées lors des contrôles UX) |
Remarques sur le tableau des risques
Certains des risques ci-dessus nécessitent quelques explications supplémentaires.
Problèmes de transfert de données
Souvent, les données sont transférées entre systèmes via les réseaux. Si ces transferts sont exécutés sous forme de processus batch et échouent, ou échouent en tant que transfert en temps réel déclenché par un utilisateur, un métier ou un autre événement système, alors les données seront absentes du système cible.
Transfert de contrôle défectueux
Un transfert de contrôle survient lorsqu’une activité utilisateur ou un processus système transfère l’utilisateur ou le processus vers une autre fonctionnalité du système.
En général, il existe un choix de fonctionnalité cible et, selon l’action de l’utilisateur ou le contenu des données d’une transaction, un choix d’une route différente dans l’application est effectué.
Du point de vue de l’utilisateur, il est conduit au mauvais endroit dans l’application ou un processus système s’attend à exécuter le mauvais processus et perd la synchronisation.
Données non conciliées
Un système peut distribuer des données relatives, par exemple, à de l’argent, à la localisation d’actifs, ou à une quantité physique qui doit « correspondre » dans tous les systèmes.
Par exemple, lorsque 100 articles de stock sont achetés et déplacés, vendus, utilisés dans des processus de fabrication, jugés défectueux puis renvoyés ou mis au rebut, le nombre d’articles détenus dans chaque sous-système doit concorder avec le compte initial de 100.
Une variante de ce problème concerne, par exemple, les unités utilisées dans les systèmes qui détiennent les données. Les tailles de lot ou les agrégations des comptages doivent être prises en compte, ou les systèmes doivent concilier les mesures métriques et impériales, etc.
Systèmes non synchronisés
En lien avec le problème de transfert de données mentionné ci-dessus, les processus système qui assurent les transferts sont programmés pour s’exécuter dans le bon ordre, déclenchés par des processus ou personnes dûment autorisés, et sont activés en temps voulu, selon l’événement approprié ou la combinaison d’événements adéquate.
Certains traitements par lots doivent être exécutés chaque heure, chaque jour, chaque semaine, à la fin du mois, du trimestre ou de l’année, etc., et doivent être vérifiés. Une grande partie du comportement fonctionnel dépend du rythme relatif des transactions ou de l’ancienneté des données entre systèmes, ce qui doit également être contrôlé.
Les objets ne sont pas réconciliés
Plutôt que des comptes d’objets, d’argent ou de mesures physiques, ces risques concernent le statut des objets conservés dans des systèmes distribués. Par exemple, le statut d’un employé dans un dossier du personnel devrait être cohérent entre tous les systèmes possédant une copie de cet objet de données. Les processus qui diffusent les changements d’état entre systèmes contenant des copies d’un même objet doivent être déclenchés et leurs actions vérifiées.
Systèmes non intégrés à l’entreprise
Le comportement des systèmes doit être synchronisé avec les intentions des utilisateurs. Les problèmes typiques sont ceux où le système présente des informations incomplètes, obsolètes ou erronées. La cause profonde est le dysfonctionnement des transferts ou synchronisations de données, mais ces problèmes se manifestent à travers l’interface utilisateur.
Les processus back-end ne soutiennent pas le front-end
Ce type de problème se manifeste comme une incohérence entre les systèmes d’enregistrement et les systèmes d’interaction. Les processus batch back-end qui ne sont pas exécutés suffisamment souvent, ou pas du tout, ne rendent pas les données disponibles aux systèmes de front-end. De même, les transactions utilisateur effectuées via le front-end ne sont pas reflétées dans les systèmes d’enregistrement.
Interfaces utilisateurs incohérentes
Lorsqu’un service ou une entreprise est proposée via des interfaces mobiles, web et sur bornes interactives, l’interface utilisateur se comporte de façon différente ou incohérente. Elles ont peut-être toutes été testées indépendamment, mais leur comportement reste différent. Par exemple, des règles de validation de saisie différentes sont appliquées, des champs de données différents sont saisis ou affichés, ou encore la séquence de saisie diffère.
Dernières réflexions
Nous avons présenté un modèle d’intégration et de test qui met l’accent sur l’intégration à l’échelle de l’entreprise et le processus métier. L’approche E2E est la seule qui exige une intégration complète des systèmes et qui fonde les tests sur des parcours utilisateur complets. De cette manière, les parties prenantes peuvent observer la preuve du bon fonctionnement des systèmes dans un contexte réaliste.
De nombreuses organisations comptent sur les utilisateurs pour appliquer une forme de test E2E lors de leurs tests d’acceptation et pour effectuer ces tests manuellement. Pour ma part, je plaide en faveur d’une approche plus systématique et basée sur les risques, afin de faciliter l’automatisation d’une grande partie du travail d’exécution des tests.
À mesure que les organisations adoptent des méthodes de développement agiles et de livraison continue plus dynamiques, en donnant aux équipes agiles une plus grande responsabilité sur les tests de leurs sous-systèmes, il est facile de négliger par la suite l’intégration et les tests d’acceptation à l’échelle de l’entreprise.
L’approche EBPA, surtout si elle est automatisée, étend le régime d’intégration continue du sous-système à l’assurance du processus métier de l’entreprise.
Les solutions COTS et les progiciels ERP permettent de mettre en œuvre des systèmes extrêmement puissants mais complexes avec moins d’efforts de développement, toutefois les risques liés à l’intégration sont tout aussi présents que pour les développements logiciels sur mesure.
Dans les environnements les plus vastes, les approches agiles et de livraison continue sont de plus en plus populaires, donc à mesure que la complexité et la taille augmentent, la fréquence de livraison et le risque associé augmentent eux aussi.
La solution est claire : les organisations doivent prendre l’EBPA au sérieux. Elles doivent comprendre les risques d’intégration et savoir comment organiser les tests pour les traiter. Les testeurs doivent adopter l’approche moderne basée sur les modèles et abstraire leurs processus métier, leurs systèmes et leurs tests, et mettre en œuvre l’automatisation des tests de façon systématique.
Inscrivez-vous à la newsletter The QA Lead pour être averti lorsque de nouvelles parties de la série sont publiées. Ces articles sont des extraits du cours Leadership In Test de Paul que nous recommandons vivement pour approfondir ce sujet et bien d’autres. Si vous souhaitez le suivre, utilisez notre code promo exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix du cours complet !
Lecture suggérée : 10 MEILLEURS OUTILS DE GESTION DE TESTS OPEN SOURCE
