Test de logiciels - Documentation
La documentation de test implique la documentation des artefacts qui doivent être développés avant ou pendant le test du logiciel.
La documentation pour les tests logiciels aide à estimer l'effort de test requis, la couverture des tests, le suivi / traçage des exigences, etc. Cette section décrit certains des artefacts documentés couramment utilisés liés aux tests logiciels tels que:
- Plan de test
- Scénario de test
- Cas de test
- Matrice de traçabilité
Plan de test
Un plan de test décrit la stratégie qui sera utilisée pour tester une application, les ressources qui seront utilisées, l'environnement de test dans lequel les tests seront effectués, ainsi que les limites des tests et le calendrier des activités de test. En général, le chef de l'équipe d'assurance qualité sera responsable de la rédaction d'un plan de test.
Un plan de test comprend les éléments suivants:
- Introduction au document du plan de test
- Hypothèses lors du test de l'application
- Liste des cas de test inclus dans le test de l'application
- Liste des fonctionnalités à tester
- Quel type d'approche utiliser lors du test du logiciel
- Liste des livrables à tester
- Les ressources allouées pour tester l'application
- Tous les risques encourus pendant le processus de test
- Un calendrier des tâches et des jalons à atteindre
Scénario de test
Il s'agit d'une instruction d'une ligne qui indique quelle zone de l'application sera testée. Des scénarios de test sont utilisés pour garantir que tous les flux de processus sont testés de bout en bout. Un domaine particulier d'une application peut avoir aussi peu qu'un scénario de test à quelques centaines de scénarios en fonction de l'ampleur et de la complexité de l'application.
Les termes «scénario de test» et «cas de test» sont utilisés de manière interchangeable, cependant un scénario de test comporte plusieurs étapes, tandis qu'un scénario de test en a une seule. Vu sous cet angle, les scénarios de test sont des cas de test, mais ils incluent plusieurs cas de test et la séquence dans laquelle ils doivent être exécutés. En dehors de cela, chaque test dépend de la sortie du test précédent.
Cas de test
Les cas de test impliquent un ensemble d'étapes, de conditions et d'entrées qui peuvent être utilisées lors de l'exécution des tâches de test. L'objectif principal de cette activité est de s'assurer qu'un logiciel réussit ou échoue en termes de fonctionnalité et d'autres aspects. Il existe de nombreux types de cas de test tels que fonctionnels, négatifs, erreurs, cas de test logiques, cas de test physiques, cas de test d'interface utilisateur, etc.
De plus, des cas de test sont écrits pour suivre la couverture de test d'un logiciel. En règle générale, aucun modèle formel ne peut être utilisé lors de l'écriture de cas de test. Cependant, les composants suivants sont toujours disponibles et inclus dans chaque cas de test -
- ID de cas de test
- Module produit
- Version de produit
- Historique des révisions
- Purpose
- Assumptions
- Pre-conditions
- Steps
- Résultat attendu
- Résultat réel
- Post-conditions
De nombreux cas de test peuvent être dérivés d'un seul scénario de test. De plus, il arrive que plusieurs scénarios de test soient écrits pour un seul logiciel, appelés collectivement suites de tests.
Matrice de traçabilité
La matrice de traçabilité (également connue sous le nom de matrice de traçabilité des exigences - RTM) est une table utilisée pour suivre les exigences au cours du cycle de vie du développement logiciel. Il peut être utilisé pour le traçage en aval (c'est-à-dire des exigences à la conception ou au codage) ou en arrière (c'est-à-dire du codage aux exigences). Il existe de nombreux modèles définis par l'utilisateur pour RTM.
Chaque exigence du document RTM est liée à son scénario de test associé afin que les tests puissent être effectués conformément aux exigences mentionnées. En outre, Bug ID est également inclus et lié à ses exigences et cas de test associés. Les principaux objectifs de cette matrice sont:
- Assurez-vous que le logiciel est développé conformément aux exigences mentionnées.
- Aide à trouver la cause première de tout bogue.
- Aide à tracer les documents développés au cours des différentes phases de SDLC.