Le reporting et le suivi des anomalies

(temps de lecture moyen : 2 min)

L‘exécution des tests métiers implique de savoir détecter et suivre la correction des 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 dans le cas de tests non automatisés:

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 reporting et le suivi des anomalies peut se faire à l’aide de logiciels spécialisés ou simplement dans un tableur du type Excel, manuellement ou de manière automatisée.

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 vérifier la couverture fonctionnelle des exigences du logiciel avant la phase de recette client.

Le Business Analyst a donc la responsabilité de :

• Reporter les anomalies et demandes d’évolution ;
• Proposer des solutions fonctionnelles ;
• Vérifier les correctifs techniques, y compris les non-régressions.
• Mettre à jour les spécifications fonctionnelles détaillées si nécessaire (ainsi que le glossaire et autres règles métier)
• Enfin, notez que les tests métiers sont un élément très important pour préparer la formation utilisateur et la gestion du changement.