LRD Drive
Une entrée orientée vers le transport avec chauffeur, les départs et destinations et la demande de réservation.
Voir la capture et sa présentationGuide pratique · Recette fonctionnelle
Tester un formulaire jusqu’à la réception de la demande
Un bouton qui affiche « envoyé » ne prouve pas que l’équipe a reçu une demande exploitable. Vérifiez la saisie, le traitement, la livraison et la réponse avec une demande de test identifiable.
Réponse directe
La réussite se vérifie dans le parcours complet.
Choisissez une personne qui teste et une personne qui surveille la réception. Convenez d’un créneau et marquez le message « TEST — aucune réservation ». Évitez les paiements réels et les données de clients pour cette recette.
Notez l’URL, l’heure, l’appareil, le résultat attendu et le résultat observé. Gardez la preuve de réception et du suivi. Une capture de l’écran de confirmation seule ne suffit pas.
1 · Saisie
Vérifier les cas normaux et les erreurs corrigibles.
Commencez sur téléphone, puis au clavier sur ordinateur. Le formulaire doit rester utilisable lorsque la personne se trompe ou prend du temps pour rédiger.
Champs vides
Soumettez sans remplir les champs obligatoires. L’erreur doit désigner le champ et expliquer la correction ; les informations déjà saisies restent présentes.
Adresse e-mail incorrecte
Essayez une adresse sans arobase, puis corrigez-la. Contrôlez le message, le focus et l’absence de succès trompeur. Une adresse syntaxiquement valide n’est pas forcément une boîte existante.
Texte réel
Utilisez des accents, une apostrophe, plusieurs paragraphes et un message proche de la limite annoncée. Contrôlez la lecture dans la boîte de réception et la conservation des retours à la ligne.
Parcours clavier
Atteignez chaque champ et le bouton avec Tab ; les libellés sont explicites, le focus visible et les erreurs accessibles. Testez aussi à fort zoom sans perdre le bouton d’envoi.
2 · Réception
Suivre la demande au-delà de la page de succès.
Le site, le serveur d’envoi et le destinataire sont trois étapes distinctes. Un message accepté par le serveur peut encore être retardé ou filtré.
Boîte de destination
Cherchez le message dans la boîte attendue, puis dans les indésirables. Comparez heure, objet et identifiant de test ; vérifiez que l’adresse de réponse correspond au testeur.
Champs utiles
Une demande liée à un bien, une chambre ou une activité doit conserver la référence concernée, les dates et les quantités. La personne chargée de répondre doit comprendre le contexte sans ouvrir plusieurs pages.
Retour au visiteur
Relisez la confirmation : elle indique réception, prochaine étape et moyen de contact alternatif. Un accusé de réception ne doit pas annoncer une table ou un séjour réservé sans validation du système ou de l’équipe.
Mesure cohérente
Comparez les demandes effectivement reçues au compteur du site. Un clic sur « Envoyer » et une demande livrée sont des événements différents. Excluez les tests des résultats commerciaux lorsque l’outil le permet.
3 · Incidents
Préparer les cas qui font perdre une demande.
Ces scénarios sont à tester sur une copie du site ou dans un environnement de test lorsqu’ils nécessitent de simuler une panne.
Session expirée
Laissez le formulaire ouvert, puis essayez d’envoyer après expiration. Le site doit expliquer comment reprendre ; proposez de copier le message avant rechargement si la saisie ne peut pas être conservée.
Double clic et retour arrière
Soumettez une fois, puis actualisez ou revenez en arrière. Vérifiez qu’aucune seconde demande ni opération n’est créée involontairement. Un identifiant de demande permet au support de retrouver un cas.
Réseau interrompu
Simulez une perte de connexion en test. Le visiteur doit savoir si l’envoi a échoué ou si son état est inconnu, et disposer d’une façon de vérifier avant de recommencer.
Échec d’envoi
En test, utilisez une configuration de livraison indisponible. L’interface doit présenter une erreur et un autre contact accessible, sans annoncer une réussite. Réactivez ensuite la configuration de test prévue.
4 · Suivi
Désigner qui reçoit, répond et vérifie à nouveau.
La recette doit devenir une routine adaptée aux changements du site et au rythme d’activité.
Responsable et relais
Nommez la personne qui surveille la réception et son relais pendant les absences. Le délai annoncé au visiteur doit correspondre à cette organisation.
Après une modification
Refaites le test après changement d’hébergement, de formulaire, de boîte destinataire ou d’outil de réservation. Testez aussi les versions linguistiques et leurs confirmations.
Journal de recette
Conservez date, page, scénario, résultat, responsable et prochaine action dans un tableau partagé. En cas de défaut, indiquez la priorité et refaites le même scénario après correction.
Confidentialité du test
Utilisez des identités et messages de test. Évitez de copier des demandes de clients dans un outil de diagnostic ; ne publiez pas les captures de boîtes de réception.
| Scénario | Résultat attendu | Preuve à conserver |
|---|---|---|
| Demande valide | Une seule demande exploitable | Message reçu avec heure et référence |
| Champ incorrect | Erreur claire et correction possible | Champ et message après soumission |
| Envoi indisponible en test | Échec expliqué et contact alternatif | Écran d’erreur sans faux succès |
| Actualisation après succès | Pas de seconde demande | Nombre de messages ou demandes créées |
Références
Sources officielles utilisées pour maintenir ce guide.
Les règles et fonctionnalités évoluent. Consultez la documentation primaire avant toute décision sensible ou modification importante d’un compte tiers.
- W3C WAINotifications des formulaires
- W3C WAIValidation des saisies
Poursuivre
Relier ce contrôle aux pages et actions complémentaires.
Besoin d’un contrôle appliqué
Transformer ce guide en priorités adaptées à votre site.
Indiquez l’adresse du site, l’activité, la commune et le parcours qui compte le plus. L’analyse distinguera les blocages, les améliorations utiles et les éléments déjà solides.
Questions fréquentes
Un message « envoyé » garantit-il la réception ?
Non. Vérifiez le message ou la demande dans le système destinataire, avec l’heure et la référence du test. L’acceptation de l’envoi par le serveur et la livraison finale sont distinctes.
Faut-il faire une vraie réservation pour tester ?
Utilisez un mode test et une demande explicitement marquée comme test. Ne déclenchez pas de paiement ou de réservation réelle sans organisation préalable avec l’établissement.
Quand refaire la recette ?
Après chaque changement qui affecte le formulaire ou sa livraison, avant une période importante et selon la fréquence de contrôle décidée par l’équipe.
Exemples du portfolio
Observer cette approche dans une réalisation
Les présentations décrivent les éléments visibles sur les captures fournies.