Comment rédiger une documentation d'assurance qualité qui fonctionnera réellement

Un logiciel est comme un avion: il doit subir un contrôle technique avant son lancement.

L'assurance qualité est une étape nécessaire pour lancer un produit logiciel réussi. Ce n'est qu'une petite partie de tout le travail du projet, mais personne n'a dit que ce serait simple.

Il existe tellement de types de tests logiciels - automatisés et manuels, exploratoires et fonctionnels, compatibilité, UI / UX, régression, unités, API et tests de performances. Bonne chance en enveloppant votre tête autour d'eux!

Ce qui est commun à tous ces types, cependant, c'est que chacun d'entre eux vous oblige à rédiger une documentation complète sur les tests d'assurance qualité. La qualité des documents de test définit si votre travail s'avérera utile ou sera vain.

J'ai écrit cet article pour vous faciliter la vie. Le voici donc, votre guide ultime sur la façon d'écrire la documentation d'assurance qualité des logiciels qui fonctionnera.

Créer un plan de test et un rapport de progression du test

Le plan de test est un document d'orientation qui présente une vue d'ensemble du processus d'AQ et comprend une liste de tâches, une stratégie, des ressources et un calendrier.

Avant de créer un document de plan d'assurance qualité, posez-vous la question «Quel est le but de la solution logicielle?» et «Quelles fonctionnalités doivent être testées?». Ne vous précipitez pas pour tester chaque partie de votre logiciel. Vous devez décider des méthodologies, technologies et outils que vous utiliserez.

Le plan de test vous aidera à comprendre ce qui suit:

  • Quels sont les critères d'acceptation?
  • De quelles ressources avez-vous besoin? Quels systèmes d'exploitation, combien de copies et avec quelle licence? Avez-vous besoin de consultants techniques?
  • Vos rôles et responsabilités sont-ils bien définis?
  • Quels sont les délais de test?

Le rapport de progression du test est une autre partie de la documentation QA, qui est similaire au plan de test mais avec des données supplémentaires sur la progression actuelle. Ce document vous permet, ainsi qu'à votre équipe de développement, de surveiller l'avancement du projet et d'identifier les problèmes d'organisation, le cas échéant.

Plan de test et rapport

Créer des cas de test

Une fois que vous avez clarifié l'ensemble des fonctions à tester dans votre plan de test, vous devez créer un scénario de test pour chaque partie de votre logiciel.

Les cas de test sont assez simples - cette documentation QA se compose de 7 sections: ID, scénario de test, étapes de test, résultat attendu, état, résultat réel et commentaires.

  1. L'ID est un numéro unique attribué à votre scénario de test.
  2. Dans la section Cas de test , vous indiquez les exigences que vous allez tester et fournissez un lien vers celles-ci dans le document de spécifications.
  3. Dans la section Étapes de test , vous répertoriez toutes les actions nécessaires pour terminer un scénario de test.
  4. Dans la section Résultat attendu , vous résumez le résultat d'un test particulier s'il réussit.
  5. Dans la section État , vous indiquez si une étape particulière a réussi ou échoué au test.
  6. Dans la section Résultat réel , vous expliquez le résultat d'un test ayant échoué.
  7. La section Commentaires n'est pas obligatoire, mais vous pouvez l'ajouter pour laisser quelques notes supplémentaires.
Cas de test

Rédiger un rapport de défaut

Le rapport de défaut est un élément important de la documentation d'assurance qualité. Il enregistre tout problème indésirable avec votre programme. C'est un élément crucial de la documentation du projet, qui vous guide vers une solution logicielle sans bogue.

Cela semble simple, non? Oui, mais seulement jusqu'à ce que vous commenciez à documenter. Ici, vous pouvez voir un exemple de rapport de défaut typique:

Rapport de défaut

