Proposition d’organisation des tests

1. Structure principale

Nous vous proposons d’organiser les tests par niveaux et sous-niveaux selon les définitions que nous avons indiquées au début du présent chapitre.

Très concrètement, cela signifie que l’arborescence principale est définie comme suit :

images/05EP13.png

Nous commençons par définir un dossier spécifique aux tests unitaires. Nous rappelons cependant que nous sommes partis du principe que les développeurs n’utilisent pas QC pour formaliser cette activité.

Ce dossier est défini de manière normalisée pour une raison que nous verrons ultérieurement avec l’Agilité, dans la seconde partie de notre ouvrage.

Le second dossier a pour rôle de concentrer l’ensemble des tests des exigences Functional, donc des applications et flux du système.

Le troisième dossier regroupera les tests d’environnement des exigences Testing.

Le quatrième sera propre à deux types de tests :

  • Les tests d’intégration technique, couvrant à la fois une exigence d’un flux et celle d’une intégration de données ou un export.

  • Les tests d’intégration des processus Métier correspondant aux exigences Business Model que ce livre ne traitera pas.

Enfin, le dernier dossier permet de traiter les tests des exigences Performance.

Le lecteur comprend ici qu’à quelques nuances près, il retrouve l’exacte...

Pour consulter la suite, découvrez le livre suivant :
couv_EPALMQC.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Proposition d'une customisation des tests
Suivant
Les champs clés d'un test : les bons réflexes