Plan de test : comment préparer l'entrée, exécuter la tâche et vérifier le résultat
Un plan de test est un document qui décrit exactement ce qu'il faut vérifier dans un produit logiciel, quelles données fournir en entrée et quel résultat est considéré comme correct. Dans ce guide, nous allons découvrir comment utiliser l'outil « Plan de test » pour préparer des cas de réussite, d'échec et de limites significatifs. Vous apprendrez à formuler les données d'entrée, à lancer la génération et à évaluer critique le plan généré. Nous ne plongerons pas dans la théorie générale des tests, mais nous nous concentrerons sur l'utilisation pratique de l'outil spécifique. En guise d'exemple, nous considérerons un formulaire de réinitialisation de mot de passe qui envoie un lien unique par e-mail. Ce scénario est fictif et fourni à des fins illustratives.
Ouvrir l'outil: Constructeur de plan de test ↗Qu'est-ce qu'un plan de test et à quoi sert-il ?
Un plan de test est une liste structurée de vérifications à effectuer pour s'assurer du bon fonctionnement d'une fonction. Il aide à ne pas oublier les scénarios importants, surtout lorsque les tests sont effectués manuellement ou automatisés. Un bon plan comprend non seulement les cas de succès évidents, mais aussi des vérifications d'erreurs, ainsi que des valeurs limites où le comportement du système peut être inattendu.
L'outil « Plan de test » accepte en entrée une description textuelle de votre idée ou fonctionnalité et le nom de la plateforme ou de l'application. Sur la base de ces informations, il génère un plan de test avec trois catégories de cas : réussites (quand tout fonctionne comme attendu), échecs (quand le système doit correctement traiter une erreur) et limites (vérification aux limites des valeurs admissibles). Cela économise du temps pour élaborer un plan à partir de zéro et aide à repérer les zones aveugles.
Il est important de comprendre que l'outil n'exécute pas de tests et ne garantit pas que votre application fonctionne correctement. Il suggère simplement des scénarios possibles, que vous adaptez ensuite à votre système. Le résultat peut contenir des erreurs ou des inexactitudes, donc il doit toujours être vérifié manuellement.
Par exemple, pour un formulaire de réinitialisation de mot de passe, un cas réussi sera la saisie d'un email existant et la réception d'un email avec un lien. Un cas échouera la saisie d'un email inexistant ou un champ vide. Un cas limite sera un email avec la longueur maximale autorisée ou avec des caractères inhabituels mais valides.
Comment préparer les données d'entrée pour l'outil
Le premier champ - « Votre texte ou idée » - accepte jusqu'à 8000 caractères. Décrivez la fonction aussi précisément que possible : qu'elle fait, quels sont ses paramètres d'entrée, quelles sont les contraintes. Plus la description est détaillée, plus le plan sera précis. Par exemple, au lieu de « formulaire de réinitialisation de mot de passe », écrivez : « Formulaire de demande de réinitialisation de mot de passe. L'utilisateur saisit un email. Si l'email est enregistré, le système envoie un email avec un lien unique pour la réinitialisation. Le lien est valable 24 heures. Si l'email n'est pas enregistré, un message d'erreur s'affiche ». Cela donnera plus de contexte à l'outil.
Le deuxième champ - « Plateforme ou application » - jusqu'à 1000 caractères. Indiquez où la fonction fonctionne : application web, application mobile, bureau. Vous pouvez ajouter des particularités : navigateur, système d'exploitation, contraintes de temps. Par exemple : « Application web, fonctionne dans les navigateurs Chrome et Firefox, interface en russe ». Cela aidera à prendre en compte la spécificité de la plateforme dans le plan de test.
Ne chargez pas de textes importants ou de code dans le champ - l'outil n'analyse pas le code, mais travaille avec la description. Si votre fonction est complexe, divisez-la en parties et générez des plans séparés pour chacune. De plus, n'indiquez pas de données confidentielles, telles que de vrais mots de passe ou des données personnelles.
Bonnes entrées : « Formulaire de réinitialisation de mot de passe. Champ email obligatoire, vérifié sur le format. En cas de succès, un email avec un lien est envoyé, valide 24 heures. En cas d'erreur, un message s'affiche. Plateforme : web, bureau et navigateurs mobiles ».
Comment exécuter la tâche dans l'interface
L'interface de l'outil est un formulaire web avec deux champs de texte et un bouton « Générer ». Aucun curseur, presets ou paramètres supplémentaires n'existe. Choisissez la langue de sortie, si cela est prévu, saisissez la description dans le premier champ, le nom de la plateforme dans le second et cliquez sur le bouton. Le résultat apparaîtra dans un panneau séparé sous forme de texte brut.
Après la génération, vous pouvez copier le résultat ou le télécharger au format TXT. L'outil ne conserve pas l'historique, ne prend pas en charge le traitement par lots et ne s'intègre pas avec d'autres services. Si le résultat ne vous convient pas, vous pouvez modifier l'entrée et générer à nouveau. Notez que la file d'attente et la disponibilité peuvent varier, et les réponses du modèle peuvent contenir des erreurs.
N'essayez pas d'utiliser l'outil pour générer des images, de l'audio ou de la vidéo - il ne fonctionne qu'avec du texte. De plus, l'export DOCX ou PDF, l'enregistrement automatique et la publication ne sont pas disponibles. Tout ce que vous obtiendrez, c'est un fichier texte contenant un plan de test.
Saisissez dans le premier champ : « Formulaire de réinitialisation de mot de passe. L'utilisateur saisit un email. Si l'email existe, un email avec un lien unique est envoyé. Le lien est valide 24 heures. Si l'email n'existe pas, un message d'erreur s'affiche. ». Dans le second champ : « Application web, navigateurs Chrome, Firefox ». Cliquez sur Générer.
Comment vérifier le plan de test généré
En recevant le plan, lisez attentivement chaque cas. Assurez-vous que les cas de succès vérifient effectivement le comportement attendu, les cas d'échec la gestion correcte des erreurs, et les cas limites les valeurs aux limites admissibles. Par exemple, pour la réinitialisation de mot de passe, un cas limite peut être un email d'une longueur exactement de 254 caractères (longueur maximale admissible) ou un email avec des espaces au début et à la fin.
Vérifiez s'il n'y a pas de scénarios fictifs ou irréalistes dans le plan. L'outil peut proposer des vérifications qui ne concernent pas votre système. Par exemple, si votre formulaire n'a pas de captcha, et que le plan propose de vérifier son contournement, c'est superflu. Supprimez ces points ou adaptez-les à votre implémentation.
Évaluez également la complétude : tous les aspects importants de la fonction sont-ils couverts ? Si quelque chose manque, complétez le plan manuellement. Souvenez-vous que l'outil ne garantit pas la couverture de tous les risques, mais aide seulement à commencer. Le plan final doit être vérifié et approuvé par vous ou votre équipe.
Exemple de cas réussi : « Saisie d'un email existant, appui sur le bouton, réception d'un email avec un lien en moins de 5 minutes ». Échouant : « Saisie d'un email inexistant, appui sur le bouton, affichage d'un message d'erreur ». Limite : « Saisie d'un email avec la longueur maximale 254 caractères, vérification d'envoi réussi ».
Exemple : plan de test pour la réinitialisation de mot de passe
Supposons que vous ayez généré un plan pour un formulaire de réinitialisation de mot de passe. Dans les cas de succès, peuvent figurer : saisi un email enregistré, réception d'un email, passage au lien, définition d'un nouveau mot de passe. Dans les cas d'échec : saisi un email non enregistré, champ vide, format d'email incorrect, lien expiré. Dans les cas limites : email avec longueur maximale, email avec caractères plus et point, lien utilisé deux fois, demande de réinitialisation pour un email qui a déjà demandé un réinitialisation moins d'une minute auparavant.
Cet exemple est fictif et fourni à des fins de démonstration. Votre plan réel dépendra de la mise en œuvre spécifique. Par exemple, si dans votre système le lien est valide 1 heure et non 24 heures, les cas limites doivent tenir compte de cela. Si there is a limit on the number of requests per hour, ajoutez une vérification de cette limite.
Utilisez cet exemple comme modèle pour élaborer votre propre plan. Ne le copiez pas aveuglément - adaptez-le à vos conditions. L'outil peut générer des cas similaires, mais vérifiez toujours qu'ils correspondent à votre système.
Le plan généré peut ressembler à ceci : Succès : 1. Saisie d'un email existant, réception d'un email. 2. Passage au lien, changement de mot de passe. Échec : 1. Saisie d'un email non existant, erreur. 2. Email vide, erreur. Limite : 1. Email d'une longueur de 254 caractères. 2. Lien utilisé à nouveau.
Limitations de l'outil et erreurs typiques
L'outil n'est pas un remplacement d'un testeur professionnel. Il ne connaît pas les particularités de votre architecture, ne prend pas en compte la logique métier et peut proposer des cas non pertinents. Par exemple, pour un formulaire de réinitialisation de mot de passe, il peut proposer de vérifier des injections SQL, alors que vous utilisez un ORM avec des requêtes paramétrées. De tels points peuvent être ignorés ou adaptés.
Une autre limitation - absence de contexte sur votre environnement. Si vous ne précisez pas la plateforme, le plan peut être trop général. Remplissez toujours le champ « Plateforme ou application ». De plus, souvenez-vous que l'outil ne vérifie pas votre code et ne lance pas de tests - il ne génère que du texte.
Ne vous attendez pas à ce que le plan soit parfait dès la première fois. Il se peut que vous deviez générer plusieurs variantes avec différentes formulations. N'ayez pas peur de modifier le résultat manuellement. L'essentiel est d'utiliser l'outil comme assistant, et non comme source unique de vérité.
Si l'outil propose de vérifier l'entrée via Google, et que vous n'avez que email/mot de passe, supprimez ce point. Si il manque une vérification de l'expiration du lien, ajoutez-le manuellement.
Comment utiliser le résultat dans le travail
Le plan de test généré peut être sauvegardé en TXT et transmis à l'équipe de test ou utilisé comme liste de contrôle lors des tests manuels. Vous pouvez l'importer dans un système de gestion de tests s'il supporte le format texte. Mais souvenez-vous que l'outil ne s'intègre pas directement avec de tels systèmes.
Le plan peut être complété et modifié au fur et à mesure du développement du produit. Par exemple, lors de l'ajout d'une nouvelle fonction de réinitialisation de mot de passe par SMS, vous pouvez générer un plan supplémentaire pour elle. Essayez de maintenir le plan à jour pour qu'il reflète les exigences actuelles.
N'oubliez pas que le plan de test est un document vivant. Revoyez-le régulièrement, surtout après des changements dans le code ou les exigences. L'outil peut aider à créer rapidement un brouillon, mais la responsabilité finale de la qualité des tests repose sur vous.
Sauvegardez le plan dans le fichier reset_password_test_plan.txt et ajoutez-le au dépôt du projet. Lors de la prochaine mise à jour de la fonction, relancez l'outil avec la description mise à jour.
L'outil « Plan de test » aide à créer rapidement une liste structurée de vérifications pour votre fonction. L'essentiel est de préparer correctement les données d'entrée, de spécifier la plateforme et de vérifier attentivement le résultat. Ne vous y fiez pas aveuglément : adaptez les cas à votre système, complétez et modifiez. Souvenez-vous que c'est seulement un assistant, pas un remplacement du test professionnel. Utilisez l'exemple de réinitialisation de mot de passe comme point de départ pour vos propres expériences.
Ouvrir l'outil: Constructeur de plan de test ↗Les traductions de l'interface sont assistées par machine et peuvent nécessiter des améliorations.