Recette d’une application métier : vérifier le travail de bout en bout

Définir ce qui doit être accepté

Partez des parcours du cahier des charges : créer un dossier, le corriger, faire approuver son contenu, générer un document et le retrouver. Indiquez la version testée et les fonctionnalités incluses dans le lot. Une nouvelle idée découverte pendant la recette doit être distinguée d'un écart au fonctionnement déjà convenu.

Pour chaque parcours, nommez la personne qui connaît le résultat attendu. Le développeur peut vérifier un calcul, mais le responsable métier doit confirmer que les données et règles utilisées correspondent au travail réel. La recette gagne en précision lorsqu'elle s'appuie sur des exemples connus, préparés avant la démonstration finale.

Écrire des scénarios que l'on peut rejouer

Une fiche de test indique le rôle, l'état de départ, les actions, le résultat attendu et la preuve à conserver. Utilisez des données fictives ou anonymisées avec des valeurs suffisamment variées pour révéler les erreurs. Conservez-les dans un environnement séparé afin que la recette ne crée pas de vrais messages clients ou de documents comptabilisés.

Exemple hypothétique : un responsable prépare un rapport d'intervention, constate une pièce manquante, demande une correction puis approuve la nouvelle version. Le résultat attendu comprend le statut final, la version consultable et les accès du client. La fiche doit permettre à une autre personne de refaire ce même parcours sans explication orale.

• État initial : dossier attribué à un client et rapport encore en brouillon.
• Action : compléter le rapport, enregistrer, se déconnecter puis le rouvrir.
• Résultat attendu : valeurs conservées et brouillon visible seulement par les rôles autorisés.
• Preuve : référence du dossier d'essai, version de l'application, date et observation.

Vérifier les erreurs et les limites d'accès

Testez une donnée manquante, un fichier refusé et un enregistrement interrompu. L'application doit expliquer l'erreur et préserver ce qui peut l'être. Rejouez une action après une réponse tardive pour vérifier qu'elle ne crée pas deux dossiers ou deux envois. Les parcours d'échec sont souvent ceux qui obligent les équipes à trouver des solutions manuelles.

Utilisez aussi plusieurs comptes avec des droits différents. Un collaborateur doit accéder à ce qui lui est attribué et être refusé ailleurs. Testez un ancien lien après retrait des permissions. Les essais de droits et de données restent séparés : obtenir la bonne valeur avec un compte administrateur ne prouve pas que le client disposera du bon accès.

Contrôler les sorties et les conditions réelles d'usage

Ouvrez les PDF et les fichiers exportés. Comparez les montants, libellés, dates, sauts de page et destinataires attendus. Si une interface transmet des données à un autre outil, vérifiez le résultat reçu ou une recette dédiée à cette connexion. Une réponse serveur positive peut seulement indiquer qu'une demande a été acceptée.

Essayez les appareils et navigateurs prévus, avec un écran de téléphone et une connexion moins favorable lorsque l'usage le nécessite. Vérifiez la navigation au clavier, les libellés de champs et la visibilité des erreurs. Le W3C propose des contrôles préliminaires d'accessibilité, tout en précisant qu'ils ne constituent pas une évaluation exhaustive.

Articuler tests automatisés et observation métier

Les tests automatisés peuvent rejouer les calculs, transformations et parcours critiques après une modification. Ils rendent les régressions plus faciles à repérer. La documentation Playwright recommande notamment de vérifier les comportements visibles pour l'utilisateur et d'isoler les tests pour qu'ils restent reproductibles. Cette approche fournit une preuve ciblée, pas une garantie générale d'absence de défaut.

L'observation d'un utilisateur répond à d'autres questions : comprend-il le statut du dossier, sait-il corriger une erreur et retrouve-t-il son travail ? Gardez ces retours distincts des tests de calcul. Un parcours techniquement exact peut rester difficile à utiliser ; une interface claire peut produire un export incorrect. La recette doit traiter ces deux dimensions.

Consigner la décision et vérifier la version livrée

Le bilan de recette doit lister les scénarios exécutés, les écarts, les corrections vérifiées et les points non testés. Classez les défauts selon leur effet sur l'utilisation du lot. Un blocage de saisie ou une perte de données demande une décision différente d'un alignement visuel secondaire. Ne transformez pas automatiquement les scénarios non exécutés en succès.

Après publication, vérifiez les parcours essentiels sur la version réellement accessible. Les tests locaux ne prouvent pas à eux seuls le fonctionnement du serveur de production, de ses accès ou de ses services externes. Si une preuve manque, indiquez-la précisément et désignez la prochaine vérification. La validation finale porte sur un périmètre et une version identifiés.