Contrairement aux tests d'intégration qui sont cadrés par le
PEP, les tests utilisateurs doivent se dérouler sans contraintes afin que les valideurs puissent s'exprimer librement pour pouvoir explorer tous les cas qu'ils souhaitent.
Pour les aider dans cette tâche ils disposeront du manuel livré avec le prototype (MUP). Il faut cependant leur conseiller de ne pas s'en tenir strictement aux consignes du manuel mais d'essayer toutes les actions qui leur viendront à l'esprit. Dans ce but il est indispensable d'adjoindre au manuel utilisateur un document qui explique cette façon de procéder et qui présente les principales catégories d'anomalies qui peuvent être rencontrées. La liste ci-dessous est loin d'être exhaustive mais donne un aperçu de la variété existante.
Anomalie bloquante
Une anomalie est dite bloquante si elle empêche la poursuite des tests. Elle peut être bloquante uniquement au niveau du logiciel livré mais aussi, et c'est le cas le plus grave, au niveau du système d'exploitation. Dans ce dernier cas on est parfois obligé de rebooter l'ordinateur.
Anomalie liée à l'installation
L'installation se déroule mal. Il manque des fichiers, la procédure n'arrive pas à son terme...
Anomalie des résultats
Le résultat obtenu à la suite d'une opération est erroné. Ce résultat peut être affiché, imprimé ou enregistré dans une base de données.
Anomalie liée à la navigation
L'enchaînement des pages ou des fenêtres n'est pas correct, soit que la fenêtre ou la page demandée ne s'affiche pas du tout, soit qu'une mauvaise fenêtre ou page apparaît.
Anomalie liée à la saisie
Manque d'information concernant le format des données à saisir, pas de message permettant d'informer l'utilisateur qu'il a entré des données hors normes : plage ou liste de valeur non respectée.
Anomalie liée aux droits d'accès
Le valideur peut réaliser une opération à laquelle il n'a pas droit ou inversement, il ne peut exécuter une opération alors qu'il en possède le droit.
Anomalie de présentation
L'information affichée est illisible, mal disposée, incohérente… Ce type d'anomalie relevant généralement de problèmes ergonomiques, son signalement peut parfois différer d'un utilisateur à l'autre.
Anomalie concernant l'information de l'utilisateur.
Un message apparaît qui n'a aucun sens pour l'utilisateur, une erreur de manipulation flagrante n'est pas signalée. L'exécution en cours d'une opération n'est pas indiquée.
Anomalie liée aux temps de réponse
Les résultats de certaines opérations sont obtenus après un délai insupportable, l'affichage est lent.
Anomalie liée à la concision
Il manque des raccourcis clavier ou des icônes permettant d'accélérer l'accès à certaines fonctions.
Anomalie liée à une incohérence matérielle
Serveur inaccessible dans le cas d'une application client-serveur, imprimante mal adaptée, définition d'écran insuffisante.
Anomalie portant sur l'aide interactive
L'aide n'est pas toujours disponible, elle est trop succincte, elle est incompréhensible et/ou trop technique.
Anomalie du manuel utilisateur
Les instructions données dans le manuel sont mal rédigées, incohérentes avec le logiciel, fausses ou incompréhensibles.
Le document explicatif doit indiquer également à l'utilisateur ce qu'il doit faire lorsqu'il rencontre une anomalie du type indiqué ou d'un type différent. Généralement on lui demandera de remplir un document spécifique appelé
Fiche d'Anomalie Prototype (FAP) qu'il transmettra au maître d'œuvre ou directement à l'équipe projet si l'anomalie est bloquante.
Un formulaire standard pourra être réalisé afin d'aider l'utilisateur dans la rédaction. Un formulaire électronique transmis par messagerie ou par un circuit de workflow spécialisé permettra de diminuer les délais de transmission.
Indépendamment des dysfonctionnements rencontrés, les valideurs pourront avoir des idées nouvelles concernant les fonctionnalités ou l'IHM du prototype. Dans ce cas ils pourront remplir une
Fiche de Modification Prototype (FMP) qui devra être discutée et éventuellement validée par l'instance compétente avant sa transmission au maître d'ouvrage. En effet, une telle modification survenant au cours du développement peut entraîner un allongement des délais prévus et donner lieu à un avenant au contrat si le développement est réalisé par une SSII.
Quatre cas peuvent se présenter lors de la discussion par l'instance décisionnelle :
- la modification est minime et peut être intégrée au prototype en cours sans inconvénients,
- la modification est importante mais nécessaire : elle sera intégrée dans le prototype suivant après réévaluation des délais et des coûts,
- la modification est intéressante mais pas indispensable actuellement : elle sera reportée à plus tard, lors de la sortie d'une nouvelle version du logiciel,
- la modification ne présente aucun intérêt général et l'idée est abandonnée.
Comme pour la FAP, un formulaire standard pourra être réalisé éventuellement sous une forme dématérialisée.
