SlideShare une entreprise Scribd logo
1  sur  18
Télécharger pour lire hors ligne
Guide pour la préparation et l’exécution de tests fonctionnels
Page 1 sur 18
GUIDE POUR LA PRÉPARATION ET
L’EXÉCUTION DE TESTS
FONCTIONNELS
PAR CHRISTIAN BERGERON - cvcby@yahoo.com
Guide pour la préparation et l’exécution de tests fonctionnels
Page 2 sur 18
TABLE DES MATIÈRES
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.
2. Sommaire de la stratégie globale de tests
Dans le cycle de vie d’un projet de développement, il y a généralement 4 grandes étapes de tests :
1. Les tests unitaires, ou tests de programmation
Les tests de programmation ont, dans un premier temps, pour but de vérifier la mécanique, l’ergonomie et
la présentation des programmes.
Dans un deuxième temps on s’assure que toutes les règles sont implantées.
Dans un troisième temps, le programmeur s’assure du bon fonctionnement des interfaces, rapports &
traitements.
Le programmeur a la responsabilité d’effectuer les tests unitaires et est responsable de la qualité de ceux-
ci. Il est important de savoir que les étapes suivantes des tests prennent pour acquis qu’aucun programme
ne sera livré sans avoir été adéquatement testé unitairement. Il n’y aura donc pas de post validations des
tests unitaires.
En général le programmeur devra préparer ses propres données de test. Par contre, pour certains cas
exigeant des données plus complexes, les données seront fournies par l’équipe de tests fonctionnels.
2. Les tests fonctionnels
Il s’agit ici de tester les fonctionnalités avec la vision du concepteur. On est préoccupé par l’aspect d’un
thème fonctionnel spécifique plutôt que par l’aspect programmation ou l’aspect global de l’application.
3. Les tests intégrés ou tests de validations ou de conception
Ici on valide l’ensemble du système en fonction des processus opérationnels. L’on s’approche de la vision
de l’utilisateur et il faut donc penser en terme de cycles d’opérations, tenir compte de la séquence
d’exécution et du facteur temps (traitement de jour, de nuit, hebdo, fin de mois, etc.). Un cycle est
composé de données de bases, d’une chaîne d’opérations et d’un résultat.
Le transfert d’information entre les modules fonctionnels doit utiliser les données générées par les
fonctionnalités en amont, et par conséquent, alimenter celles qui sont en aval. Les jeux d’essais seront
donc des données de bases qui devront cheminer dans tout le processus.
Guide pour la préparation et l’exécution de tests fonctionnels
Page 4 sur 18
4. Les tests d’acceptation ou recette utilisateurs
Il s’agit ici de la recette utilisateurs, où ils valideront le produit dans son ensemble en fonction de leurs
processus réels.
A noter que le terme « tests intégrés » est utilisé différemment selon les organisations. Pour certains il signifie les tests
fonctionnels (étape 2) et pour d’autres il signifie les tests de validations (étape 3). Dans ce document, les tests intégrés
correspondent à l’étape 3.
3. Environnements pour les tests
Les tests unitaires sont faits sur l’environnement de développement. Les tests fonctionnels sont faits sur un environnement
dédié et indépendant des changements faits dans l’environnement de développement.
Au cours de l’évolution du développement, le paramétrage, les programmes et les données de bases seront appelés à
changer et à évoluer. On doit donc pouvoir les transférer d’un environnement à l’autre.
Les jeux d’essais devront pouvoir être rechargés et ré initialisés afin de permettre de refaire les mêmes tests dans les mêmes
conditions. On peut envisager de créer un environnement de référence qui contiendra tous les objets requis pour les tests
mais sur lequel aucun test ou développement ne sera fait. Ceci requiert un processus permettant de copier des jeux d’essais
entre environnements.
Il est à noter que des tests de régression seront faits suites à des corrections de programmes. Dans certains cas ces tests
devront être effectués dans les plus brefs délais. Ceci exige de pouvoir charger/initialiser un environnement d’essai
rapidement. Il faut pouvoir répondre à cette contrainte.
Il est essentiel de documenter et mettre en place un processus clair et efficace permettant les transferts entre
l’environnement de développement et celui de test.
Ceci doit être fait avant de commencer la mise en place des jeux d’essais.
4. Les jeux d’essais : Tests reproductibles et régression
Chaque fonctionnalité doit être testée dans un contexte isolé et un environnement stable et reproductible à volonté. Il faut
donc des jeux d’essais prédéterminés qui pourront être rechargés à volonté.
La préparation et la mise en place de jeux d’essais représentent un effort important. La tentation est grande de sauter cette
étape et de faire des jeux d’essais à la pièce.
Avoir un jeu d’essais stable et réutilisable permet de refaire les tests suite à des changements, avec exactement le même
environnement et les mêmes données. C’est la seule façon de s’assurer que l’on a réglé un problème sans briser autre chose
(régression suite à des corrections). Quand on utilise des jeux de données qui sont faits au fur et à mesure, il devient très
difficile de détecter les régressions. Il s’ensuit généralement une situation où, suite à plusieurs corrections de code, on
découvre un peu plus tard (des fois beaucoup plus tard) que ce qui marchait avant ne marche plus.
Bien qu’il semble plus rapide de faire des jeux de données au fur et à mesure, ceci implique qu’il faut recommencer à
chaque fois. Quand vous prenez le temps de faire des jeux spécifiques avec un processus de chargement, vous y mettez plus
de temps au début, mais ensuite il est très facile et rapide de mettre en place les jeux d’essais pour refaire une nouvelle série
de tests … et refaire il y aura.
Guide pour la préparation et l’exécution de tests fonctionnels
Page 5 sur 18
5. Structure des cas de tests - Un processus « top down »
Thèmes
Fonctionnalités
Domaines de tests (éclatement des fonctionnalités en règles et requirements)
Sous-domaine (regroupement des caractéristiques de domaines)
Cas cibles
--
--
--
5.1 Règles fonctionnelles, un prérequis essentiel
Avant toute chose, il est essentiel d’avoir l’ensemble des règles fonctionnelles. Règles que les programmeurs ont aussi
utilisées pour faire le développement et les tests unitaires.
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.
5.2 Thèmes et Fonctionnalités
• Thème : Un cycle opérationnel. Un thème est composé d’une ou plusieurs fonctionnalités
• Fonctionnalité : Sous ensemble d’un thème
Exemples :
. Liste des liens entre les thèmes et fonctionnalités
Thèmes Fonctionnalités
Paiements automatiques des relevés Interface relevés/règlements auto
Remise en banque
Effets échus/ suppression du risque
Édition journal des effets
Maj. date d'échéance d'effet
Liste des liens entre les thèmes et les fonctionnalités
Cas détaillés Jeux d’essais
Programmes de chargements
et fichiers de données
Scénarios de tests :
Prérequis
Transactions à exécuter
Données transactionnelles
Résultats attendus
Guide pour la préparation et l’exécution de tests fonctionnels
Page 6 sur 18
Règlements manuels Gestion du bordereau de remise en banque
Génération écritures
Saisie rapide règlements (espèces)
Maj. textes postes comptables
Situation de compte Gestion situation de compte
Calcul des intérêts
Génération des éléments de facturation
Liste des situations de compte
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.
5.3 Domaines de tests
Le domaine de tests est un découpage de la fonctionnalité. Il s’agit d’une caractéristique à tester, comme par exemple la
sélection des pièces comptables ou la validation du calcul de taxes. Un domaine de tests peut découler d’une règle
spécifique, de plusieurs règles regroupées, d’une réalité du métier, d’un cycle opérationnel ou tout autre critère de
regroupement pertinent à ce que l’on veut tester.
Un domaine de tests s’éclate en sous domaines.
Par exemple :
Domaine :
Sélection des pièces
Sous domaines :
Sélection selon le type de pièce + DC
Sélection selon le type de client + DC
Sélection selon la date
5.4 Sous-domaines – Croisement des N° de cas tests avec les N° de règles
Les sous-domaines sont l’éclatement des domaines de tests en caractéristiques (règles fonctionnelles spécifiques).
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.
5.5 Cas cibles
Les cas cibles sont l’éclatement des sous-domaines. C’est le dernier niveau d’éclatement. A partir de ce point, un cas cible
correspondra à un cas de test spécifique à exécuter.
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
Les cas cibles pourraient êtres :
N° TYPE DE PIÈCE DC Résultat
010-1 Valide Valide Sélectionné
010-2 Valide Invalide Non sélectionné
010-3 Invalide Valide Non sélectionné
N° TYPE DE PIÈCE CLIENT Résultat
020-1 Valide Valide Sélectionné
020-2 Valide Invalide Non sélectionné
020-3 Invalide Valide Non sélectionné
Exemple de cas cibles à partir d’une règle de gestion :
Domaine : ASSIGNATION DES PÉRIODES
Règle de gestion : L’assignation de la période est faite selon la date de la pièce.
Analyse du cas :
La date peut :
Correspondre à la période courante
Correspondre à une période précédente
Correspondre à une période postérieure
Une période précédente ou postérieure peut :
Être ouverte
Être fermée
Sous-domaine :
Valider l’assignation des périodes et l’impact de leurs statuts sur le bon fonctionnement de l’interface
Cas cibles :
NOTE : on prend pour acquis que la période courante est toujours ouverte
Statut de la Période
correspondante
Date Résultat
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
5.6 Cas détaillés
Les cas détaillés sont l’exécution des cas cibles. Il s’agit ici de traduire le cas cible en actions précises. Quelqu’un qui ne
connaît pas le sujet doit pouvoir exécuter et valider le test en suivant simplement les instructions du cas détaillé.
5.6.1 Les prérequis
Documenter les prérequis à exécuter avant de pouvoir procéder au test.
5.6.2 Transactions à exécuter
La partie traitement donne les instructions à suivre, pas à pas, pour exécuter le test. (Ex : code transaction, saisie du champ
XXXX, appel de la fonction YYYY via touche ZZZZ,…)
Guide pour la préparation et l’exécution de tests fonctionnels
Page 8 sur 18
5.6.3 Les données
Lors de l’exécution des cas de tests détaillés on détermine les données requises selon :
• Les prérequis
• Les transactions à utiliser
• Les champs à saisir
Les principaux types de données sont :
• Les données d’input
Elles sont constituées de l’ensemble des données requises à la bonne exécution du cas détaillé. On
distinguera :
• Les données prérequises pour la bonne exécution du cas détaillé
Exemples : Chargement d’une plage de clients, d’écritures comptables, de factures.
• Les données transactionnelles du jeu d’essai
Exemples : Fichier en entrée dans le cadre d’un traitement d’interface, valeurs de zones à saisir
sur un traitement transactionnel, etc.
• Les données d’output
Les données d’output constituent le résultat attendu du cas détaillé. (Ex : valeurs de zones d’une écriture
comptable générée dans la cadre du cas de test détaillé)
5.6.4 Résultats attendus
Il y a ici deux règles importantes à suivre :
- Résultat clair
- Documenter et valider le résultat global de chaque cas
• Résultat clair
Il est important dans le cas détaillé de donner le résultat attendu sans ambiguïté.
• Documenter et valider le résultat global de chaque cas
Afin de permettre une meilleure détection de la régression lors de tests, la documentation des résultats attendus doit
permettre de valider le résultat total de la transaction et non pas seulement la valeur que l’on teste. Il en découle que l’on
demande aussi au testeur de valider l’ensemble, tel que documenté.
Par exemple :
Si on teste le calcul de taxes sur une facture, dans le résultat final il faut bien indiquer « tout » ce qui sera affiché
ou imprimé sur la facture (noms, items, descriptions, montant de chaque ligne, total, etc.). De cette façon, si
quelque chose d’autre a été affectée suite à une correction de code, on le détectera … même si on ne le cherche pas.
Cette règle exige plus de travail lors de la préparation des cas de tests détaillés et a souvent été remise en question. Mais il a
été démontré, que sur l’ensemble, on sauvait énormément de temps.
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).
5.7 Jeux d’essais
Les jeux d’essais découlent des cas de tests détaillés et comprennent l’ensemble des données, prérequises et d’exécution,
nécessaires à la bonne réalisation du test. (cf. cas détaillés).
La plupart du temps, on associera au jeu d’essai un processus de chargement via des programmes ou des outils.
Guide pour la préparation et l’exécution de tests fonctionnels
Page 9 sur 18
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.
7. Consignes générales dans la préparation de cas de tests
• Utiliser un jeu de données spécifique pour chaque cas de test. Éviter les combinaisons de plusieurs cas de tests avec les
mêmes données. Ainsi la validation s’en trouve plus simple. Si l’on combine plusieurs cas sur un jeu de données, la
validation du résultat et l’analyse d’une erreur s’en trouvent plus complexes. Finalement, et c’est ce qui arrive le plus
souvent, si on doit modifier le jeu de données pour une raison quelconque on sait quoi changer et quels en sont les
impacts sans risque d’interférer avec un autre cas de test qui pourrait utiliser ce même jeu.
• Mettre des références qui permettent d’identifier uniquement chaque enregistrement et de les lier à un cas spécifique.
Comme inclure le N° du cas dans une pièce comptable ou une description de produit. S’il y a plusieurs enregistrements
pour un cas, ajouter aussi un numéro de séquence pour bien les différencier. Ceci permet de faciliter le travail de
validation et est indispensable pour permettre l’automatisation des tests.
• Utiliser une fourchette spécifique et facilement identifiable pour les tests négatifs et les items à exclure du résultat. On
peut les identifier facilement si les références commencent ou se terminent par 99. Par exemple, si pour un test de
sélection toutes les pièces rejetées on une référence qui commence par 99 on pourra rapidement les identifier si elles ont
été incluses par erreur.
• Utiliser des fourchettes de valeurs pour regrouper les données selon les thèmes. Par exemple associer une fourchette de
N° de client spécifique à chaque thème. Le but est d’isoler les tests, afin d’éviter que quelqu’un d’autres modifie vos
données lors de l’exécution des ses tests.
• Commencer par faire des tests positifs (dont le résultat attendus est un succès) simples. Procéder ensuite à des cas
positifs plus complexes. Terminer avec les tests négatifs (cas où le résultat doit générer ou détecter une erreur)
• Voici une liste non exhaustive de divers points à considérer dans l’élaboration des cas de tests :
Validations des combinaisons de règles :
- Est-ce fonctionnellement valide ?
- Même si ça ne plante pas, est-ce que ça fonctionne comme prévu au niveau fonctionnel ?
Validation des différents niveaux de sélections et d’exclusions :
- Lors d’une sélection automatique
- Lors du balayage d’un fichier
Test de sélection nulle :
- Critère de traitement qui retourne une sélection vide (ex : sélection d'un client qui n’a aucune facture)
- Traitement d’un fichier batch vide
Guide pour la préparation et l’exécution de tests fonctionnels
Page 10 sur 18
Test des cas extrêmes :
- Fourchette avec minimum plus grande que le maximum
- Valeurs autorisées
- Combinaisons inexistantes
- Valeurs nulles ou vides
- Vérifier si possible d’entrer des nombres dont une opération de totalisation sera plus grande que le
format du champ de total.
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
ANNEXE – Exemples du processus de préparation de cas de tests
Guide pour la préparation et l’exécution de tests fonctionnels
Page 12 sur 18
A. Découpage en domaines / sous-domaines
Notez ici le croisement des numéros de cas de tests avec les numéros de règles fonctionnelles
OBJECTIF / Fonctionnalité testée
ID test N° règles BESOIN
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
c-rlv008-trt
c-rlv014-trt
Différents types de relevés
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
c-rlv017-trt
Valider le critère de tri
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
En-tête pièce comptable de RLV
Date de RLV dans ACTI = Date comptable dans COGEST (= Date de pièce)
DATE COMPTABLE RESULTAT
010-1 Date RLV = Date 1 DATE DE LA PIECE CREE = DATE 1
010-2 Date RLV = Date 2 DATE DE LA PIECE CREE = DATE 2
Valider le texte d’en-tête
020 La règle de gestion s’applique à ACTI et pas à COGEST
Pour COGEST, il s’agit d’un transfert zone à zone ce qui a du être vérifié en Test Unitaire
Valider le type de pièce comptable et le texte du poste client des pièces RLV
Les types de pièces varient en fonction du type de RLV (info ACTI)
Type de pièce provenant de ACTI Texte du poste client
030-1 T1 Libellé type de pièce T1
030-2 T2 Libellé type de pièce T2
030-3 T3 LIBELLE TYPE DE PIECE T3
Poste client du RLV
Valider le choix des clés comptables
La CC varie en fonction de la présence ou non de CGS et du sens de l’écriture
ENTREE RESULTAT
MODE DE
PAIEMENT
TYPE DE PIECE SENS CODE CGS CC
040-1 Quelconque RB Débit OUI 09
040-2 Quelconque RB Crédit OUI 19
040-3 3 RC Débit OUI 09
040-4 3 RC Crédit OUI 19
040-5 4 RC Débit OUI 09
040-6 4 RC Crédit OUI 19
040-7 Autre que 3 et 4 RC Débit NON 01
040-8 Autre que 3 et 4 RC Crédit NON 11
040-9 4 Autre que RC et
RB
Débit NON 01
040-10 4 Autre que RC et
RB
Crédit NON 11
Valider l’enregistrement comptable dans le compte client
Le numéro de client est une info ACTI
Groupe de comptes : CLGO, PERS, DIVR
Groupe de compte du client N° DE COMPTE CLIENT N° DE COMPTE DU POSTE CLIENT
050-1 CLGO N1 N1
050-2 PERS N2 N2
050-3 DIVR N3 N3
Guide pour la préparation et l’exécution de tests fonctionnels
Page 14 sur 18
C. Prérequis et Jeux d’essais détaillés
• Fourchettes de valeurs utilisées
Entités Plage de valeurs Commentaires
Société RGA La société RGA est une copie de la société DPG
Lors de la copie, il faut préciser que le plan
comptable est aussi copié ; ainsi il n’est pas
nécessaire de recréer les plans comptables
Clients 10000 à 10999
Domaine d’activité 672
479
493
ROANNE
ST ETIENNE
VALENCE
• Chargement automatique des données
Séqu
enc.
Entités Fichiers d’input Script autotester Transaction/
programme
Commentaires
1. Clients IFRGA01.XLS ISRGA01 FD01
• Chargement manuel des données
Les données sont saisies dans les tables spécifiques selon la procédure suivante :
1. LANCER LA TRANSACTION SM31
2. SAISIR LE NOM DE LA TABLE A REMPLIR
3. CLIQUER SUR LE BOUTON GERER
4. L’ECRAN DE GESTION DE TABLE APPARAIT, CLIQUER SUR NOUVELLES ENTREES
5. SAISIR LES DONNEES TELLES QUE DANS LES TABLEAUX PAGE SUIVANTE
L’ensemble des tables à remplir est le suivant :
TABLE DES PARAMETRES DE REMISE EN BANQUE
Nom Libellé Type
ZADBQ Délai interne banque
ZADIN Délai interbancaire
ZABQP Priorité banque
ZADOC Délai DPG AVP accéléré
TABLE DES PARAMETRES DES CRITERES DE RECADRAGE
Nom Libellé Type
ZACAF Critère de recadrage chiffre d’affaire
ZAPAR Critères particuliers de recadrage
ZASOC Table paramétrage société arpège
Guide pour la préparation et l’exécution de tests fonctionnels
Page 15 sur 18
• Données d’exécution du test
Fichiers d’input Fichiers d’output Script autotester Transaction/
programme
Commentaire
IZRLV01 Sans Objet Sans Objet Ce fichier est copié sous :
GARLVAR1.19981201.74.672.DAT
IZRLV02 Sans Objet Sans Objet Ce fichier est copié sous :
GARLVAR1.19981202.76.493.DAT
IZRLV03 Sans Objet Sans Objet Ce fichier est copié sous :
GARLVAR1.19981203.75.479.DAT
Guide pour la préparation et l’exécution de tests fonctionnels
Page 16 sur 18
D. Cas détaillés et résultats attendus
• Interface relevés – Règlements auto (création portefeuille)
L’intégration des relevés et la génération des règlements ont été dissociés dans le paragraphe « cas cible » afin de bien isoler les règles de gestion de l’un ou l’autre des
traitements.
Ces deux traitements sont, ici, traités ensembles car dans COGEST c’est un seul programme qui intègre les relevés puis génère les règlements automatique.
PROCÉDURE DE TEST
Intégration du fichier IZRLV01 : 1er fichier de relevés
010-1
010-2
030-1
030-2
030-3
050-1
050-2
050-3
090-1
090-2
090-3
090-4
090-5
100-1
100-2
100-3
100-4
1020-1
1020-2
Lancement de l’exécution du programme
Lancer la transaction « SE38 »
Indiquer le nom du programme ZAJOUHLP
Appuyer sur le bouton EXÉCUTER
Passage à l’écran de saisie des paramètres de sélection
COGEST : Programme d’aide à la mise en place de la journalisation
Saisie des paramètres de sélection :
Nom du programme d’interface : ZARLVB01
Nom de la variante d’interface : V_ZARLVB01_672
DC : 672
Date de traitement : 01.12.1998
Appuyer sur le bouton EXÉCUTER
Lancer la transaction « SE38 »
Indiquer le nom du programme ZARLVB01
Appuyer sur le bouton EXÉCUTER AVEC VARIANTE
Affichage de la fenêtre de choix de la variante
Sélectionner la variante : V_ZARLVB01_672
Appuyer sur le bouton EXÉCUTER
Passage à l’écran : COGEST – Interface relevés et règlement
automatique
Modifier la société:
Société : RGA
Dans le menu : ‘Programme / Exéc. Arrière plan’
Passage à l’écran de sélection des paramètres d’impression batch
Décocher les options suivantes :
Impression immédiate
Supprimer après édition
Appuyer sur le bouton ‘SAUVEGARDE’
Suivi de l’exécution du job lancé en arrière-plan
Lancer la transaction « SM37 »
Saisie des paramètres de sélection :
Nom du job : ZARLVB01
Appuyer sur ‘ENTER’
Passage à l’écran de synthèse des jobs
Appuyer sur ‘ACTUALISER’ jusqu’à ce que le statut du job soit ‘Terminé’
Guide pour la préparation et l’exécution de tests fonctionnels
Page 17 sur 18
Vérification des données dans les comptes-rendus
Lancer la transaction « SP01 »
Vérifier que la zone « N° d’ordre spool » est vide
Appuyer sur ‘ENTER’
Visualisation des ordres spool
Le programme précédent a généré 3 états :
C.R Règlements
C.R
C.R Relevés
Sélectionner le ‘C.R’
Appuyer sur ‘ AFFICHER ‘
Vérifier le total des relevés intégrés pour l’établissement :
Nombre de relevé lus dans le fichier 17
Nombre de relevés générés 17
Nombre de règlements générés 1
Nombre de relevés non traités 0
Sélectionner le ‘C.R RELEVÉS
Appuyer sur ‘ AFFICHER ‘
Vérifier l’ensemble des données en comparaison du tableau des
résultats ci-dessous
Lancement de l’exécution du dossier Batch-Input
Lancer la transaction « SM35 »
Saisie des paramètres de sélection :
Nom de dossier : ARLV01*
Appuyer sur ‘ENTER’
Accès à l’écran « Batch input : synthèse des dossiers »
Dans la rubrique ‘Dossier restant à traiter’ :
Nom de dossier : ARLV01JJHHMM
Transaction :
Double cliquer sur le Dossier
Sélectionner le Mode exécution « Arrière-plan »
Appuyer sur ‘EXÉCUTER
Affichage du message ‘1 dossier transféré en arrière plan’
Appuyer sur ‘ENTER’ pour actualiser l’affichage
Lorsque la rubrique ‘Dossier traité’ apparaît
Appuyer sur ‘PROTOCOL’
Reprendre le n° des pièces comptabilisées (créées) dans RGA
Vérifier :
Le nombre de transactions lues : 18
Le nombre de transactions traitées : 18
Le nombre de transaction erronées : 0
Le nombre de transactions supprimées : 0
Guide pour la préparation et l’exécution de tests fonctionnels
Page 18 sur 18
• Résultats attendus
Contenu du compte-rendu ‘C.R RELEVÉS’
Etab. Client Type Nbre. Montant Test
672 10993 RD 1 1.302,00
Total Client 1 1.302,00 1020-1
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
Total etab. Par relevé
RD 10 24.218,00 1020-2
RB 1 1.302,00 1020-2
RC 3 3.906,00 1020-2
RJ 2 617,94 1020-2
RM 1 12.500,00 1020-2
Total Établissement 17 42.543,94 1020-2

Contenu connexe

Tendances

Stratégie de tests type
Stratégie de tests typeStratégie de tests type
Stratégie de tests typemadspock
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxNicolas Fédou
 
Présentation Agile Testing
Présentation Agile TestingPrésentation Agile Testing
Présentation Agile Testingjubehr
 
JFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à ZJFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à ZCedric GAUTIER
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1Christophe Rochefolle
 
Méthodologie de tests et qualité
Méthodologie de tests et qualitéMéthodologie de tests et qualité
Méthodologie de tests et qualitéSpikeeLabs
 
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonEmeline Simon
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de testsSabrine MASTOURA
 
Exigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logicielsExigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logicielsPierre
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Sylvain Leroy
 
20100608 2 - TNR automatisés (Generali)
20100608 2 - TNR automatisés (Generali)20100608 2 - TNR automatisés (Generali)
20100608 2 - TNR automatisés (Generali)LeClubQualiteLogicielle
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitésoregh
 
Métriques de qualité logicielle
Métriques de qualité logicielleMétriques de qualité logicielle
Métriques de qualité logicielleYouness Boukouchi
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel Esaie88
 
Assurance Qualité logicielle
Assurance Qualité logicielleAssurance Qualité logicielle
Assurance Qualité logicielleSylvain Leroy
 

Tendances (20)

Stratégie de tests type
Stratégie de tests typeStratégie de tests type
Stratégie de tests type
 
Strategie de test à agile tour bordeaux
Strategie de test à agile tour bordeauxStrategie de test à agile tour bordeaux
Strategie de test à agile tour bordeaux
 
Présentation Agile Testing
Présentation Agile TestingPrésentation Agile Testing
Présentation Agile Testing
 
JFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à ZJFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à Z
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Méthodologie de tests et qualité
Méthodologie de tests et qualitéMéthodologie de tests et qualité
Méthodologie de tests et qualité
 
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
 
Types de tests vs techniques de tests
Types de tests vs techniques de testsTypes de tests vs techniques de tests
Types de tests vs techniques de tests
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
 
Exigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logicielsExigences de qualité des systèmes / logiciels
Exigences de qualité des systèmes / logiciels
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)
 
