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 !
