• 15 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 29/06/2020

Mettez en place des tests utilisateurs

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Vous avez terminé le travail sur les spécifications techniques de la solution adoptée par le COPIL. Votre responsable a donné son approbation et les équipes MOE démarrent le travail.

À partir de maintenant, il s’agit de coordonner leur travail pour faire de ce projet une réussite !

Alors, comment démarrer votre projet ?

Dans la vie d’un projet SI, il existe plusieurs concepts dont les objectifs principaux sont de garantir que les bonnes décisions ont été prises et de prouver que le résultat sera à la hauteur des attentes.
Voici quelques-uns de ces concepts les plus utilisés.

Le PoC (Proof Of Concept) 

En français, “preuve de concept”, c’est-à-dire “démonstration de la faisabilité”. On utilise un PoC dans le cadre d’un projet qui s’appuiera sur l’acquisition d’un produit du marché ou pour comparer plusieurs produits et choisir celui qui est le plus adapté au besoin de l’entreprise. Chaque solution sera installée sur une infrastructure isolée du reste de l’entreprise en mode “laboratoire”.

Le prototype 

Dans un projet de développement, le prototype permet aux futurs utilisateurs de notre solution de se prononcer sur la bonne direction (ou non) prise par le projet.
Un prototype est une version minimaliste du projet, une maquette qui pourrait ne contenir par exemple que :

  • l’écran d’accueil et la navigation (les menus) ;

  • un écran montrant une liste et le principe de filtre ;

  • un écran montrant une fiche détail.

Une fois le prototype validé, nous pourrons lancer les développements des autres composants tout en prenant en compte les retours de nos utilisateurs.

Le MVP (Minimum Viable Product)

Dans un projet géré en mode agile, c’est la toute première version qui sera livrée à vos utilisateurs, le premier sprint. Cette version contiendra un minimum de fonctionnalités, uniquement celles qui permettent au produit de fonctionner.
Les versions suivantes, quant à elles, permettront d’une part, d’ajouter de nouvelles fonctionnalités et d’autre part, d’apporter les corrections et améliorations nécessaires remontées par nos utilisateurs.

La phase pilote

Les trois principaux objectifs d’une phase pilote sont, sur un petit périmètre, de :

  • valider le processus de déploiement ;

  • valider la qualité du produit livré ;

  • accompagner et former les équipes support.

Le périmètre de notre projet “Devis vers Factures” est particulièrement important puisqu’il sera déployé dans 989 agences. Il est donc pertinent de nous appuyer sur une phase pilote. Je vous en parlerai plus longuement dans le chapitre suivant.

Définissez les scénarios de test

Même en démarrant votre projet par une phase pilote, vous souhaitez livrer la solution qui comportera le moins d’erreurs possible. Une étape indispensable est de définir des scénarios de test.

Un scénario de test est une série d’actions effectuées afin de valider le bon fonctionnement d’un cas d’emploi. Par exemple, pour un calcul de TVA, il faudra s’assurer que le résultat soit juste, quel que soit le taux de TVA choisi, mais également que l’application réagisse bien lorsque le montant hors taxe saisi ne correspond pas à un nombre. 

Afin d’être efficace, chaque scénario doit être le plus complet possible et être documenté dans le cahier de tests. Le cahier de tests est un livrable de votre projet et, comme tous les autres livrables, au même titre que votre cahier des charges technique, c’est donc un document versionné qui a vocation à être validé par le représentant du métier.

Pour définir les scénarios de tests, vous pouvez vous appuyer sur les cahiers des charges techniques et fonctionnels. Mais dans tous les cas, je vous conseille de ne pas travailler seul et d’impliquer vos utilisateurs.

Voici quelques bonnes pratiques pour un test efficace :

  • Les cas de tests doivent être simples, clairs et concis.

  • Appuyez-vous sur le cahier des charges technique pour tester l’ensemble des exigences.

  • Mettez-vous à la place de l’utilisateur final.

  • Les cas de tests sont identifiables : utilisez une référence (ID).

  • Évitez la répétition : si un test nécessite l’exécution d’un autre, rappelez son ID.

  • Pour une fonctionnalité attendue, les tests couvrent 100 % des cas. On demandera par exemple de saisir une chaîne de caractères dans une zone attendant un nombre. 

  • Les tests sont répétables et les résultats sont identiques, quel que soit l’exécutant.

  • Faites examiner votre cahier de tests par vos pairs. 

