L’exécution des tests métiers

(temps de lecture moyen : 3 min)

L’exécution des tests métiers consiste à vérifier que la solution cible, complète ou partielle, a été développée conformément aux attentes exprimées par le Client et que celle-ci apporte réellement de la valeur aux utilisateurs.

Voici 5 activités phares de l’exécution des tests métiers:

• Vérification de la conformité de la solution en regard des attentes du Client ;
• Signalement des anomalies et les non-conformités ;
• Diagnostic des causes des anomalies métiers ;
• Proposition de solutions fonctionnelles;
• Vérification de la correction et des mises en oeuvre des demandes d’évolution.

Vérification de la conformité de la solution en regard des attentes du client

A ce stade, l’objectif de la Business Analyse est de valider que la solution, quelle que soit sa forme (composant, solution complète, prototype), répond aux besoins du Client.

Le déroulement des tests fonctionnels dépend :

• du planning de livraison de l’équipe de développement. C’est l’objet des campagnes, qui découpent les tests en fonction des composants développés.
• des besoins Client de haut et moyen niveaux, exprimés sous et décrits dans les spécifications fonctionnelles générales sous la forme d’exigences fonctionnelles de haut niveau. C’est l’objet des scenarios qui regroupent les exigences de manière logique.
• Des règles métier et besoins de bas niveau exprimés sous forme d’exigences fonctionnelles et non fonctionnelles dans les spécifications fonctionnelles détaillées et les cas d’utilisation de la solution.
• De la compréhension du métier de l’Organisation et des utilisateurs. En effet, en phase de tests métiers, le Business Analyst doit également vérifier l’impact favorable de la solution cible (elle doit amener des points d’amélioration).

Selon le contexte, le Business Analyst rédige et exécute ses cas de test dans une application dédiée ou dans un outil de bureautique (en général, Excel).

Signalement des anomalies et les non-conformités

Là aussi, selon le contexte projet, un outil de reporting peut être imposé au Business Analyst. Il est en effet indispensable de coordonner les activités entre les Acteurs du projet qui:

• exécutent les tests,
• corrigent les anomalies techniques,
• corrigent les anomalies fonctionnelles,
• implémentent les demandes d’évolution,
• font le suivi d’avancement,
• valident la phase de tests fonctionnels.

Reporter les anomalies et les non-conformités doit se faire de manière précise, circonstanciée et non ambiguë. Donner un maximum d’information au développeur permet de corriger le bug plus facilement et plus rapidement : qui, quand, quoi, comment, avec quoi, résultat attendu, résultat obtenu…

Diagnostic des causes des anomalies

Les anomalies et les non-conformités sont de trois sortes :

• anomalie technique: erreur dans le programme ;
• anomalie fonctionnelle: erreur ou ambiguïté dans les spécifications fonctionnelles ;
• non-conformité aux besoins du Client: ceux-ci n’ont peut-être pas été identifiés en amont. Il s’agit donc d’une demande d’évolution des spécifications fonctionnelles détaillées.

Les anomalies techniques et fonctionnelles doivent être corrigés. Elles sont classées en niveaux de criticité et d’urgence.

• La criticité se rapporte à l’impact que la non-conformité a sur l’expérience utilisateur et les enjeux économiques de l’Organisation.
• Le niveau d’urgence, en phase de tests métiers, permet de prioriser les corrections. Les plus urgentes bloquent littéralement un scenario ou une campagne de tests. Les moins urgentes n’impactent pas le déroulement des autres tests.

Ce classement est d’ailleurs souvent l’objet d’âpres discussions entre Client, Business Analyst et Développeur !

Dans les projets traditionnels, les demandes d’évolution sont en général implémentées si la charge de travail de l’équipe technique le permet. Sinon, elles sont listées pour éventuellement faire l’objet d’upgrade des releases ultérieures de la solution au travers du processus de Change Requests.

Dans les projets agiles, le traitement des anomalies et des demandes d’évolutions alimentent le Product Backlog.

Proposition de solutions fonctionnelles

Le Business Analyst a comme mission d’assurer l’adéquation de la solution livrée avec les besoins du Client.

Aussi doit-il être capable de détailler de quelle manière une anomalie fonctionnelle ou une non-conformité doivent être traitées. Il repart donc souvent dans un cycle d’itérations « recueil d’information / analyse du besoin / mise à jour des spécifications fonctionnelles détaillées / mise à jour des cas de tests / test fonctionnel ». Et dans les projets agiles, il s’agit d’alimenter un nouveau sprint avec des user stories et critères d’acceptance ad hoc.

Vérification de la correction et des mises en œuvre des demandes d’évolution

Une fois les anomalies et non-conformités détectées et reportées, elles sont corrigées par les équipes de développeurs. La livraison de la solution corrigée nécessite parfois d’incrémenter une nouvelle version. D’autres fois, la correction est mineure et peut se faire dans la version en cours de test.

Le Business Analyst se base sur la stratégie développée par l’équipe technique et validée par le Chef de Projet. En effet, celle-ci est fonction des choix faits sur le projet mais aussi du contexte organisationnel. Par exemple, certaines organisations encadrent étroitement les processus, et livrent des releases à dates précises, alors que d’autres sont plus flexibles et peuvent livrer à la demande.

Le Business Analyst doit donc planifier ses contrôles en fonction de cette stratégie.

Pour finir… la validation de la phase de tests métiers

Une fois que les tests métiers ont tous été exécutés, il reste un certain nombre d’anomalies et de non-conformités non corrigés. Le Business Analyst est au minimum consulté, ou est décideur, quant à la validation de la phase de tests.

En général, seuls les anomalies mineures sont tolérées, ainsi que les non-conformités… mais il s’agit là d’une décision projet qui dépend donc fortement du contexte, et il n’y a pas de règles immuables.

Le livrable de la phase de tests métiers est en général le quitus donné par le Business Analyst (ou tout autre Acteur désigné) pour poursuivre le projet en l’état.