20100608 2 - TNR automatisés (Generali)
20100608 2 - TNR automatisés (Generali)20100608 2 - TNR automatisés (Generali)
20100608 2 - TNR automatisés (Generali)
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
 
Ingénierie du test 0.9
Ingénierie du test 0.9Ingénierie du test 0.9
Ingénierie du test 0.9
 
Métriques de qualité logicielle
Métriques de qualité logicielleMétriques de qualité logicielle
Métriques de qualité logicielle
 
Qualite1
Qualite1Qualite1
Qualite1
 
Cours1.pptx
Cours1.pptxCours1.pptx
Cours1.pptx
 
Exposée: Processus de test logiciel
Exposée:  Processus de test logiciel Exposée:  Processus de test logiciel
Exposée: Processus de test logiciel
 
Assurance Qualité logicielle
Assurance Qualité logicielleAssurance Qualité logicielle
Assurance Qualité logicielle
 

En vedette

Arret de cedh_association_les_temoins_de_jehovah_c_france
Arret de cedh_association_les_temoins_de_jehovah_c_franceArret de cedh_association_les_temoins_de_jehovah_c_france
Arret de cedh_association_les_temoins_de_jehovah_c_franceourbothy
 
Balade en suisse
Balade en suisseBalade en suisse
Balade en suissefilipj2000
 
