Recette d’une application métier : les tests avant livraison

La recette d’une application métier consiste à vérifier qu’elle permet de réaliser les usages attendus avant d’en accepter la livraison. Pour une TPE, commence par des critères observables, des parcours complets et des résultats notés. Une démonstration réussie par le développeur ne suffit pas à montrer que ton équipe peut travailler avec ses propres rôles et contraintes.

Ce guide propose une méthode pratique pour préparer les essais, signaler les anomalies et décider de la suite. Il complète la définition des fonctionnalités ; il ne remplace pas les vérifications techniques et de sécurité prévues pour le projet.

Définir ce qui permettra d’accepter une fonction

Avant les essais, relis le périmètre convenu et transforme les formulations vagues en résultats vérifiables. « Le suivi des dossiers fonctionne » est difficile à tester. « Un responsable peut attribuer un dossier et l’utilisateur concerné retrouve cette attribution après une nouvelle connexion » décrit un comportement observable.

Pour chaque critère, précise qui agit, les conditions de départ et le résultat attendu. Le programme Acceptance Testing de l’ISTQB met notamment en avant les critères d’acceptation et la collaboration entre acteurs métier et testeurs. La procédure proposée ici en est une application pratique adaptée à un petit projet, sans prétendre constituer une certification.

Si le périmètre reste trop large, notre guide pour choisir les fonctionnalités d’une première version aide à isoler un usage complet. Réduire le périmètre ne doit pas supprimer les protections nécessaires ou les contrôles indispensables à cet usage.

Préparer un environnement et des données de test

Note la version de l’application, l’adresse de l’environnement et les comptes utilisés. Définis les rôles à essayer : utilisateur, responsable, administrateur, ou ceux réellement prévus dans le projet. Un test effectué uniquement avec le compte qui peut tout faire masque certains problèmes.

Prépare des données fictives représentatives : dossier complet, champ vide, texte long, accents, ancien statut et association entre plusieurs objets. Évite les données confidentielles lorsque des exemples suffisent. Si des données réelles sont nécessaires, leur utilisation, leurs accès et leur suppression doivent être organisés dans un cadre adapté.

Si l’application reprend des fichiers existants, vérifie aussi les résultats de la reprise des données Excel. Un parcours peut sembler correct avec trois fiches fictives alors que les relations ou les formats de l’historique n’ont pas été validés.

Tester un parcours de bout en bout

Construis les scénarios autour du travail réel. Pour un suivi de demandes, cela peut être : créer une demande, l’attribuer, compléter les informations, changer son état puis la retrouver dans une liste. Note ce que chaque rôle peut consulter et modifier à chaque étape.

Le tableau suivant est un exemple fictif de fiche de recette. Les résultats attendus doivent être adaptés et convenus avant l’essai ; ils ne décrivent pas automatiquement les fonctions de toutes les applications.

Essayer les erreurs et les limites utiles

Un parcours normal ne couvre pas les situations qui interrompent le travail. Essaie une valeur invalide, une action répétée et un service indisponible lorsque le projet dépend d’une connexion externe. Vérifie ce que voit l’utilisateur et comment il peut reprendre.

Ne provoque pas de panne en production pour tester une hypothèse. Prépare le cas dans l’environnement convenu avec l’équipe technique. Le résultat attendu peut être un message clair, une reprise contrôlée ou un traitement manuel identifié ; il ne faut pas inventer une garantie d’absence d’erreur.

Vérifie les limites importantes pour ton usage : champ long, liste vide, recherche sans résultat, export attendu ou fichier refusé. Pour chaque essai, évite de multiplier les variations sans objectif. Commence par celles qui pourraient empêcher un travail courant ou produire des données incorrectes.

Contrôler l’utilisation avec les vrais rôles

Pour un espace réservé aux clients, prépare notamment des dossiers distincts et vérifie les refus d’accès entre clients. Notre guide du portail client pour une TPE aide à cadrer les documents, les invitations et les droits avant de rédiger ces scénarios de recette.

Fais réaliser un scénario par une personne qui utilisera l’outil. Observe si elle comprend les libellés, retrouve les actions et sait distinguer une sauvegarde réussie d’une erreur. Si l’usage sur téléphone est prévu, teste sur un appareil réel avec le navigateur concerné.

Prévois aussi un passage au clavier : ordre de navigation, repérage du champ actif et accès aux boutons. Contrôle la lisibilité des messages et l’affichage lorsque le texte est agrandi. Ces essais révèlent des difficultés concrètes, mais ne constituent pas à eux seuls un audit complet d’accessibilité.

De même, vérifier les droits dans les parcours habituels ne remplace pas un audit de sécurité. Les besoins de sécurité, de performance, de sauvegarde et de restauration doivent être traités selon le contexte et les engagements du projet.

Décrire une anomalie pour qu’elle puisse être reproduite

Un signalement utile contient la version testée, le rôle, le scénario, les étapes, le résultat attendu et le résultat observé. Ajoute une capture ou une référence de test si cela aide, sans publier de données sensibles. Indique si le problème est systématique ou observé une seule fois.

Attribue une priorité selon l’effet réel : travail bloqué, donnée incorrecte, contournement possible ou gêne d’affichage. Convenez des critères ensemble. Un défaut visuel et une perte de saisie ne demandent pas forcément la même décision, même si les deux doivent être documentés.

Après correction, rejoue le scénario initial sur la version indiquée. Vérifie ensuite les parcours proches qui pourraient avoir été affectés. Conserve le résultat du nouveau test plutôt que de fermer le signalement sur la seule annonce « c’est corrigé ».

Décider de la livraison et préparer la suite

Rassemble les scénarios exécutés, leurs résultats et les anomalies encore ouvertes. Distingue ce qui est accepté, ce qui nécessite une correction et ce qui demande un arbitrage. Une fonction non testée doit rester identifiée comme telle ; elle ne doit pas être assimilée à un résultat positif.

Consigne la décision et les réserves éventuelles dans le cadre prévu pour le projet. Identifie les responsables et les prochaines étapes. Si un problème empêche l’usage principal ou compromet les données, il faut décider explicitement d’une correction ou d’un report, plutôt que d’espérer qu’il disparaisse au lancement.

Enfin, prépare les accès, le contact de support et la prise en main. Notre méthode pour former l’équipe à un nouvel outil métier complète cette phase. Pour cadrer le développement et sa validation, consulte les prestations d’Oraxya ou présente ton processus et les usages à vérifier.