Le reporting et le suivi des anomalies

Reporter et suivre les anomalies

(temps de lecture moyen : 2 min)

Quels outils utiliser ?
Le reporting des anomalies
Le suivi des anomalies

Le déroulement des tests fonctionnels implique de savoir détecter et suivre les anomalies.

Lors de cette étape, le Business Analyst doit donc mesurer la performance de la solution sur le plan fonctionnel, sans omettre son alignement avec les objectifs de l’Organisation (à l’échelle de l’équipe, du service, de l’entreprise etc…). Il doit donc se baser sur les Spécifications Fonctionnelles Détaillées, tout en restant vigilant s’il constate que ces dernières ne respectent pas le besoin client dans son ensemble.

Voici le processus nominal standard :

  1. Le testeur ouvre les cas de test, dans le cadre d’une campagne et d’un scenario donnés, et suit les instructions.
  2. A chaque écart par rapport aux attentes décrites, il reporte l’anomalie.
  3. Celle-ci est assignée automatiquement ou manuellement à l’un des développeurs dédié à la correction de la solution.
  4. Ce dernier va corriger le bug, ou développer la fonctionnalité manquante (pour les demandes d’évolution).
  5. La livraison de la correction dans l’environnement de test peut être faite par l’intermédiaire d’un intégrateur, dans une nouvelle version, ou sous forme de patch. Cette distinction est importante car elle impacte la poursuite des tests fonctionnels.
  6. Le Business Analyst vérifie que la correction est conforme.
  7. Si c’est le cas, l’anomalie est clôturée, sinon, elle est renvoyée à l’équipe technique jusqu’à ce que le Business Analyst la valide.
  8. Notez qu’en cours de test, Le Business Analyst peut être amené à modifier les SFD s’il constate qu’elles ne remplissent pas le besoin du Client. Cette modification, validée par le comité de pilotage (et donc le Client), fera l’objet d’une demande d’évolution

Quels outils utiliser ?

Selon le contexte du projet, le déroulement des tests fonctionnels, le reporting et le suivi des anomalies peut se faire à l’aide de logiciels spécialisés ou faute de mieux… dans un tableur.

La prise en main des logiciels de test est en général intuitive car ils ont souvent un panel de fonctionnalités similaires. Une fois l’un d’entre eux maîtrisé, les autres sont faciles d’accès, bien souvent sans formation. De plus, leur utilisation allège considérablement le travail de tous les collaborateurs impliqués dans cette phase du projet.

Un tableur peut aussi être utilisé pour des projets de petite dimension. Le Business Analyst doit cependant veiller à classer, organiser et nommer les fichiers des campagnes, scenarii et cas de test de manière rigoureuse. Enfin, il doit partager un processus clair entre les équipes fonctionnelles et techniques pour le reporting des anomalies (souvent réalisé par mail).

Le reporting des anomalies

Celui-ci doit être clair, circonstancié et rattaché au cas de test. Dire « ça ne marche pas » n’est pas suffisant.

Gardez à l’esprit que plus il y aura des détails relativement au contexte du test, plus le développeur aura de pistes pour effectuer la correction.

N’hésitez donc pas à indiquer les détails de connexion, les étapes du test, les valeurs obtenues vs. celles attendues, à mettre en pièce jointe copies d’écran et autres éléments utiles.

Le suivi des anomalies

Quel que soit l’outil utilisé, le processus « end-to-end » d’un test fonctionnel doit être tracé et suivre un workflow décrit et partagé à l’avance.

Autrement dit, il s’agit de tracer une anomalie depuis sa création jusqu’à sa clôture. Ce workflow met en place des rôles et responsabilités et permet d’y assigner des collaborateurs. Le chef de projet peut ainsi piloter l’évolution de la phase de tests fonctionnels, et la fluidité permet à l’équipe technique de travailler de manière efficace et efficiente.

C’est également essentiel pour s’assurer de la complétude fonctionnelle de la solution technique avant la phase de recette client.

Le Business Analyst a donc la responsabilité de :

Poster un Commentaire

avatar
  S’abonner  
Notifier de