les opportunités du web mobile
les opportunités du web mobileles opportunités du web mobile
les opportunités du web mobilesdistasi
 
4 raisons de maintenir votre page facebook
4 raisons de maintenir votre page facebook4 raisons de maintenir votre page facebook
4 raisons de maintenir votre page facebookFrederic Gonzalo
 
Rutas estaticasenpackettracer
Rutas estaticasenpackettracerRutas estaticasenpackettracer
Rutas estaticasenpackettracerJavier Guaman
 
Faire le pont entre designers et développeurs avec Sass au Guardian
Faire le pont entre designers et développeurs avec Sass au GuardianFaire le pont entre designers et développeurs avec Sass au Guardian
Faire le pont entre designers et développeurs avec Sass au GuardianKaelig Deloumeau-Prigent
 
My-e-book – Développer votre image numérique
My-e-book – Développer votre image numériqueMy-e-book – Développer votre image numérique
My-e-book – Développer votre image numériqueAlexandre Bouvard
 
Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)
Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)
Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)Pauline Moirez
 
Fontainesenmusique
FontainesenmusiqueFontainesenmusique
Fontainesenmusiquefilipj2000
 
Principales Personajes de la Segunda Guerra Mundial
Principales Personajes de la Segunda Guerra MundialPrincipales Personajes de la Segunda Guerra Mundial
Principales Personajes de la Segunda Guerra Mundialdanielaesgo
 