Le rapport de défaut se compose des sections suivantes: identificateur, résumé, description, étapes de reproduction, reproductibilité, gravité, priorité, environnement et pièces jointes.

  1. Chaque problème logiciel particulier se voit attribuer un numéro unique - l' identifiant . Il optimise la navigation dans les documents d'assurance qualité et facilite la communication entre les développeurs, les testeurs et les gestionnaires de projet.
  2. Dans la section récapitulative , vous fournissez une réponse concise à trois questions simples: que s'est-il passé, où et dans quelles circonstances.
  3. Dans la section de description , vous décrivez le bogue en détail. Vous devez parler des résultats réels et des résultats attendus. Il est utile de fournir un lien vers vos exigences logicielles.
  4. Ensuite, vous écrivez sur les étapes à reproduire (STR) . Cela montre aux développeurs comment reproduire exactement le problème. Ne manquez pas une étape ou votre rapport pourrait vous revenir.
  5. Dans la section reproductibilité , vous clarifiez si le bogue apparaît à chaque fois que vous suivez le STR. Vous devez utiliser des nombres pour montrer des chances approximatives, par exemple 7 fois sur 10.
  6. Dans la section gravité , vous expliquez les dommages que le bogue peut apporter au projet. En d'autres termes, il montre le degré d'influence technologique du défaut sur l'ensemble du système. Même un petit problème peut affecter gravement l'ensemble de l'application.
  7. La priorité montre à quel point un rapport de défaut particulier est important. La priorité peut être indiquée à l'aide de lettres - «A» pour le plus urgent et «Z» pour le moins urgent, des chiffres - «1» pour le plus urgent et «9» pour le moins urgent, ou simplement des mots comme «élevé »,« Moyen »ou« faible ».
  8. Dans la section environnement , vous devez définir les systèmes d'exploitation ou les versions de navigateur concernés.
  9. Enfin, les pièces jointes incluent la liste des vidéos, des captures d'écran ou des fichiers journaux de la console ajoutés au rapport de défaut.

Gardez ces conseils utiles pour la rédaction de rapports d'anomalies à l'esprit

  1. Rédigez un résumé suffisant et adéquat. Peu importe que ce soit long ou court. Ce qui compte, c'est que ce soit clair.
  2. Jetez un œil au résumé et à la description. Se ressemblent-ils à peu près? Vous devez avoir oublié de décrire les résultats attendus et réels dans la description et d'ajouter le lien vers les exigences.
  3. Capturez le problème à l'aide d'une capture d'écran. Cela peut vous faire gagner beaucoup de temps à vous et à l'équipe de développement. Parfois, un seul coup d'œil sur l'image suffit pour comprendre la situation.
  4. Avant de signaler le problème, essayez de le reproduire au moins 3 fois pour vous assurer qu'il existe.
  5. Signalez le problème dès que possible et informez votre chef de projet ou votre propriétaire de produit si le problème est majeur.
  6. Vérifiez les erreurs de grammaire dans votre documentation de contrôle qualité afin de ne pas être éliminé par la police de la grammaire.
  7. Aussi comique que cela puisse paraître, assurez-vous que le problème n'est pas une fonctionnalité - consultez à nouveau la documentation!
  8. Ne manquez aucune information importante dans vos étapes de reproduction.

Soumettre un rapport d'anomalie

Les rapports d'anomalies passent par un cycle de vie - du moment où vous signalez un problème au moment où le problème est résolu.

Cycle de vie des rapports de défauts

La première étape consiste à compiler et soumettre le rapport de défaut. À ce stade, le chef de projet ou un responsable technique décide de l' attribuer à un développeur ou de le refuser pour des raisons d'insuffisance ou d'insuffisance.

Une fois que le développeur désigné a corrigé le bogue, vous, en tant que QA, devez vérifier et vérifier qu'il a été corrigé. Si oui, vous pouvez fermer le rapport de défaut. La meilleure pratique consiste à le fermer dans une semaine ou deux.

Si le bogue n'est pas résolu, vous rouvrez le rapport d'anomalie et le renvoyez au développeur affecté. Le processus de correction des bogues peut être long, mais vous devez rester ferme jusqu'à ce que tous les rapports de défauts soient finalement fermés.

Envelopper

L'assurance qualité est un processus que vous ne pouvez tout simplement pas éviter. Chaque avion avant le départ est soumis à un contrôle technique. S'il y a un problème, l'avion est cloué au sol jusqu'à ce que le problème soit résolu.

De même, chaque produit logiciel doit être vérifié avant le lancement. Vous ne pouvez pas vous permettre de déployer un logiciel bogué car les utilisateurs ne donneront pas une seconde chance à votre application.

Avez-vous besoin d'améliorer la qualité de votre logiciel?

Mon entreprise KeenEthics fournit de solides services de développement et d'assurance qualité. Si vous avez besoin d'un devis pour un projet similaire, n'hésitez pas à nous contacter .

Si vous avez apprécié l'article, vous devriez continuer avec Qu'est-ce que le prototypage et pourquoi en avons-nous besoin et le produit minimum viable: entre une idée et le produit.

PS

L'article original publié sur le blog KeenEthics se trouve ici: Comment rédiger une documentation d'assurance qualité qui fonctionnera?