Guides pratiques approfondis
Tester de la découverte à la décision : un plan de recette qui relie navigation, recherche, changement de langue, outils, formulaires et erreurs.
Mise à jour :
Touches d’un clavier portant plusieurs jeux de caractères. Photo de contexte documentaire ; elle ne représente pas une mission ou un équipement d’Alexis Roux ZG. © Alexander-design · Source · CC0. Redimensionnement et conversion WebP ; affichage recadré.
Une page traduite ne suffit pas si son menu ramène au français, si la recherche ignore ses mots ou si le formulaire produit une erreur non expliquée. La recette porte sur des tâches observables et des états complets. Elle complète le contrôle des textes et des URL en vérifiant ce que l’utilisateur peut réellement accomplir. Les situations ci-dessous sont des exemples de préparation, pas des missions déclarées.
Lister les familles de pages et leurs actions : trouver une définition, comparer des sources, ouvrir une fiche, composer une référence, calculer ou contacter. Associer à chaque tâche un départ, une destination et un résultat attendu. Inclure les pages secondaires, pas seulement les entrées du menu principal.
Prévoir état initial, contenu long, filtre actif, absence de résultat, saisie incorrecte et reprise après erreur. Utiliser des données synthétiques clairement identifiées. Pour un contact, séparer validation locale, rejet sûr côté serveur et essai de livraison explicitement autorisé : ne pas envoyer de messages réels par défaut.
Entrer par une fiche profonde et changer de langue. Vérifier conservation de l’entité, du filtre ou de la source sélectionnée lorsque c’est pertinent. Contrôler lang, direction, libellés et messages. Les canonicals et hreflang décrivent les versions équivalentes ; ils ne démontrent pas le bon fonctionnement du sélecteur.
Formuler des requêtes représentatives de chaque alphabet, avec accents, variantes et plusieurs mots. Vérifier pertinence, liens des résultats, pagination et absence de résultat. Une URL trouvée dans le sitemap peut encore être difficile à atteindre par la navigation. Tester aussi les liens connexes et le retour à la rubrique.
Utiliser les outils avec une entrée normale puis un cas limite. Comparer la sortie au résultat attendu et vérifier remise à zéro, copie ou export. Tester les formulaires au clavier et les erreurs près des champs. Distinguer les parcours qui fonctionnent sans JavaScript des fonctions qui le nécessitent et doivent l’annoncer.
Consigner attendu, observé, preuve et gravité liée à la tâche. Corriger la cause commune, rejouer le cas en échec puis les autres langues et composants concernés. Une recette validée signifie que la matrice définie passe ; elle ne permet pas d’affirmer que tous les usages et appareils possibles ont été testés.
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
Depuis une source sélectionnée, le bouton anglais mène à une fiche par défaut. Conserver le paramètre public identifiant l’entité, puis comparer les destinations des six langues. Ne pas placer des notes privées ou un brouillon dans ces URL.
Une requête accentuée ne retrouve pas la fiche pourtant présente. Vérifier normalisation et index de la langue, puis plusieurs mots, résultats et pagination. Ne pas confondre égalité de volumes et pertinence.
Après le rejet, le message est hors écran ou non associé au champ. Vérifier localisation, annonce, focus et conservation des saisies non sensibles. Rejouer la correction puis une soumission volontairement invalide sans déclencher d’envoi.
Inventorier toutes les routes et leurs langues, puis couvrir les tâches et états de chaque gabarit. Ajouter des contrôles ciblés pour les fiches ou paramètres atypiques.
Conserver le contexte public utile lorsque cela est prévu. Éviter d’inscrire dans l’URL un brouillon ou des informations sensibles ; expliquer si une action réinitialise la saisie.
Il repère des régressions reproductibles. Une revue visuelle et un parcours clavier restent nécessaires pour juger lisibilité, compréhension et ordre des actions.
Quand les critères définis sont satisfaits et les défauts restants explicitement documentés. Un défaut bloquant la tâche prioritaire doit être corrigé puis rejoué avant validation.