Desfragmentación - Cookies - Archivos temporales.
Desfragmentación - Cookies - Archivos temporales.Desfragmentación - Cookies - Archivos temporales.
Desfragmentación - Cookies - Archivos temporales.a_dam_
 
Yourprezi losdaniels
Yourprezi losdanielsYourprezi losdaniels
Yourprezi losdanielsEsa Silv:3
 
Les meilleures photos_journalistiques_de_
Les meilleures photos_journalistiques_de_Les meilleures photos_journalistiques_de_
Les meilleures photos_journalistiques_de_filipj2000
 

En vedette (20)

Modèle cas d'utilisation
Modèle cas d'utilisationModèle cas d'utilisation
Modèle cas d'utilisation
 
Présentation banc_ test
Présentation banc_ testPrésentation banc_ test
Présentation banc_ test
 
Arret de cedh_association_les_temoins_de_jehovah_c_france
Arret de cedh_association_les_temoins_de_jehovah_c_franceArret de cedh_association_les_temoins_de_jehovah_c_france
Arret de cedh_association_les_temoins_de_jehovah_c_france
 
Balade en suisse
Balade en suisseBalade en suisse
Balade en suisse
 
Abraham
AbrahamAbraham
Abraham
 
les opportunités du web mobile
les opportunités du web mobileles opportunités du web mobile
les opportunités du web mobile
 
