Les TI permettent aujourd’hui d’établir des processus d’affaires plus évolués, mais plus complexes à tester de bout en bout. L’une des difficultés à cet égard vient de la nécessité de prendre en charge de multiples interfaces d’application. 
La modélisation des processus d’affaires (business process modeling ou BPM) connaît une popularité croissante. Les entreprises y ont recours pour créer une représentation de leurs processus courants, tels qu’ils existent. Cette « image » est utilisée en tant que base de référence pour l’accroissement de l’efficacité organisationnelle et l’établissement de nouveaux processus intégrant les améliorations jugées pertinentes.
Certains processus ainsi modélisés chevauchent plusieurs applications, chacune d’elles ayant été testée séparément au fur et à mesure qu’elles ont été développées ou intégrées. Dans ce contexte, il est fréquent qu’un processus ne soit pas entièrement testé. On n’en teste que des parties, et ce, même s’il s’agit d’un tout cohérent qui mérite une analyse complète et uniforme.
Cette carence est due au fait que, de façon générale, les outils de test n’ont pas la capacité de prendre en charge les différentes interfaces d’application. Par exemple, certains outils de pistage des demandes HTTP qui sont dirigées vers un serveur sont utilisés pour tester une interface Web et ne peuvent donc pas servir pour une application client-serveur. On fait face au même problème lorsque le processus d’affaires comprend une application terminale ou mobile, ou une composante de réponse vocale intégrée (RVI). Pourtant, il est fréquent qu’un processus s’étende sur plusieurs applications ayant des interfaces différentes et, par conséquent, qu’il soit difficile de le tester de bout en bout avec un seul outil de script d’application.
Voyons un exemple plus concret : une banque souhaite tester le traitement d’une première transaction exécutée dans un compte nouvellement créé. Pour accéder à ce dernier, le client utilise une application web qui est reliée à un ordinateur central patrimonial. Il a aussi la possibilité de faire la transaction depuis une application mobile ou un guichet automatique. Les spécialistes chargés de tester le processus devront donc composer avec les interfaces patrimoniale, web et mobile. Ils peuvent aussi avoir à créer un script simulant un guichet bancaire, ce qui pourrait nécessiter un autre type d’interface. En bout de piste, la vérification de ce processus ne pourra être effectuée à l’aide d’un seul outil de script d’application.
Pour compenser, on simule des parties du processus, mais cela demande des efforts et entraine des coûts. On suppose que le processus s’est déroulé correctement jusqu’au déclenchement de l’interface testée et on imagine des situations intermédiaires à partir desquelles on peut tester les parties mono-interface. Dans ce contexte, il n’est pas rare qu’un processus ne soit pas testé intégralement.
Outil prenant en charge des interfaces multiples
Si, pour optimiser un processus, on juge nécessaire de le modéliser dans son intégralité, il est important que le même raisonnement soit appliqué aux tests logiciels relatifs à ce processus. Afin d’analyser globalement un tel ensemble, il faut une cohésion dans les tests et un moyen de les regrouper. Cette exigence peut être comblée à l’aide d’un outil capable de prendre en charge différents logiciels de script de tests – pour les pages Web, les terminaux, les applications de RVI, etc. L’utilisation d’un tel outil est la seule façon d’analyser efficacement la totalité d’un processus dont les applications sont dotées d’interfaces différentes.
Il s’agit là d’un besoin pressant, car le modèle de développement de processus intégrant diverses applications est de plus en plus courant dans les entreprises. Le phénomène est notamment attribuable à la complexification des processus, laquelle découle de la forte puissance de traitement disponible aujourd’hui, du caractère évolué des applications et de l’arrivée de nouveaux canaux de distribution (téléphones intelligents, tablettes, etc.). Non seulement est-il probable que les applications comprises dans un processus soient dotées d’interfaces différentes, mais il est possible que plusieurs équipes soient affectées aux tests. D’où l’importance de coordonner les efforts d’analyse et de test à l’aide d’un outil performant et polyvalent.
À l’heure où l’on demande aux services de TI de contribuer fortement à accroître le rendement organisationnel dans des limites budgétaires étroites, les processus d’affaires des entreprises doivent être continuellement optimisés. Dans ce but, il est important de se donner les moyens de les tester intégralement et rigoureusement, sans que l’exercice soit démesurément long et coûteux. Il ne suffit plus de contrôler la qualité d’un processus en partie seulement.
