01. Cadrer le projet digital
Dans la vie d’un projet digital, la recette est une étape primordiale. Il existe de nombreuses variantes de tests, méthodes, bonnes pratiques, pour l'intégration, le développement, le recettage; mais savoir lesquels utiliser peut être difficile. Cet article couvrira les méthodes que nous utilisons, chez altavia.JETPULP, pour tester les applications Web, les outils pour simuler le parcours d'un utilisateur réel à travers l'application, et vérifier la bonne qualité du livrable avant de mettre en ligne et d’accueillir les utilisateurs.
Une bonne recette découle d’un bon cadrage !
Pour examiner le degré de conformité du travail produit, il va falloir le comparer aux documents de référence. Ces données se trouvent dans la commande, le backlog et/ou le plan de route présentés lors de la réunion de lancement.
De plus, au cours de la vie du projet, il est possible de mener/produire des ateliers UX ou UI, des zonings ou maquettes, des recommandations SEO, atelier d’arborescence, etc… ces livrables deviendront alors de nouvelles références. Il est donc important de vérifier la cohérence globale de l’ensemble des documents de cadrage avec ce qui a été produit.
Ainsi avec ces supports, nous allons pouvoir vérifier le bon respect des fondamentaux de la commande, fonctionnalités et attentes du client.
Pour accompagner le cadrage et la recette, il faut se doter d’un outil permettant de reporter les bugs, les annotations et remarques aux développeurs référents.
Au fil de cet article nous allons mentionner certains outils (Mantis, Redmine, Wrike, Google Sheet, Figma, Miro…) permettant d’avoir une interface dont la mécanique et logique, facilite les échanges. Il est préférable de favoriser l’un ou l'autre de ces outils suivant les étapes de la recette.
Les étapes sont divisées en 3 grandes parties: La recette interne, la recette externe et la livraison client.
02. Évaluer une production
La Recette interne
Avant de livrer un environnement de préproduction au client, il convient de vérifier la réponse aux différents besoins du client et de valider la qualité de la production. Il est à noter que cette étape doit être prévue et planifiée dès le démarrage projet.
Regardons de plus près les points de vigilance qui composent cette phase là :
#1 Examen des données de référence
C’est ce qui va nous permettre d’être sûr de sa qualité et du bon fonctionnement du produit/site. Comme cité précédemment, c’est une étape clé, pilotée par un profil testeur, qui va permettre une vigilance sur la conformité des fonctionnalités, du design et de la structure du site. Pour cela, le profil testeur utilisera un cahier de recette comportant une énumération des différents blocs html, fonctionnalités front mais aussi back, ainsi que de tous les composants constituants du projet. Il est important de noter ses remarques et points de non-conformité recensés dans un outil comme Wrike, Jira ou Google Sheet pour de l’interne (voir étape #3).
#2 Examen des URLs et Meta données du site web
Réalisé systématiquement par le consultant SEO, l’examen des liens, redirections,
Balisage Hn, règles de construction d'urls… implique un haut degré d’assiduité pour permettre au projet d’être viable et facilement identifié sur la toile. Google avec ses règles spécifiques, impose une rigueur qui touche à la fois à la structure html (pour les titres par exemple) mais aussi à celle des URLs. L’objectif principal étant que les pages soient bien indexées et optimisées afin de se positionner sur les mots-clés visés. Après l’audit du consultant, et son action sur ce qu’il est en mesure de mettre en place, le développeur aura une tâche dédiée pour le traitement des retours SEO.
#3 Évaluation des fonctionnalités et sur différentes plateformes
Ayant passé en revu l’attendu et le réel du front avec la maquette ou zoning de la page concernée, au Back avec les plugins et l’administration des différents contenus par le client, jusqu’à la structure SEO; le profil testeur va pouvoir éprouver l’application ou le site sur les supports et navigateurs web convenu dans la commande. Certains indicateurs permettent de voir si les fonctionnalités sont bien toutes présentes, en suivant une logique plus harmonieuse et interactive avec le site. Nous utilisons chez altavia.JETPULP un outil (comme BrowserStack) qui émule les différents supports du marché. Cela permet de véritablement se rendre compte de la réalité d’affichage et de la fluidité dans son parcours utilisateur.
#3.1 Simulation de l'interaction utilisateur
Le site va subir une phase d’épreuves interactives et de tests, dans laquelle nous allons nous balader et noter les freins ou imperfections rencontrés. Les images trop grandes, qui dépassent, les titres coupés au mauvais endroits, les décalages de blocs, les micro interactions qui fonctionnent… Il était difficile de simuler le comportement des utilisateurs avant cette phase de recette interne. Maintenant, tout est plus ou moins posé. Interagir avec votre application comme le ferait un utilisateur est un facteur important pour avoir des tests qui apportent de la valeur.
#3.2 Simulation des différents supports
Après avoir simuler le parcours utilisateur, il convient d’interagir avec votre application sur les plateformes les plus récentes et comprises dans la commande. En effet, des dysfonctionnements peuvent apparaître sur certains supports et pas sur d’autres, en raison des différentes technologies propres à chacun pour générer le rendu d’un site Web. Browserstack émule les devices et permet d’inspecter en live le code pour donner les informations au développeur sur ce qui ne va pas. Le profil testeur pourra alors enrichir dans l’outil de partage (type kanban) les différents points bloquants.
La livraison de préproduction
À la suite de ces étapes, le profil testeur regroupe toutes les informations et retours résultants, dans l’outil choisi pour la phase de test.
Rédaction des tickets de recette
Au moindre bug trouvé, spécifications techniques à apporter, ou autre retour, il est nécessaire de noter et empiler dans un tableau, type Kanban, les tickets de recette, pour le ou les développeurs.
Avec un système de statut, de capture d'écran, de liens hypertextes et de description du bug, le consultant qui aura la charge de s’occuper de ces tickets, pourra agir simplement, tâche par tâche, et donner de la visibilité sur son avancement à toute l’équipe projet. Il est très important d’être le plus transparent et exhaustif possible dans les explications, pour qu’il n’y ait pas besoin d’échanges supplémentaires sur la tâche à réaliser.
La planification en découlera naturellement pour estimer un temps de recette bien défini. Tout retour doit y être inscrit (pour chacune des phases de recette, de manière linéaire, avec un début et une fin) pour que le tableau de tickettage puisse servir de référentiel et ne pas accepter des retours tardifs qui déséquilibreraient la planification.
Il faudra indiquer l’évolution du recettage avec un système de statuts et un code couleur adéquat :
- À faire
- Engagé du Lot
- En cours
- À valider
- Terminé
- Validé
- En attente
Les développeurs pourront, une fois planifié, dépiler les différents retours en les traitant dans un laps de temps défini.
Une dernière vérification du profil testeur viendra cocher la conformité de chacune des tâches avant de livrer l’environnement de préproduction au client. Ce dernier indique au client que les travaux de notre côté sont finalisés et que l'environnement est prêt à être testé.
Nous indiquons les accès, points spécifiques et délai de recette au client.
La Recette externe
Le client peut maintenant, dans un temps imparti, éprouver son application avec sa connaissance métier et ses besoins. Le pilote projet aura au préalable donné les indications pour le workflow concernant les retours. Un outil dédié avec un système de statuts, de conversations et de priorisation pour gagner en vélocité est à privilégier pour encore une fois cadrer cette recette.
Nous allons voir les différentes étapes de la recette client et l'utilisation de l'outil de recette dans la section suivante.
03. Récolter - Échanger - Traiter
Une fois la pré production livrée au client, une nouvelle phase démarre avec ses enjeux : récolter les retours de recette, préciser et échanger autour de ces derniers, et les traiter.
C’est grâce à des échanges et un accompagnement du client que les retours seront au mieux quantifiés, déterminés et traités. Cela a pour but de rassurer, dans cette démarche de recette, le client et les équipes de production.
Récolter
Il ne s’agit pas que de récupérer toutes les imperfections établies par le client mais aussi de les évaluer suivant les documents de référence pour les renseigner de la manière la plus pertinente dans l’outil de traitement de recette. (Voir étape 02 > onglet #3, pour la rédaction de ticket de recette).
Des outils comme Jira, Redmine ou Mantis, permettent d’apporter les retours client dans lequel le niveau de priorité sera déterminant pour le consultant dans son traitement de ticket :
- Très faible
- Mineur
- Moyen
- Majeur
- Bloquant
Le pilote projet pourra prendre connaissance des retours clients et jauger :
- si les besoins sont de l’ordre du périmètre initial (ex : bug / feature manquante), ou
- si les attentes sont de l’ordre de l’évolution (ex : comportement additionnel à ce qui était demandé)
Ainsi il va véritablement filtrer les demandes de l’ordre de l'évolution et celles de l’ordre du dysfonctionnement qui rentre dans le cadre de la commande et donc sera traité lors de cette phase de recette externe.
Échanger
Le client peut voir l'évolution des tâches traitées ou en attente… Les outils précédemment cités, ont pour la plupart un système de commentaire qui permet d’échanger sur chacun des tickets avec le client pour demander un complément d’informations ou pour apporter des précisions.
Chaque intervenant pourra apporter des réponses.
De plus, les développeurs sont parties prenantes de ces échanges ce qui leur permettra de gagner en confiance et de s'engager sur la qualité du traitement, ce qui favorise la motivation et la satisfaction de part et d’autre.
Traiter
Tous les retours sont renseignés et précisés. L’équipe de production va pouvoir s’atteler au traitement de la recette. Chaque développeur passe de statuts en statuts les tâches qui lui sont confiées, pour remplir sa mission, s’engager sur la bonne réussite des retours traités, mais aussi donner cette visibilité au pilote projet et client.
Chez altavia.JETPULP nous vérifions le bon traitement des retours avant de permettre au client de faire ses derniers retours. L’ensemble des tickets est terminé, il est maintenant temps de finaliser le projet en faisant signer le PV de recette au client. Ce dernier assure le traitement de l’ensemble des tickets engagés lors de la recette.
04. Conclusion
En utilisant les techniques décrites dans cet article, vous pourrez créer des tests flexibles qui vous donneront un haut degré de confiance dans votre application.
Pour récapituler les principaux points :
- Arrêtez les retours au compte goutte. Centraliser, filtrer et traiter dans des temps biens répartis.
- Simulez le comportement réel des utilisateurs dans vos tests pour vous donner une plus grande confiance dans la qualité du livrable.
- Utilisez un seul outil comme source de vérité pour la récolte des retours internes, et un autre pour la récolte des retours externes.
- Utiliser une structure de projet cohérente pour les tests, les simulations et les modèles pour la maintenabilité
- Faites intervenir les référents SEO, DEV, DATA, dès la phase interne pour ne pas avoir de surprise à la livraison.
Les tests d'intégration peuvent apporter une valeur considérable aux applications Web et même enrichir le périmètre d’un gage de qualité, tout en étant indépendants de la mise en œuvre
J'ajouterai la mise en garde que toutes ces techniques n'ont pas de sens pour chaque projet. Il y aura toujours des cas d'utilisation différents, mais il y a de fortes chances que vous puissiez trouver de la valeur à partir de ces techniques, même si vous ne les utilisez pas toujours toutes.
Merci de m'avoir lu, et n'hésitez pas à me faire part de vos commentaires ou suggestions.