4 raisons de maintenir votre page facebook
4 raisons de maintenir votre page facebook4 raisons de maintenir votre page facebook
4 raisons de maintenir votre page facebook
 
apple
appleapple
apple
 
Tour du monde
Tour du mondeTour du monde
Tour du monde
 
Reglamento de Biblioteca
Reglamento de BibliotecaReglamento de Biblioteca
Reglamento de Biblioteca
 
Rutas estaticasenpackettracer
Rutas estaticasenpackettracerRutas estaticasenpackettracer
Rutas estaticasenpackettracer
 
Faire le pont entre designers et développeurs avec Sass au Guardian
Faire le pont entre designers et développeurs avec Sass au GuardianFaire le pont entre designers et développeurs avec Sass au Guardian
Faire le pont entre designers et développeurs avec Sass au Guardian
 
My-e-book – Développer votre image numérique
My-e-book – Développer votre image numériqueMy-e-book – Développer votre image numérique
My-e-book – Développer votre image numérique
 
Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)
Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)
Réseaux et médias sociaux (Biblioquest Saison 2 - Episode 1)
 
RSS.
RSS.RSS.
RSS.
 
Fontainesenmusique
FontainesenmusiqueFontainesenmusique
Fontainesenmusique
 
Principales Personajes de la Segunda Guerra Mundial
Principales Personajes de la Segunda Guerra MundialPrincipales Personajes de la Segunda Guerra Mundial
Principales Personajes de la Segunda Guerra Mundial
 
Desfragmentación - Cookies - Archivos temporales.
Desfragmentación - Cookies - Archivos temporales.Desfragmentación - Cookies - Archivos temporales.
Desfragmentación - Cookies - Archivos temporales.
 
Yourprezi losdaniels
Yourprezi losdanielsYourprezi losdaniels
Yourprezi losdaniels
 
Les meilleures photos_journalistiques_de_
Les meilleures photos_journalistiques_de_Les meilleures photos_journalistiques_de_
Les meilleures photos_journalistiques_de_
 

Similaire à Guide tests fonctionnels

Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logicielsAccélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logicielskalistick
 
Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1SQLI
 
Presentation tests d'acceptations automatisés sug v1.1
Presentation tests d'acceptations automatisés sug v1.1Presentation tests d'acceptations automatisés sug v1.1
Presentation tests d'acceptations automatisés sug v1.1Jean-Emmanuel Houdu
 
Neolians testing offer
Neolians testing offerNeolians testing offer
Neolians testing offerryad_o
 
Projets d'évolution ERP
Projets d'évolution ERPProjets d'évolution ERP
Projets d'évolution ERPpanayaofficial
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesCaroline de Villèle
 
cours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.pptcours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.pptFatiMa243348
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsCloudNetCare
 
Article de référence de Winston Royce
Article de référence de Winston RoyceArticle de référence de Winston Royce
Article de référence de Winston RoyceFabrice Aimetti
 
Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0
Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0
Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0CERTyou Formation
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileDenis Voituron
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_finalagnes_crepet
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2Christophe Rochefolle
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptxZALIMAZA
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptxZALIMAZA
 
presentation Zest au JFTL 2014
presentation Zest au JFTL 2014presentation Zest au JFTL 2014
presentation Zest au JFTL 2014Laurent PY
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxZALIMAZA
 

Similaire à Guide tests fonctionnels (20)

Accélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logicielsAccélérer les tests et la validation de logiciels
Accélérer les tests et la validation de logiciels
 
Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1Tra optimiser preparation_tests_v1
Tra optimiser preparation_tests_v1
 
Presentation tests d'acceptations automatisés sug v1.1
Presentation tests d'acceptations automatisés sug v1.1Presentation tests d'acceptations automatisés sug v1.1
Presentation tests d'acceptations automatisés sug v1.1
 
Neolians testing offer
Neolians testing offerNeolians testing offer
Neolians testing offer
 
Projets d'évolution ERP
Projets d'évolution ERPProjets d'évolution ERP
Projets d'évolution ERP
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
 
Bonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigencesBonnes pratiques : la hiérarchie des exigences
Bonnes pratiques : la hiérarchie des exigences
 
cours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.pptcours-gratuit.com--id-12146.ppt
cours-gratuit.com--id-12146.ppt
 
Up1
Up1Up1
Up1
 
Avis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests LogicielsAvis d'expert : Les Tests Logiciels
Avis d'expert : Les Tests Logiciels
 
Article de référence de Winston Royce
Article de référence de Winston RoyceArticle de référence de Winston Royce
Article de référence de Winston Royce
 
Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0
Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0
Rt273 g formation-test-management-with-ibm-rational-quality-manager-v4-0
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Testeur agile mhc
Testeur agile   mhcTesteur agile   mhc
Testeur agile mhc
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptx
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptx
 
presentation Zest au JFTL 2014
presentation Zest au JFTL 2014presentation Zest au JFTL 2014
presentation Zest au JFTL 2014
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptx
 

