Image mise en avant pour l'article

Recette d'un projet Web : Comment la réussir ?

20 avril 2018
Stratégie Digitale
Votre projet Web vient d'être livré et vous devez le recetter ? Avant de mettre en service, vous devez vérifier que ce qui a été livré fonctionne bien et correspond à ce que vous avez demandé. C’est ce que l'on appelle la recette et elle n’est pas à négliger. Comment garantir l'efficacité et la réussite de cette étape fondamentale avant la mise en ligne ?


La recette pour un projet web est le terme consacré pour désigner la phase primordiale et néanmoins souvent maltraitée d’un projet : les tests d’acceptation. En d’autres termes, est-ce que ce qui est livré fonctionne et correspond à ce qui a été demandé ?

La recette : un moment délicat qui demande patience

Puisque tout le monde veut la même chose, la réussite du projet, ne nous fâchons pas.

ob_4c29c7_gestion-projet-web-humour
 

La recette est une opération qui doit être traitée avec sérieux, méthode et préparation. Comme elle arrive à la fin du projet, parfois avec du retard, tous les malentendus, imprécisions ou encore erreurs d’interprétation se cristallisent à ce moment.

Si on y ajoute les quelques erreurs ou anomalies qui ont échappées à la vigilance des techniciens, il n’est pas rare de voir des crispations. Celles-ci ne favorisent pas l’avancement du projet, en cela la (bonne) méthode permet d’aller au-delà.

Tout d’abord, la recette nécessite l’intervention de toutes les parties prenantes du projet. Certains peuvent ne pas se sentir concernés, il faut les convaincre du bien-fondé de la démarche pour qu’elle réussisse.

En effet, il ne s’agit pas simplement de « faire un tour de l’application » pour voir si tout va bien. Cela, les développeurs l’ont déjà fait.

Il s’agit de s’assurer que :

  • l’ensemble des fonctions métiers sont opérationnelles (utilisateurs et MOA),
  • les cas non conformes sont pris en charge (AMOA, AMOE),
  • les interfaces inter-opèrent convenablement (MOA, AMOA et MOE),
  • l’identité de l’entreprise est respectée (MOA et AMOA),
  • le backoffice est sécurisé (DSI, AMOA, AMOE),
  • et que tous les autres aspects décrits dans les spécifications ont été intégrés.

 


Il faut s'assurer que tout va bien pour la recette

 

 

Une recette préparée en amont qui construit de véritables protocoles de tests

Cette démarche doit être prise en considération dès la rédaction des spécifications fonctionnelles, voire même pendant la conception pour les fonctions sensibles du projet.

Elle s’étale alors jusqu’à la fin de la Vérification de Service Régulier (VSR), soit au minimum quelques semaines après la mise en service.

On peut découper ce travail de recette en deux étapes bien distinctes :

  • la préparation,
  • et l’exécution.

La préparation commence par la définition de la stratégie de recette, selon quelle méthode et surtout sur quel planning et par quels intervenants. Elle se poursuit par la conception des scénarios de tests et de leur préparation.

 

Prévoyez assez de temps pour la recette

 ... Sinon, en production, ce sera plus long, plus difficile et plus stressant parce qu’avec des impacts forts pour les utilisateurs.

L’exécution de la recette s’établit sur deux axes. Les tests automatisés sont pris en charge par des techniciens. Les résultats, présentés sous forme de journaux, peuvent être analysés pour identifier les problèmes.

Ce type de test est indispensable pour les fonctions métier complexes ou pour contrôler la non régression lors de mises à jour.

Les tests manuels sont pris en charge par l’AMOA et les utilisateurs. Le but est de mettre en évidence les problèmes et les axes d’amélioration en situation réelle. Les résultats sont présentés sous forme de rapport.

Dans tous les cas, les observations sont remontées dans un système de suivi – gestionnaire de tickets – permettant de les qualifier et de les prendre en charge.

Ainsi donc, la recette s’établit sur la base de tests. Pour être capable de tester une fonction il faut en identifier les cas d’usage, proposer des collections de données de tests, définir les résultats attendus et les actions consécutives.

 

La base de tests

 

Lorsque le test est automatisé, un programme ou un script est écrit pour exécuter les opérations.

Lorsqu’il est manuel, une fiche de test est rédigée pour permettre au testeur de l’exécuter selon le protocole prévu.

Certes, on peut accepter que les tests soient établis par le testeur, par exemple pour valider une mise en forme, une ergonomie ou une fonction simple. Pourtant, on prendra garde à utiliser de vraies données pour s’assurer de la vraie mesure du résultat.

En tout état de cause, la recette doit faire l’objet d’un rapport, appelé procès-verbal, qui explicite, ce qui a été testé, comment cela a été testé, les anomalies relevées et celles qui ont été corrigées. On y ajoutera les ajustements et évolutions qui ont été demandées. C’est sur la base de ce rapport que vous pourrez exprimer votre acceptation de la livraison et ainsi autoriser – ou tout au moins valider – la mise en service.

 

La terminologie de la recette

1. MOA / AMOA

Le maître d’ouvrage (MOA) est la personne ou l’entreprise qui commande le projet. L’assistant au maître d’ouvrage (AMOA) est un consultant spécialiste qui accompagne le maître d’ouvrage dans sa démarche.

 

2. MOE / AMOE