Pour chaque test effectué, enregistrez le résultat dans un tableau (1 tableau par testeur). Les testeurs sont idéalement des utilisateurs finaux, mais également des membres du support. Ce tableau contiendra a minima les informations suivantes :

  • Date et heure du test

  • Nom du testeur

  • Rôle du testeur

  • L’ID du test

  • La description du test

  • Les étapes

  • Le résultat attendu

  • Le résultat réel

  • La validité du test (OK ou KO)

  • Un commentaire pour relever les dysfonctionnements 

Un petit exemple ? Allons-y… Reprenons notre application de gestion des flux.

Notre cahier des charges dit :

Seuls les utilisateurs déclarés dans l’application et ayant un rôle défini pourront y accéder.

Nous allons donc écrire les cas de tests de connexion à l’application.

Test ID : 001 

Cas de test : Connexion à l’application DVF

Étape 1 : Exécutez l’URL : https://test.dvf-les-artisans-reunis.com

Résultat attendu : Affichage de la page de connexion de DVF

Test ID : 002

Cas de test : Connexion à l’application DVF - aucun utilisateur aucun mot de passe

Étape 0 : Si nécessaire, exécutez le test ID 001

Étape 1 : Cliquez sur le bouton “Se connecter”

Résultat attendu : Affichage d’une pop-up : Saisie du login et du mot de passe obligatoire

Étape 2 : Cliquez sur le bouton OK

Résultat attendu : Disparition de la pop-up et retour sur la page de connexion

Test ID : 003

Cas de test : Connexion à l’application DVF - User1 - aucun mot de passe

Étape 0 : Si nécessaire, exécutez le test ID 001

Étape 1 : Saisissez User1 dans login

Étape 2 : Cliquez sur le bouton “Se connecter”

Résultat attendu : Affichage d’une pop-up : Saisie du mot de passe obligatoire

Étape 2 : Cliquez sur le bouton OK

Résultat attendu : Disparition de la pop-up et retour sur la page de connexion

Test ID : 004

Cas de test : Connexion à l’application DVF - User1 - MDP User1

Étape 0 : Si nécessaire, exécutez le test ID 001

Étape 1 : Tapez le login User1, le mot de passe User1 puis cliquez sur “Se connecter”.

Résultat attendu : Affichage de la page d’erreur - L’utilisateur User1 n’est pas autorisé à utiliser cette application.

Étape 2 : Cliquez sur le bouton retour

Résultat attendu : Affichage de la page de connexion

Test ID : 005

Cas de test : Connexion à l’application DVF - Votre login - MDP Test02

Étape 0 : Si nécessaire, exécutez le test ID 001

Étape 1 : Tapez votre login, le mot de passe Test02 puis cliquez sur “Se connecter”.

Résultat attendu : Affichage de la page d’erreur - Votre mot de passe est incorrect

Étape 2 : Cliquez sur le bouton retour

Résultat attendu : Affichage de la page de connexion

Test ID : 006

Cas de test : Connexion à l’application DVF - Votre Login - MDP Votre mot de passe

Étape 0 : Si nécessaire, exécutez le test ID 001

Étape 1 : Tapez votre login et votre mot de passe puis cliquez sur “Se connecter”.

Résultats attendus : 

Affichage de la page Liste des flux

Affichage du menu : selon votre rôle 

  • Liste des flux => Tous les utilisateurs

  • Menu Administration => Pour les utilisateurs ayant le rôle ADMINISTRATEUR

  • Sous-Menu Utilisateurs => Pour les utilisateurs ayant le rôle ADMINISTRATEUR

  • Sous-Menu Rôles => Pour les utilisateurs ayant le rôle ADMINISTRATEUR 

Étape 2 : Passez votre souris sur votre avatar (en haut à droite)

Résultat attendu : Affichage d’une bulle de survol contenant :

Login : votre login

Rôle : votre rôle

Définissez les critères de validation