Guide tests fonctionnels

  • 1. Guide pour la préparation et l’exécution de tests fonctionnels Page 1 sur 18 GUIDE POUR LA PRÉPARATION ET L’EXÉCUTION DE TESTS FONCTIONNELS PAR CHRISTIAN BERGERON - cvcby@yahoo.com
  • 2. Guide pour la préparation et l’exécution de tests fonctionnels Page 2 sur 18 TABLE DES MATIÈRES 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
  • 3. 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. 2. Sommaire de la stratégie globale de tests Dans le cycle de vie d’un projet de développement, il y a généralement 4 grandes étapes de tests : 1. Les tests unitaires, ou tests de programmation Les tests de programmation ont, dans un premier temps, pour but de vérifier la mécanique, l’ergonomie et la présentation des programmes. Dans un deuxième temps on s’assure que toutes les règles sont implantées. Dans un troisième temps, le programmeur s’assure du bon fonctionnement des interfaces, rapports & traitements. Le programmeur a la responsabilité d’effectuer les tests unitaires et est responsable de la qualité de ceux- ci. Il est important de savoir que les étapes suivantes des tests prennent pour acquis qu’aucun programme ne sera livré sans avoir été adéquatement testé unitairement. Il n’y aura donc pas de post validations des tests unitaires. En général le programmeur devra préparer ses propres données de test. Par contre, pour certains cas exigeant des données plus complexes, les données seront fournies par l’équipe de tests fonctionnels. 2. Les tests fonctionnels Il s’agit ici de tester les fonctionnalités avec la vision du concepteur. On est préoccupé par l’aspect d’un thème fonctionnel spécifique plutôt que par l’aspect programmation ou l’aspect global de l’application. 3. Les tests intégrés ou tests de validations ou de conception Ici on valide l’ensemble du système en fonction des processus opérationnels. L’on s’approche de la vision de l’utilisateur et il faut donc penser en terme de cycles d’opérations, tenir compte de la séquence d’exécution et du facteur temps (traitement de jour, de nuit, hebdo, fin de mois, etc.). Un cycle est composé de données de bases, d’une chaîne d’opérations et d’un résultat. Le transfert d’information entre les modules fonctionnels doit utiliser les données générées par les fonctionnalités en amont, et par conséquent, alimenter celles qui sont en aval. Les jeux d’essais seront donc des données de bases qui devront cheminer dans tout le processus.
  • 4. Guide pour la préparation et l’exécution de tests fonctionnels Page 4 sur 18 4. Les tests d’acceptation ou recette utilisateurs Il s’agit ici de la recette utilisateurs, où ils valideront le produit dans son ensemble en fonction de leurs processus réels. A noter que le terme « tests intégrés » est utilisé différemment selon les organisations. Pour certains il signifie les tests fonctionnels (étape 2) et pour d’autres il signifie les tests de validations (étape 3). Dans ce document, les tests intégrés correspondent à l’étape 3. 3. Environnements pour les tests Les tests unitaires sont faits sur l’environnement de développement. Les tests fonctionnels sont faits sur un environnement dédié et indépendant des changements faits dans l’environnement de développement. Au cours de l’évolution du développement, le paramétrage, les programmes et les données de bases seront appelés à changer et à évoluer. On doit donc pouvoir les transférer d’un environnement à l’autre. Les jeux d’essais devront pouvoir être rechargés et ré initialisés afin de permettre de refaire les mêmes tests dans les mêmes conditions. On peut envisager de créer un environnement de référence qui contiendra tous les objets requis pour les tests mais sur lequel aucun test ou développement ne sera fait. Ceci requiert un processus permettant de copier des jeux d’essais entre environnements. Il est à noter que des tests de régression seront faits suites à des corrections de programmes. Dans certains cas ces tests devront être effectués dans les plus brefs délais. Ceci exige de pouvoir charger/initialiser un environnement d’essai rapidement. Il faut pouvoir répondre à cette contrainte. Il est essentiel de documenter et mettre en place un processus clair et efficace permettant les transferts entre l’environnement de développement et celui de test. Ceci doit être fait avant de commencer la mise en place des jeux d’essais. 4. Les jeux d’essais : Tests reproductibles et régression Chaque fonctionnalité doit être testée dans un contexte isolé et un environnement stable et reproductible à volonté. Il faut donc des jeux d’essais prédéterminés qui pourront être rechargés à volonté. La préparation et la mise en place de jeux d’essais représentent un effort important. La tentation est grande de sauter cette étape et de faire des jeux d’essais à la pièce. Avoir un jeu d’essais stable et réutilisable permet de refaire les tests suite à des changements, avec exactement le même environnement et les mêmes données. C’est la seule façon de s’assurer que l’on a réglé un problème sans briser autre chose (régression suite à des corrections). Quand on utilise des jeux de données qui sont faits au fur et à mesure, il devient très difficile de détecter les régressions. Il s’ensuit généralement une situation où, suite à plusieurs corrections de code, on découvre un peu plus tard (des fois beaucoup plus tard) que ce qui marchait avant ne marche plus. Bien qu’il semble plus rapide de faire des jeux de données au fur et à mesure, ceci implique qu’il faut recommencer à chaque fois. Quand vous prenez le temps de faire des jeux spécifiques avec un processus de chargement, vous y mettez plus de temps au début, mais ensuite il est très facile et rapide de mettre en place les jeux d’essais pour refaire une nouvelle série de tests … et refaire il y aura.
  • 5. Guide pour la préparation et l’exécution de tests fonctionnels Page 5 sur 18 5. Structure des cas de tests - Un processus « top down » Thèmes Fonctionnalités Domaines de tests (éclatement des fonctionnalités en règles et requirements) Sous-domaine (regroupement des caractéristiques de domaines) Cas cibles -- -- -- 5.1 Règles fonctionnelles, un prérequis essentiel Avant toute chose, il est essentiel d’avoir l’ensemble des règles fonctionnelles. Règles que les programmeurs ont aussi utilisées pour faire le développement et les tests unitaires. 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. 5.2 Thèmes et Fonctionnalités • Thème : Un cycle opérationnel. Un thème est composé d’une ou plusieurs fonctionnalités • Fonctionnalité : Sous ensemble d’un thème Exemples : . Liste des liens entre les thèmes et fonctionnalités Thèmes Fonctionnalités Paiements automatiques des relevés Interface relevés/règlements auto Remise en banque Effets échus/ suppression du risque Édition journal des effets Maj. date d'échéance d'effet Liste des liens entre les thèmes et les fonctionnalités Cas détaillés Jeux d’essais Programmes de chargements et fichiers de données Scénarios de tests : Prérequis Transactions à exécuter Données transactionnelles Résultats attendus
  • 6. Guide pour la préparation et l’exécution de tests fonctionnels Page 6 sur 18 Règlements manuels Gestion du bordereau de remise en banque Génération écritures Saisie rapide règlements (espèces) Maj. textes postes comptables Situation de compte Gestion situation de compte Calcul des intérêts Génération des éléments de facturation Liste des situations de compte 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. 5.3 Domaines de tests Le domaine de tests est un découpage de la fonctionnalité. Il s’agit d’une caractéristique à tester, comme par exemple la sélection des pièces comptables ou la validation du calcul de taxes. Un domaine de tests peut découler d’une règle spécifique, de plusieurs règles regroupées, d’une réalité du métier, d’un cycle opérationnel ou tout autre critère de regroupement pertinent à ce que l’on veut tester. Un domaine de tests s’éclate en sous domaines. Par exemple : Domaine : Sélection des pièces Sous domaines : Sélection selon le type de pièce + DC Sélection selon le type de client + DC Sélection selon la date 5.4 Sous-domaines – Croisement des N° de cas tests avec les N° de règles Les sous-domaines sont l’éclatement des domaines de tests en caractéristiques (règles fonctionnelles spécifiques). 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. 5.5 Cas cibles Les cas cibles sont l’éclatement des sous-domaines. C’est le dernier niveau d’éclatement. A partir de ce point, un cas cible correspondra à un cas de test spécifique à exécuter. 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
  • 7. Guide pour la préparation et l’exécution de tests fonctionnels Page 7 sur 18 Les cas cibles pourraient êtres : N° TYPE DE PIÈCE DC Résultat 010-1 Valide Valide Sélectionné 010-2 Valide Invalide Non sélectionné 010-3 Invalide Valide Non sélectionné N° TYPE DE PIÈCE CLIENT Résultat 020-1 Valide Valide Sélectionné 020-2 Valide Invalide Non sélectionné 020-3 Invalide Valide Non sélectionné Exemple de cas cibles à partir d’une règle de gestion : Domaine : ASSIGNATION DES PÉRIODES Règle de gestion : L’assignation de la période est faite selon la date de la pièce. Analyse du cas : La date peut : Correspondre à la période courante Correspondre à une période précédente Correspondre à une période postérieure Une période précédente ou postérieure peut : Être ouverte Être fermée Sous-domaine : Valider l’assignation des périodes et l’impact de leurs statuts sur le bon fonctionnement de l’interface Cas cibles : NOTE : on prend pour acquis que la période courante est toujours ouverte Statut de la Période correspondante Date Résultat 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 5.6 Cas détaillés Les cas détaillés sont l’exécution des cas cibles. Il s’agit ici de traduire le cas cible en actions précises. Quelqu’un qui ne connaît pas le sujet doit pouvoir exécuter et valider le test en suivant simplement les instructions du cas détaillé. 5.6.1 Les prérequis Documenter les prérequis à exécuter avant de pouvoir procéder au test. 5.6.2 Transactions à exécuter La partie traitement donne les instructions à suivre, pas à pas, pour exécuter le test. (Ex : code transaction, saisie du champ XXXX, appel de la fonction YYYY via touche ZZZZ,…)
  • 8. Guide pour la préparation et l’exécution de tests fonctionnels Page 8 sur 18 5.6.3 Les données Lors de l’exécution des cas de tests détaillés on détermine les données requises selon : • Les prérequis • Les transactions à utiliser • Les champs à saisir Les principaux types de données sont : • Les données d’input Elles sont constituées de l’ensemble des données requises à la bonne exécution du cas détaillé. On distinguera : • Les données prérequises pour la bonne exécution du cas détaillé Exemples : Chargement d’une plage de clients, d’écritures comptables, de factures. • Les données transactionnelles du jeu d’essai Exemples : Fichier en entrée dans le cadre d’un traitement d’interface, valeurs de zones à saisir sur un traitement transactionnel, etc. • Les données d’output Les données d’output constituent le résultat attendu du cas détaillé. (Ex : valeurs de zones d’une écriture comptable générée dans la cadre du cas de test détaillé) 5.6.4 Résultats attendus Il y a ici deux règles importantes à suivre : - Résultat clair - Documenter et valider le résultat global de chaque cas • Résultat clair Il est important dans le cas détaillé de donner le résultat attendu sans ambiguïté. • Documenter et valider le résultat global de chaque cas Afin de permettre une meilleure détection de la régression lors de tests, la documentation des résultats attendus doit permettre de valider le résultat total de la transaction et non pas seulement la valeur que l’on teste. Il en découle que l’on demande aussi au testeur de valider l’ensemble, tel que documenté. Par exemple : Si on teste le calcul de taxes sur une facture, dans le résultat final il faut bien indiquer « tout » ce qui sera affiché ou imprimé sur la facture (noms, items, descriptions, montant de chaque ligne, total, etc.). De cette façon, si quelque chose d’autre a été affectée suite à une correction de code, on le détectera … même si on ne le cherche pas. Cette règle exige plus de travail lors de la préparation des cas de tests détaillés et a souvent été remise en question. Mais il a été démontré, que sur l’ensemble, on sauvait énormément de temps. 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). 5.7 Jeux d’essais Les jeux d’essais découlent des cas de tests détaillés et comprennent l’ensemble des données, prérequises et d’exécution, nécessaires à la bonne réalisation du test. (cf. cas détaillés). La plupart du temps, on associera au jeu d’essai un processus de chargement via des programmes ou des outils.
  • 9. Guide pour la préparation et l’exécution de tests fonctionnels Page 9 sur 18 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. 7. Consignes générales dans la préparation de cas de tests • Utiliser un jeu de données spécifique pour chaque cas de test. Éviter les combinaisons de plusieurs cas de tests avec les mêmes données. Ainsi la validation s’en trouve plus simple. Si l’on combine plusieurs cas sur un jeu de données, la validation du résultat et l’analyse d’une erreur s’en trouvent plus complexes. Finalement, et c’est ce qui arrive le plus souvent, si on doit modifier le jeu de données pour une raison quelconque on sait quoi changer et quels en sont les impacts sans risque d’interférer avec un autre cas de test qui pourrait utiliser ce même jeu. • Mettre des références qui permettent d’identifier uniquement chaque enregistrement et de les lier à un cas spécifique. Comme inclure le N° du cas dans une pièce comptable ou une description de produit. S’il y a plusieurs enregistrements pour un cas, ajouter aussi un numéro de séquence pour bien les différencier. Ceci permet de faciliter le travail de validation et est indispensable pour permettre l’automatisation des tests. • Utiliser une fourchette spécifique et facilement identifiable pour les tests négatifs et les items à exclure du résultat. On peut les identifier facilement si les références commencent ou se terminent par 99. Par exemple, si pour un test de sélection toutes les pièces rejetées on une référence qui commence par 99 on pourra rapidement les identifier si elles ont été incluses par erreur. • Utiliser des fourchettes de valeurs pour regrouper les données selon les thèmes. Par exemple associer une fourchette de N° de client spécifique à chaque thème. Le but est d’isoler les tests, afin d’éviter que quelqu’un d’autres modifie vos données lors de l’exécution des ses tests. • Commencer par faire des tests positifs (dont le résultat attendus est un succès) simples. Procéder ensuite à des cas positifs plus complexes. Terminer avec les tests négatifs (cas où le résultat doit générer ou détecter une erreur) • Voici une liste non exhaustive de divers points à considérer dans l’élaboration des cas de tests : Validations des combinaisons de règles : - Est-ce fonctionnellement valide ? - Même si ça ne plante pas, est-ce que ça fonctionne comme prévu au niveau fonctionnel ? Validation des différents niveaux de sélections et d’exclusions : - Lors d’une sélection automatique - Lors du balayage d’un fichier Test de sélection nulle : - Critère de traitement qui retourne une sélection vide (ex : sélection d'un client qui n’a aucune facture) - Traitement d’un fichier batch vide
  • 10. Guide pour la préparation et l’exécution de tests fonctionnels Page 10 sur 18 Test des cas extrêmes : - Fourchette avec minimum plus grande que le maximum - Valeurs autorisées - Combinaisons inexistantes - Valeurs nulles ou vides - Vérifier si possible d’entrer des nombres dont une opération de totalisation sera plus grande que le format du champ de total. 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.
  • 11. Guide pour la préparation et l’exécution de tests fonctionnels Page 11 sur 18 ANNEXE – Exemples du processus de préparation de cas de tests
  • 12. Guide pour la préparation et l’exécution de tests fonctionnels Page 12 sur 18 A. Découpage en domaines / sous-domaines Notez ici le croisement des numéros de cas de tests avec les numéros de règles fonctionnelles OBJECTIF / Fonctionnalité testée ID test N° règles BESOIN 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 c-rlv008-trt c-rlv014-trt Différents types de relevés 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 c-rlv017-trt Valider le critère de tri 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
  • 13. 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 En-tête pièce comptable de RLV Date de RLV dans ACTI = Date comptable dans COGEST (= Date de pièce) DATE COMPTABLE RESULTAT 010-1 Date RLV = Date 1 DATE DE LA PIECE CREE = DATE 1 010-2 Date RLV = Date 2 DATE DE LA PIECE CREE = DATE 2 Valider le texte d’en-tête 020 La règle de gestion s’applique à ACTI et pas à COGEST Pour COGEST, il s’agit d’un transfert zone à zone ce qui a du être vérifié en Test Unitaire Valider le type de pièce comptable et le texte du poste client des pièces RLV Les types de pièces varient en fonction du type de RLV (info ACTI) Type de pièce provenant de ACTI Texte du poste client 030-1 T1 Libellé type de pièce T1 030-2 T2 Libellé type de pièce T2 030-3 T3 LIBELLE TYPE DE PIECE T3 Poste client du RLV Valider le choix des clés comptables La CC varie en fonction de la présence ou non de CGS et du sens de l’écriture ENTREE RESULTAT MODE DE PAIEMENT TYPE DE PIECE SENS CODE CGS CC 040-1 Quelconque RB Débit OUI 09 040-2 Quelconque RB Crédit OUI 19 040-3 3 RC Débit OUI 09 040-4 3 RC Crédit OUI 19 040-5 4 RC Débit OUI 09 040-6 4 RC Crédit OUI 19 040-7 Autre que 3 et 4 RC Débit NON 01 040-8 Autre que 3 et 4 RC Crédit NON 11 040-9 4 Autre que RC et RB Débit NON 01 040-10 4 Autre que RC et RB Crédit NON 11 Valider l’enregistrement comptable dans le compte client Le numéro de client est une info ACTI Groupe de comptes : CLGO, PERS, DIVR Groupe de compte du client N° DE COMPTE CLIENT N° DE COMPTE DU POSTE CLIENT 050-1 CLGO N1 N1 050-2 PERS N2 N2 050-3 DIVR N3 N3
  • 14. Guide pour la préparation et l’exécution de tests fonctionnels Page 14 sur 18 C. Prérequis et Jeux d’essais détaillés • Fourchettes de valeurs utilisées Entités Plage de valeurs Commentaires Société RGA La société RGA est une copie de la société DPG Lors de la copie, il faut préciser que le plan comptable est aussi copié ; ainsi il n’est pas nécessaire de recréer les plans comptables Clients 10000 à 10999 Domaine d’activité 672 479 493 ROANNE ST ETIENNE VALENCE • Chargement automatique des données Séqu enc. Entités Fichiers d’input Script autotester Transaction/ programme Commentaires 1. Clients IFRGA01.XLS ISRGA01 FD01 • Chargement manuel des données Les données sont saisies dans les tables spécifiques selon la procédure suivante : 1. LANCER LA TRANSACTION SM31 2. SAISIR LE NOM DE LA TABLE A REMPLIR 3. CLIQUER SUR LE BOUTON GERER 4. L’ECRAN DE GESTION DE TABLE APPARAIT, CLIQUER SUR NOUVELLES ENTREES 5. SAISIR LES DONNEES TELLES QUE DANS LES TABLEAUX PAGE SUIVANTE L’ensemble des tables à remplir est le suivant : TABLE DES PARAMETRES DE REMISE EN BANQUE Nom Libellé Type ZADBQ Délai interne banque ZADIN Délai interbancaire ZABQP Priorité banque ZADOC Délai DPG AVP accéléré TABLE DES PARAMETRES DES CRITERES DE RECADRAGE Nom Libellé Type ZACAF Critère de recadrage chiffre d’affaire ZAPAR Critères particuliers de recadrage ZASOC Table paramétrage société arpège
  • 15. Guide pour la préparation et l’exécution de tests fonctionnels Page 15 sur 18 • Données d’exécution du test Fichiers d’input Fichiers d’output Script autotester Transaction/ programme Commentaire IZRLV01 Sans Objet Sans Objet Ce fichier est copié sous : GARLVAR1.19981201.74.672.DAT IZRLV02 Sans Objet Sans Objet Ce fichier est copié sous : GARLVAR1.19981202.76.493.DAT IZRLV03 Sans Objet Sans Objet Ce fichier est copié sous : GARLVAR1.19981203.75.479.DAT
  • 16. Guide pour la préparation et l’exécution de tests fonctionnels Page 16 sur 18 D. Cas détaillés et résultats attendus • Interface relevés – Règlements auto (création portefeuille) L’intégration des relevés et la génération des règlements ont été dissociés dans le paragraphe « cas cible » afin de bien isoler les règles de gestion de l’un ou l’autre des traitements. Ces deux traitements sont, ici, traités ensembles car dans COGEST c’est un seul programme qui intègre les relevés puis génère les règlements automatique. PROCÉDURE DE TEST Intégration du fichier IZRLV01 : 1er fichier de relevés 010-1 010-2 030-1 030-2 030-3 050-1 050-2 050-3 090-1 090-2 090-3 090-4 090-5 100-1 100-2 100-3 100-4 1020-1 1020-2 Lancement de l’exécution du programme Lancer la transaction « SE38 » Indiquer le nom du programme ZAJOUHLP Appuyer sur le bouton EXÉCUTER Passage à l’écran de saisie des paramètres de sélection COGEST : Programme d’aide à la mise en place de la journalisation Saisie des paramètres de sélection : Nom du programme d’interface : ZARLVB01 Nom de la variante d’interface : V_ZARLVB01_672 DC : 672 Date de traitement : 01.12.1998 Appuyer sur le bouton EXÉCUTER Lancer la transaction « SE38 » Indiquer le nom du programme ZARLVB01 Appuyer sur le bouton EXÉCUTER AVEC VARIANTE Affichage de la fenêtre de choix de la variante Sélectionner la variante : V_ZARLVB01_672 Appuyer sur le bouton EXÉCUTER Passage à l’écran : COGEST – Interface relevés et règlement automatique Modifier la société: Société : RGA Dans le menu : ‘Programme / Exéc. Arrière plan’ Passage à l’écran de sélection des paramètres d’impression batch Décocher les options suivantes : Impression immédiate Supprimer après édition Appuyer sur le bouton ‘SAUVEGARDE’ Suivi de l’exécution du job lancé en arrière-plan Lancer la transaction « SM37 » Saisie des paramètres de sélection : Nom du job : ZARLVB01 Appuyer sur ‘ENTER’ Passage à l’écran de synthèse des jobs Appuyer sur ‘ACTUALISER’ jusqu’à ce que le statut du job soit ‘Terminé’
  • 17. Guide pour la préparation et l’exécution de tests fonctionnels Page 17 sur 18 Vérification des données dans les comptes-rendus Lancer la transaction « SP01 » Vérifier que la zone « N° d’ordre spool » est vide Appuyer sur ‘ENTER’ Visualisation des ordres spool Le programme précédent a généré 3 états : C.R Règlements C.R C.R Relevés Sélectionner le ‘C.R’ Appuyer sur ‘ AFFICHER ‘ Vérifier le total des relevés intégrés pour l’établissement : Nombre de relevé lus dans le fichier 17 Nombre de relevés générés 17 Nombre de règlements générés 1 Nombre de relevés non traités 0 Sélectionner le ‘C.R RELEVÉS Appuyer sur ‘ AFFICHER ‘ Vérifier l’ensemble des données en comparaison du tableau des résultats ci-dessous Lancement de l’exécution du dossier Batch-Input Lancer la transaction « SM35 » Saisie des paramètres de sélection : Nom de dossier : ARLV01* Appuyer sur ‘ENTER’ Accès à l’écran « Batch input : synthèse des dossiers » Dans la rubrique ‘Dossier restant à traiter’ : Nom de dossier : ARLV01JJHHMM Transaction : Double cliquer sur le Dossier Sélectionner le Mode exécution « Arrière-plan » Appuyer sur ‘EXÉCUTER Affichage du message ‘1 dossier transféré en arrière plan’ Appuyer sur ‘ENTER’ pour actualiser l’affichage Lorsque la rubrique ‘Dossier traité’ apparaît Appuyer sur ‘PROTOCOL’ Reprendre le n° des pièces comptabilisées (créées) dans RGA Vérifier : Le nombre de transactions lues : 18 Le nombre de transactions traitées : 18 Le nombre de transaction erronées : 0 Le nombre de transactions supprimées : 0
  • 18. Guide pour la préparation et l’exécution de tests fonctionnels Page 18 sur 18 • Résultats attendus Contenu du compte-rendu ‘C.R RELEVÉS’ Etab. Client Type Nbre. Montant Test 672 10993 RD 1 1.302,00 Total Client 1 1.302,00 1020-1 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 Total etab. Par relevé RD 10 24.218,00 1020-2 RB 1 1.302,00 1020-2 RC 3 3.906,00 1020-2 RJ 2 617,94 1020-2 RM 1 12.500,00 1020-2 Total Établissement 17 42.543,94 1020-2