Audit d’accessibilité du tunnel d’achat : tester jusqu’au paiement
Mis à jour le · Rédaction : Plein Accès
Suivre une transaction entière
Le tunnel d’achat est un processus : un test de la page panier ne suffit pas à montrer qu’un client peut terminer sa commande. Le scénario doit relier le choix du produit à la confirmation finale. Précisez les chemins possibles : commande invitée, compte existant, création de compte ou changement d’adresse. L’auditeur doit savoir lesquels sont ouverts au public et lesquels dépendent d’une configuration particulière. Le cadre EAA et la qualification du service sont traités dans le guide e-commerce.
Préparez un environnement qui autorise les essais sans facturation ni expédition. Les références de test et les comptes temporaires doivent être fournis par le responsable de la boutique. Aucun numéro de carte réel ni dossier client ne doit être nécessaire à un premier cadrage. Si une étape ne peut être simulée, le rapport doit indiquer sa couverture réelle et la vérification complémentaire attendue.
Observer le panier et les transitions
Le panier cumule des actions : supprimer un produit, changer la quantité, utiliser un code et consulter le total. Testez chacune de ces actions puis vérifiez ce que l’utilisateur apprend après la mise à jour. Un changement visible à l’écran peut rester silencieux pour un lecteur d’écran. La position du clavier doit permettre de poursuivre le travail, sans obliger à retrouver tout le contexte après chaque action.
Prévoyez les erreurs spécifiques : quantité au-delà du stock, code refusé et produit devenu indisponible. Décrivez le message attendu et l’endroit où le client peut agir. Les frais de livraison et les totaux doivent être compréhensibles sans dépendre d’une seule mise en forme. Demandez que les constats précisent l’état du panier, car une anomalie liée à une quantité donnée peut disparaître avec les valeurs par défaut.
Tester l’identification et les adresses
Les formulaires de connexion et d’adresse doivent être examinés dans leurs états de réussite et d’échec. Vérifiez les labels, les instructions, les erreurs et les informations conservées après un refus. Un message général placé en haut peut être utile, mais il ne remplace pas une relation compréhensible avec les champs concernés. Les aides à la saisie doivent rester utilisables au clavier et ne pas masquer une partie de l’interface à fort zoom.
Les choix d’adresse et de livraison appellent également des scénarios. La sélection d’un point relais peut passer par une carte ou une fenêtre externe. Demandez comment le client repère la liste des options, choisit un lieu puis revient au processus. Le rapport doit distinguer les obstacles de chaque composant et le comportement de retour. L’équipe peut ensuite attribuer la correction au thème, au module ou au fournisseur réellement responsable.
Examiner le paiement et la confirmation
Le passage vers le paiement peut se faire dans un cadre embarqué, une nouvelle page ou un domaine externe. L’audit doit décrire la transition et ses limites. Identifiez les moyens de paiement inclus dans le test, puis les conditions nécessaires pour déclencher un refus ou une étape d’authentification. Un fournisseur doit être interrogé sur ses propres éléments lorsque votre équipe ne peut pas les corriger.
Après un paiement simulé, vérifiez la confirmation, le récapitulatif et les possibilités de retrouver la commande. Une erreur technique doit permettre au client de comprendre si l’achat a été confirmé avant de recommencer. Ces scénarios sont des recommandations de recette ; le prestataire doit les rapprocher des critères et exigences contractuels retenus. Les détails du rapport doivent permettre de reproduire l’obstacle sans réaliser une nouvelle transaction réelle.
Préparer une réception commune aux équipes
Créez une fiche par scénario : données initiales, étapes, résultat attendu et versions des modules. Ajoutez les observations au clavier et avec les technologies d’assistance prévues au contrat. Cette fiche doit servir à l’équipe de correction autant qu’à l’auditeur. Le cahier des charges précise les exigences de preuve qui rendent les offres comparables.
Lors de la recette après correction, rejouez tout le processus concerné, pas seulement le bouton modifié. Un changement de gestion du focus dans un dialogue peut modifier la progression vers l’étape suivante. Conservez également un scénario d’échec. Une commande qui réussit dans le cas idéal peut encore bloquer un client qui a besoin de corriger une adresse. Le contrôle ciblé doit être nommé comme tel s’il ne couvre pas les autres fonctions de la boutique.
Questions sur le test du paiement
Faut-il inclure tous les moyens de paiement ?
Le contrat doit nommer ceux qui sont examinés et justifier les limites. Un moyen non testé reste un point à vérifier ; il ne peut pas être présumé conforme.
Les essais au clavier remplacent-ils le lecteur d’écran ?
Ils contrôlent des aspects différents. Prévoyez les environnements et les restitutions nécessaires, notamment pour les changements d’état et les erreurs dynamiques.
Comment transmettre un défaut à un fournisseur ?
Joignez un scénario reproductible avec l’état initial, l’environnement et le résultat attendu. Retirez toute donnée de transaction ou identité réelle avant l’envoi.