Vous l’avez vu : pour chacun de nos cas de tests, nous avons un ou plusieurs “Résultat(s) attendu(s)”. C’est parfois très simple (l’affichage d’une page donnée, d’un message d’erreur ou d’une pop-up), mais cela peut être aussi plus complexe comme le résultat d’un calcul ou le résultat d’un filtre. Comment vérifier que votre test est un succès ou un échec ?

Reprenons notre test ID 006 : “Connexion à l’application DVF - Votre Login - MDP Votre mot de passe”.

Selon vous, en quoi est-il incomplet ?

Le résultat attendu lors de l’affichage de la liste des flux sera différent selon que l’utilisateur a un rôle AGENCE ou non. En effet, notre cahier des charges précise que les utilisateurs AGENCE ne peuvent voir que les flux de leur agence. Il faudra donc dans ce cas préciser le nombre de lignes visibles sur cette page selon le rôle de l’utilisateur.

Concevez le jeu de tests

Pour que vos tests soient pertinents, il est nécessaire de concevoir un jeu de tests (appelé aussi jeu de données) qui reflète l’utilisation réelle de l’application concernée.

Dans notre cas, nous devons, avant de commencer les tests utilisateurs, injecter dans notre base de données :

  • Quelques utilisateurs pour chacun des rôles définis

  • Des flux pour chaque agence, à des dates différentes

  • Des flux en succès

  • Des flux en échec

  • Des flux contenant un seul devis

  • Des flux contenant plusieurs devis

  • Des devis validés

  • Des devis non validés

Bref… Notre base de données doit contenir les éléments nécessaires permettant d’exécuter nos tests.

Il sera également nécessaire de bien connaître le contenu de notre jeu de tests afin de décrire avec précision les résultats attendus.

Le choix de l’une ou l’autre de ces méthodes dépend avant tout de la volumétrie nécessaire. Dans le cas de notre projet, nous n’aurons besoin que de quelques utilisateurs avec des rôles différents et appartenant à plusieurs agences. Par ailleurs, nous aurons besoin de tester le comportement de l’application avec de nombreux devis de plusieurs agences et ayant des statuts différents. L’injection dans notre base de données de fichiers CSV sera la plus adaptée à notre besoin.

Ces fichiers CSV seront organisés de la même manière que les tables du MPD que nous avons conçu précédemment.

Il y a donc 4 fichiers CSV à injecter dans votre base de données pour avoir un jeu de tests valide :

  • Agence

  • Utilisateur

  • Utilisateur_Agence

  • Rôle

Relevez les bugs et suivez leur correction

Votre cahier de tests est finalisé, votre jeu de données également. Il est temps maintenant de solliciter vos utilisateurs pour enfin tester votre MVP.

La première chose à faire est de mettre à leur disposition un outil de suivi de bugs ou ils enregistreront, le plus précisément possible, chaque dysfonctionnement rencontré durant leurs sessions de tests.

Peu importe l’outil de ticketing dont vous disposez, l’important étant de disposer des informations suivantes :

  • Le logiciel testé

  • La version testée

  • La fonctionnalité

  • La date et l’heure

  • La description précise du dysfonctionnement

  • Le type (bug, amélioration, suggestion)

  • La fréquence (toujours, souvent, rarement, aléatoire)

  • La méthode de reproduction

  • La possibilité d’attacher des captures d’écran

  • L’estimation de la criticité (cosmétique, gênant, très gênant, bloquant) 

Ces informations vous permettront de classifier et de prioriser les corrections à inclure dans la version suivante.

En résumé

Nous nous sommes lancés dans le déploiement de votre projet en choisissant de passer par une phase pilote. Pour que cette étape soit un succès, il faut au préalable tester votre application. Pour cela, il est nécessaire de penser à tous les cas d’utilisation pour chaque fonctionnalité et de concevoir les scénarios de tests adaptés.

Pour chaque test, il faut déterminer les critères qui permettront de les valider ou non. Ensuite, vous avez besoin d’un jeu de tests, c’est-à-dire d’un environnement réaliste pour pouvoir les faire fonctionner.

Dernière étape : vous avez choisi un logiciel qui permettra de suivre et de gérer les bugs qui seront détectés par vos premiers utilisateurs.

Vous êtes prêt ! Passons à la création de votre pilote !

Exemple de certificat de réussite
Exemple de certificat de réussite