Le maître d’œuvre (MOE) est la personne ou l’entreprise qui réalise le projet. L’assistant au maître d’œuvre (AMOE) est un consultant qui accompagne le maître d’œuvre durant la réalisation du projet en particulier dans sa relation avec le maître d’ouvrage.

 

3. PV : procès-verbal

Le procès-verbal de recette concrétise le rapport d’opération d’un lot de tests du projet web. Chaque procès-verbal est soumis à validation de la MOA en vue de l’acceptation de la livraison du projet.

 

4. VABF : Vérification d’Aptitude au Bon Fonctionnement

Il s’agit de vérifier le bon fonctionnement du produit selon les spécifications fonctionnelles afin d’autoriser la mise en service.

 

5. VSR : Vérification de Service Régulier

Il s’agit de s’assurer du bon fonctionnement du produit en conditions réelles, soit sur un site pilote, soit en production. Cette période permet de porter une attention particulière au fonctionnement durant les premiers moments de vie.

 

6. TMA : Tierce Maintenance Applicative

Lorsque le produit est en exploitation, des dysfonctionnements peuvent être identifiés et des évolutions peuvent être programmées. Ces travaux sont pris en charge par un prestataire (Tiers) dans un cadre contractuel pour les maintenances corrective et évolutive, le support ou des travaux d’exploitation.

 

7. Use case ou cas d’usage

Il s’agit de la description d’une fonctionnalité selon le point de vue de l’utilisateur. La démarche permet de cerner le contexte de la fonctionnalité et surtout d’en préciser le protocole de test.

 

Les différents types de tests

Les principaux tests

  • Test unitaire : Il relève de la MOE. Il s’agit du test de bon fonctionnement d’une unité de programme, d’un module.
  • Test d’intégration : Il relève de la MOE. Il s’agit de s’assurer que des unités de programme conjointes fonctionnent correctement ensemble.
  • Test système : Il relève de la MOE. Aussi appelé test d’homologation, il s’agit de s’assurer de la validité de l’ensemble dans son environnement technique cible.
  • Test d’acceptation : Il relève de la MOA. C’est la recette fonctionnelle à proprement parler qui conduit à l’acceptation de la livraison.

Les autres types de tests

  • Test de migration : il relève de la MOE et de la MOA. Il s’agit de s’assurer que le passage d’un système à l’autre s’effectuera dans de bonnes conditions. Souvent, la migration nécessite des travaux spécifiques à n’exécuter qu’une fois.
  • Test de sécurité : Il relève de la MOE et de la DSI de la MOA. Il s’agit de s’assurer que les différentes contraintes de sécurité – données, accès, … – sont respectées.
  • Tests de charge : Il relève de la MOE et la DSI de la MOA. Il s’agit de s’assurer de la bonne tenue du produit en charge normale et en charge élevée. Des protocoles de tests automatisés sont nécessaires.
  • Test utilisateur : il relève de la MOA. Il s’agit d’observer le comportement d’utilisateurs face au produit pour préparer son évolution, ou un prototype du produit pour sa conception.
  • Test d’ergonomie : il relève de la MOA ou de la MOE. Un expert de l’ergonomie étudie celle proposée pour le produit afin de l’ajuster ou la faire évoluer. Cette démarche est souvent associée à un test utilisateur.
  • Tests d’accessibilité : il relève de la MOA ou de la MOE. Il s’agit de s’assurer que le produit peut être exploité par des utilisateurs handicapés selon les contraintes projet et la réglementation.
  • Les tests dans la méthode de développement agile

On imagine souvent que la méthode agile permet de s’affranchir des tests grâce à l’intégration continue ou parce que les tests unitaires sont écrits avant le code source lui-même.

Cela n’est vrai qu’en partie. Certes l’intégration continue évite de nombreux problèmes, de régression notamment. Et les tests unitaires, bien que très solides restent des tests unitaires.

Bien souvent, confronté à la réalité des process réels et de la production, des lacunes et des défauts se font jour.

Par exemple, si un contrôle de format est bien implémenté mais qu’il n’intervient pas au bon moment, un process de saisi peut être singulièrement remis en question.

C’est pour cela que des tests doivent être réalisés, même dans le cadre d’une méthode agile.

La conséquence de l’insertion de tests est la perte potentielle d’agilité. En effet, durant la recette d’un sprint – phase qui génère une version d’un projet agile – la version n’est pas disponible pour les utilisateurs finaux et on ne peut pas vraiment lancer le sprint suivant.

LE28099insertion20dE28099un20test20dE28099acceptation20peut20entrainer20une20perte20dE28099agiliteCC81

L’insertion d’un test d’acceptation peut entrainer une perte d’agilité.

Une méthode peut consister à gérer la recette du sprint A en parallèle du sprint B. On retrouve alors l’agilité mais on doit gérer les corrections du sprint A dans les développements du sprint B. 

Un sprint doit prendre en considération les problèmes de son prédécesseur

Un sprint doit prendre en considération les problèmes de son prédécesseur.

 

Image mise en avant pour l'article
Adimeo
Comment réussir ses tests utilisateurs ?
Télécharger le support
Vous cherchez à améliorer l'expérience utilisateur sur votre service ou produit digital ?
Nos experts en UX et UI design vous accompagnent dans votre démarche (entretiens exploratoires, focus groupes, sondages…)
Contactez-nous