Ergonomie, Rails et Architecture de l'information web (2.0)

La préparation de la phase de recette est un des moments clé de la conception du projet en ce qu’il donne l’assurance de vérifier dans les meilleures conditions possibles l’adéquation du produit fini avec les spécifications. Il s’agit aussi de la phase la plus fastidieuse et rébarbative d’un projet, et, si jamais vous rencontrez quelqu’un qui vous prétend le contraire et tente de vous démontrer par tous les moyens possibles que la qualité est un domaine absolument passionnant, engagez le, et ne le laissez jamais repartir : ces gens là sont trop rares pour qu’on les laisse échapper.

Quand rédiger les plans de test ?

Idéalement, vous rédigerez vos plans de tests dès que le client aura validé la conception, histoire de ne pas les changer du tout au tout trois fois par semaine. La tentation à éviter est d’attendre la fin des développements afin de pouvoir effectuer les tests en même temps que vous les rédigez. Comme expliqué plus haut, ils doivent permettre de contrôler l’adéquation du produit fini avec les spécifications, pas du produit fini avec le produit fini et les souvenirs du concepteur.

Pour rédiger vos plans de tests, vous aurez donc soin de fermer toutes les applications en dehors de votre traitement de textes et des spécifications fonctionnelles et techniques de l’application à tester, et c’est tout.

N’oubliez pas que ces plans de tests et les données afférentes vont devoir évoluer avec votre application au fur et à mesure des évolutions. Le cahier de recette est un document vivant qui suit parfaitement le cycle de vie de votre application.

Que mettre dans les plans de tests

Tout, évidemment, et c’est long, très long, même s’il est possible d’automatiser un certain nombre de choses.

Pour être un tant soit peu complet, vous diviserez vos tests en 3 lots :

1. Les tests unitaires.
2. Les tests fonctionnels.
3. Les scénarios d’usage de l’application.

Les tests unitaires.

Les tests unitaires vont principalement vous servir à vérifier que les inputs sont bien enregistrés en base et ressortis comme ils doivent l’être. Ce n’est pas à vous de les écrire, mais à vos équipes au fur et à mesure du développement. L’idéal est d’utiliser une méthode de développement dirigée par les tests :

1. Le développeur rédige les tests.
2. Il développe son module.
3. Il lance les tests, si ça marche, il passe à la suite.

Ces tests sont terriblement longs et fastidieux à réaliser, et c’est pour cette raison que vous devrez immédiatement les automatiser. Bien que coûteuse, l’automatisation se justifie d’elle-même par le temps gagné ensuite et l’absence d’erreur due à l’interface chaise-clavier en charge d’effectuer les tests. En fonction du langage et du framework utilisés, vous aurez à votre disposition tout un tas d’outils pour ce faire : PHPUnit, JUnit, rails::test… les solutions ne manquent pas.

Les tests fonctionnels

Plus complexes que les tests unitaires, ils ont pour but de vérifier la cohérence fonctionnelle de l’application sur de très courtes séquences en fonction des spécifications fonctionnelles de l’application.

Exemple : selon les spécifications, si l’utilisateur rentre un identifiant ou un mot de passe erroné, il est renvoyé sur l’écran d’authentification et un message d’erreur est affiché. Le test consistera donc à contrôler que c’est effectivement le cas, et que le bon message est affiché à l’écran.

Là aussi, il s’agit d’une partie très longue, et pas très rigolote ni à écrire ni à effectuer. C’est un travail de fourmi titanesque et rébarbatif qui nécessite de recommencer cent fois la même chose afin de tester tous les cas possibles, sans pour autant avancer dans l’utilisation de l’application. Mais rassurez-vous, là aussi il et possible de les automatiser, au moins en partie.

Les scénarios d’usage de l’application

Les scénarios d’usage ont ceci d’intéressant qu’ils permettent de tester le produit fini dans des conditions réelles ou quasi réelles. À travers des scénarios représentant l’utilisation quotidienne de l’application, ils permettront de :

• Vérifier que l’application fait bien ce qu’elle a à faire.
• Détecter les erreurs de conception afin de pouvoir les corriger par la suite.
• Corriger toutes les erreurs typographiques, ou de nomenclature qui auraient pu être oubliées pendant la réalisation.

Il est possible d’automatiser cette phase également, mais je ne le recommanderais pas. Au delà d’une étude purement théorique de l’enchaînement des écrans sur le papier, ce sont en effet ces scénarios qui vont permettre de tester l’utilisabilité de l’application, et constater les difficultés de prise en main que pourront rencontrer les utilisateurs finaux amenés à participer aux tests.

Qui doit passer les tests ?

En ce qui concerne les tests unitaires, c’est évidemment le développeur qui doit les passer chaque fois qu’il effectue une modification de son application. Passer les tests de parties qui n’ont pas été impactées permet de détecter les régressions sur l’application ou les effets de bord imprévus. Si des parties plus anciennes sont touchées, il faut évidemment modifier les tests en conséquence.

En fonction de l’ampleur du projet et de la durée de la recette avec le client, vous pourrez faire passer les tests fonctionnels à vos équipes internes et au client, afin de valider tous les points et enchaînements dans les détails. Même si on peut raisonnablement imaginer que le client va méticuleusement vérifier l’ensemble de ces points – et on a parfois de bonnes surprises – lui fournir les scénarios de tests fonctionnels, que ceux-ci soient automatisés ou non, assure une base de connaissance que l’on peut espérer exhaustive.

Enfin, les scénarios d’usage sont à faire passer aussi bien en recette interne qu’avec le client. Il y a d’ailleurs des chances pour qu’il se cantonne uniquement à ces derniers, donc n’hésitez pas à les détailler au maximum.
Si vous en avez l’occasion, accompagnez les utilisateurs du client dans cette phase : c’est un excellent terrain d’expérimentation de l’utilisabilité de l’application sur ses destinataires quotidiens.

Comment rédiger ses plans de tests ?

J’imagine que chacun a ses propres plans de tests, personnellement, je fais comme ça :

Chacun de mes plans de tests – tests fonctionnels et scénarios d’usage – est rassemblé sous la forme de deux classeurs OpenOffice.org, et je place un scénario, ou ensemble de scénarios par feuille. La page est en mode “paysage” et comporte 5 cases :

1. Numéro d’étape.
2. Description de l’étape : quelques mots qui me permettent de savoir vers quoi je tends.
3. Actions : l’ensemble des actions à effectuer.
4. Résultat attendu : ce que je dois obtenir à cette étape du scénario.
5. Résultat obtenu : OK ou KO.

Je mets une étape par ligne, chaque étape correspondant à une fonctionnalité ou description de résultat à valider. Ensuite, ça marche ou ça ne marche pas, et l’utilisateur coche OK ou KO et remplit le rapport de bugs. On rentre maintenant dans la phase corrective, mais ceci est une autre histoire©.