Le déroulement des tests fonctionnels

test fonctionnel

(temps de lecture moyen : 3 min)

Les tests fonctionnels consistent à vérifier que la solution cible, complète ou partielle, a été développée conformément aux attentes exprimées par le Client.

Voici les cinq activités principales:

Tester la conformité de la solution

A ce stade, l’objectif de la Business Analysis 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 et décrits dans les spécifications fonctionnelles détaillées. C’est l’objet des scenarios qui regroupent les exigences de manière logique.
  • Des règles métier et besoins de bas niveau, également exprimés et décrits dans ou en accompagnement des spécifications fonctionnelles détaillées. Ce sont 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 fonctionnels, 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 déroule ses cas de test dans une application dédiée ou dans un outil de bureautique (en général, Excel).

Reporter les 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:

  • déroulent 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…

Diagnostiquer les causes

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 donc sur son métier).
  • Le niveau d’urgence, en phase de tests fonctionnels, 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 !

Quant aux demandes d’évolution, elles 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.

Recommander une modification de la solution ou des processus

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 « collecte d’information / analyse du besoin / mise à jour des spécifications fonctionnelles détaillées / mise à jour des cas de tests / test fonctionnel ».

Contrôler l’implémentation des recommandations

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.

Ici, l’input du Business Analyst est 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 fonctionnels

Une fois que les tests fonctionnels ont tous été déroulé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 fonctionnels 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.

Poster un Commentaire

avatar
  S’abonner  
Notifier de