- Tests utilisateurs (ß-Tests) -

Objectif

Les tests utilisateurs, encore appelés bêta-tests (ß-Tests), ont pour objet de demander à certains utilisateurs de tester eux-mêmes le prototype en conditions réelles de fonctionnement. Les bêta-tests permettent de vérifier la qualité externe du logiciel alors que les tests unitaires et d'intégration vérifient sa qualité interne.

En effet, alors que les informaticiens ont une vision plutôt technique dans les tests réalisés (tests unitaires et tests d'intégration), les utilisateurs s'attacheront à vérifier si le logiciel répond à leurs besoins en termes de fonctionnalités, de performances et de convivialité. Par ailleurs, ils auront la propension à effectuer des actions qu'un technicien n'aurait jamais réalisées car ne faisant pas partie de sa logique, et qui peuvent déboucher sur la découverte de nouvelles anomalies. Par exemple, un utilisateur pourra cliquer dans une zone de la fenêtre ou appuyer sur une touche ou une combinaison de touches qui ne présenterait aucun intérêt pour un technicien et provoquer ainsi un dysfonctionnement du logiciel.

Si les fonctions implémentées dans le prototype concernent un grand nombre d'utilisateurs, il n'est pas nécessaire qu'ils participent tous aux tests. Le choix de certains d'entre eux pourra être effectué en fonction de divers critères tels que leur disponibilité pendant la période de tests, leur degré de motivation, le niveau d'implication qu'ils peuvent avoir dans le projet ou leur position hiérarchique dans l'organisation. Nous appellerons "valideur" un utilisateur chargé d'effectuer les bêta-tests du prototype.

Les tests utilisateurs représentent une opération importante qui demande une grande disponibilité de la part de ceux qui vont y participer. Il faut donc éviter de demander à un employé déjà surchargé de travail de prendre cette tâche supplémentaire car il y a gros à parier que les délais ne seront pas respectés ou que les tests seront réalisés superficiellement. D'ailleurs, il faut se souvenir que le choix du périmètre fonctionnel de chaque prototype a été décidé en accord avec les utilisateurs en tenant compte justement de leurs disponibilités, c'est pourquoi cet aspect ne devrait pas poser trop de difficultés.

La motivation de l'utilisateur et son niveau d'implication dans le projet sont deux critères également importants car ils détermineront le sérieux avec lequel les tests se dérouleront. Afin d'apprécier ce critère, on pourra se baser sur le ressenti éprouvé lors des interviews ou des réunions ou sur l'avis donné par un responsable.

Dans la mesure où des utilisateurs appartenant à différents niveaux hiérarchiques (chef de service, cadre et personnel d'exécution par exemple) sont concernés par les fonctions livrées dans le prototype, il est bon qu'au moins une personne de chaque niveau participe aux tests afin d'obtenir des points de vue différents.

Début et durée des tests

Il faut laisser suffisamment de temps aux valideurs pour réaliser leurs tests afin qu'ils puissent explorer un maximum de cas. La durée des tests doit cependant être limitée afin de ne pas retarder la réalisation du prototype suivant dont le codage ne pourra commencer qu'après recette du prototype actuel.

Dans ce but, il est recommandé de faire coïncider la phase de tests d'un prototype N avec les phases de définition et de conception détaillée du prototype N+1. Ainsi, l'équipe projet perdra-t-elle un minimum de temps lors de la jonction entre deux prototypes successifs (cycle en spirale)
.
Le jalon limite de recette d'un prototype devra être placé avant le début de codage du prototype suivant afin que tous les sources aient pu être archivés.

Le problème existant dans cette organisation est que l'équipe projet devra mener de front à la fois les phases 1 et 2, et les corrections à apporter au prototype précédent.