Académique Documents
Professionnel Documents
Culture Documents
Page 1 sur 18
1. Introduction ................................................................................................................................................................ 3
2. Sommaire de la stratégie globale de tests ................................................................................................................... 3
3. Environnements pour les tests .................................................................................................................................... 4
4. Les jeux d’essais : Tests reproductibles et régression ................................................................................................ 4
5. Structure des cas de tests - Un processus « top down »............................................................................................. 5
5.1 Règles fonctionnelles, un prérequis essentiel .................................................................................................... 5
5.2 Thèmes et Fonctionnalités ................................................................................................................................ 5
5.3 Domaines de tests .............................................................................................................................................. 6
5.4 Sous-domaines – Croisement des N° de cas tests avec les N° de règles ............................................................ 6
5.5 Cas cibles ........................................................................................................................................................... 6
5.6 Cas détaillés ....................................................................................................................................................... 7
5.6.1 Les prérequis .......................................................................................................................................... 7
5.6.2 Transactions à exécuter .......................................................................................................................... 7
5.6.3 Les données ............................................................................................................................................ 8
5.6.4 Résultats attendus ................................................................................................................................... 8
5.7 Jeux d’essais ...................................................................................................................................................... 8
6. Campagnes de tests .................................................................................................................................................... 9
7. Consignes générales dans la préparation de cas de tests ............................................................................................ 9
8. Conclusion................................................................................................................................................................ 10
ANNEXE – Exemples du processus de préparation de cas de tests ................................................................................. 11
A. Découpage en domaines / sous-domaines ........................................................................................................ 12
B. Cas Cibles ........................................................................................................................................................ 13
C. Prérequis et Jeux d’essais détaillés .................................................................................................................. 14
D. Cas détaillés et résultats attendus ..................................................................................................................... 16
Guide pour la préparation et l’exécution de tests fonctionnels
Page 3 sur 18
1. Introduction
Ce document se veut un guide pour aider les gestionnaires ainsi que les équipes de tests dans la préparation et l’exécution
des tests fonctionnels. Outre quelques commentaires sur la stratégie globale de tests, ce document traite exclusivement des
tests fonctionnels.
Vous n’y trouverez pas une méthodologie complète avec des modèles et des plans d’actions. Il s’agit plutôt de principes de
base, très terre à terre, qui peuvent être la fondation d’une méthodologie de tests. Ce qui est dans ce document s’applique à
n’importe quelle plateforme, domaine fonctionnel ou industrie.
Lorsque j’ai utilisé ces principes dans mon travail, en tant que gestionnaire des tests, j’avais des équipes de tests
principalement composées d’experts métiers et non pas d’informaticiens. Donc peu d’expérience en analyse structurée et en
processus de développements et de tests. C’est pour répondre à cet état de fait que j’ai originalement documenté les
principes de bases pour les tests fonctionnels TI, car si on n’a pas assimilé la base, il n’y a aucun gabarits ou modèles qui
fonctionne.
Tout ce que vous verrez ici a été mis en application avec succès dans la vraie vie, où il y a une pression constante au niveau
des délais et des coûts. Les objectifs à respecter dans l’application des ces principes sont donc : facile à assimiler,
organisation simple et mise en œuvre rapide.
En tant que gestionnaire des tests, mon équipe à réussi à diminuer le nombre d’erreurs non détectées de 90% simplement en
appliquant ces quelques principes de base.
Cas cibles
--
--
--
Les cas de tests exécutés doivent impérativement être liés à une ou plusieurs règles spécifiques. Ainsi si on change une
règle, on sait immédiatement quels sont les cas de tests affectés. A l’inverse, si on trouve une inconsistance fonctionnelle en
exécutant un cas de tests, on sait immédiatement quelles sont les règles en causes.
Il faut toujours numéroter chaque règle fonctionnelle et chaque cas de test. Ensuite, il faut s’assurer que l’on peut facilement
faire le croisement.
En tests fonctionnels on regroupe par thème et on travaille en mode boîte noire. C’est-à-dire que l’on n’utilise pas les
résultats des thèmes amont pour tester un thème aval. Les données et les fichiers d’entrées générés sont spécifiques aux tests
d’un thème en particulier.
Au niveau des fonctionnalités, sous ensemble d’un thème, on travaille en mode boîte blanche. C’est-à-dire, qu’à l’intérieur
du thème, on passe d’une fonctionnalité à l’autre en utilisant les résultats des fonctionnalités précédentes.
Sous domaines :
Sélection selon le type de pièce + DC
Sélection selon le type de client + DC
Sélection selon la date
Ici ont doit croiser les numéros de cas de tests (au niveau sous-domaines) avec les numéros de règles fonctionnelles.
Chaque sous-domaine s’éclatera ensuite en cas cibles. La numérotation des sous-domaines peut se faire par incrément de
dix sous la forme 010, 020 … Ceci facilitera l’ajout éventuel de cas.
Par exemple si on a comme domaine de test « Validation de pièces comptables » et comme sous-domaines :
- Sous-domaine N° 010 : Valider les sélections selon le type de pièce + DC
- Sous-domaine N° 020 : Validation par type de pièce + client
Guide pour la préparation et l’exécution de tests fonctionnels
Page 7 sur 18
NOTE : on prend pour acquis que la période courante est toujours ouverte
Statut de la Période Date Résultat
correspondante
ouverte = période courante période = mois de la date de pièce
< période courante période = mois de la date de pièce
> période courante période = mois de la date de pièce
fermée < période courante Erreur, pièce rejetée
> période courante Erreur, pièce rejetée
Parce que de cette façon nous arrivions à détecter les régressions immédiatement, nous avons diminué considérablement
le nombre de cycles tests/corrections tout en augmentant le niveau de qualité (beaucoup moins de régressions non
détectées).
6. Campagnes de tests
Lors des tests fonctionnels, il faut procéder à un cycle complet de tests avant de faire des corrections. Ceci permet d’obtenir
une vue d’ensemble des corrections à apporter, d’éviter le va-et-vient tests/modifications et de faciliter les tests de
régression. Ce cycle porte le nom de campagne de tests.
Une campagne correspond à :
• Une version de l’application
• Le regroupement d’une série de tests et leurs assignations à des testeurs
• Un environnement dédié pour cette campagne
• Un jeu d’essai spécifique (ou plusieurs) à charger
• Une date système
• Une fiche de résultats par testeur
A la fin de chaque campagne il faudra répertorier et regrouper les anomalies trouvées. Le responsable des tests fera alors le
suivi des corrections (programmes, règles fonctionnelles et cas de tests associés) afin de déterminer quand il sera possible de
faire une nouvelle campagne de tests.
Validation des impressions : Il faut au moins imprimer 3 pages (2 pleines + partie de la troisième). Ceci parce que
la première page est souvent différente des autres pages (en-tête, haut de page et bas de page différents). Il s’ensuit
qu’il y a des différences de code entre la page 1 et la page 2. Tant pour la page elle-même que pour la gestion des
sauts de pages. La seule façon de trouver des erreurs ou des régressions, est d’imprimer au moins 3 pages.
Traitement des erreurs. Déterminez quelles sont les erreurs possibles qui pourraient être rencontrées. Ne vous
limitez pas ici, ce genre de situation arrive fréquemment en production et c’est une excellente occasion de
découvrir ce qui arrive à votre système si quelque chose d’imprévu survient :
- Saisie de données erronées
- Repasser deux fois le même fichier batch
- Présence de données erronées dans un fichier input pour batch
- Erreur de données (dates hors phase, déphasage, etc.)
- Absence anormale de données
8. Conclusion
Comme je l’ai mentionné au début de ce document, mon équipe de tests à réussi à diminuer le nombre d’erreurs non
détectées de 90% simplement en appliquant ces quelques principes de base.
Il faut se rappeler que simple n’est pas synonyme de facile. Ce qui, avant tout, a fait la réussite des nos tests c’est la rigueur
dont a fait preuve l’équipe dans la mise en application systématique des ces principes. Même quand on était sous pression,
nous avons respecté les consignes.
Des fois on perd du temps et des fois on gagne du temps. La recette gagnante est celle où on gagne plus souvent que l’on
perd lorsque appliquée systématiquement … Faut juste avoir la discipline de bien tenir la ligne de conduite.
Guide pour la préparation et l’exécution de tests fonctionnels
Page 11 sur 18
RELEVÉS
Date de RLV dans ACTI = Date comptable dans COGEST (= Date de pièce)
010 c-rlv006-trt Relevés ayant des dates différentes
Valider le texte d’en-tête
020 c-rlv009-trt Relevés de différentes périodes de couverture
Valider le type de pièce comptable et le texte du poste client des pièces RLV
030 c-rlv007-trt Différents types de relevés
c-rlv008-trt
c-rlv014-trt
Valider le choix des clés comptables
040 c-rlv010-trt Inclure différents types de relevés selon les 4 clés comptables possibles
Valider l’enregistrement comptable dans le compte client
050 c-rlv011-trt Inclure plusieurs clients (groupes de compte différents)
Valider l’utilisation des bons comptes généraux
060 c-rlv011-trt Inclure plusieurs comptes généraux de contre partie
Valider la génération d’une contrepartie par nature comptable
070 c-rlv011-trt Inclure des cas où il y a plusieurs comptes généraux de contre partie
Vérifier l’alimentation du Critère de tri et Critères de Tri CGS dans le poste client
080 c-rlv015-trt Valider le critère de tri
c-rlv017-trt
et le critère de tri CGS
Vérifier l’alimentation de la zone spécifique « mode de versement »
090 c-rlv016-trt Inclure des relevés à modes de versement différents (cf. DAS2)
Valider l’utilisation des bons codes CGS
100 c-rlv019-trt Inclure des cas qui alimentent les codes CGS X,C,U
Valider la procédure de vérification de « non-intégration en double » dans l’interface RLV
110 d-rlv015-prg Inclure des relevés déjà traités (prévoir de découper en 2 fichiers successifs)
Vérifier le message d’anomalie d’absence de référence pour les règlements autos
120 d-rlv018-prg Inclure relevés à mode de règlements 4,5,7 n’ayant pas de références.
Vérifier l’alimentation du mode de paiement
130 c-rlv018-trt Inclure des modes de règlements différents.
Vérifier l’alimentation du mode de versement
140 c-rlv021-prg C’est le mode de versement issue de ACTI
Vérifier l’alimentation de la date différée
150 c-rlv022-prg Le calcul de cette date dépend de la condition de paiement et du mode de règlement
Vérifier la gestion du code blocage d’intérêts
160 c-rlv023-prg La sélection de ce code blocage dépend du compte général
TVA
Vérifier l’alimentation du bon code TVA sur chaque poste de ventes (compte général)
170 c-rlv012-trt Inclure plusieurs taux de TVA sur un même relevé
Vérifier qu’un même code TVA n’apparaît qu’une seule fois sur une pièce comptable (cumul)
180 d-rlv010-prg Mettre le même code TVA sur 2 comptes généraux du même RLV
Guide pour la préparation et l’exécution de tests fonctionnels
Page 13 sur 18
B. Cas Cibles
• Interface relevés
OBJECTIF / Fonctionnalité testée (Rappel)
ID test Valeurs cibles / Besoins
• Résultats attendus
Contenu du compte-rendu ‘C.R RELEVÉS’
10995 RD 1 1.302,00
Total Client 1 1.302,00 1020-1
10999 RB 1 1.302,00
RC 3 3.906,00
RD 8 21.614,00
RJ 2 617,94
RM 1 12.500,00
Total Client 15 39.939,94 1020-1