Docstoc

GUIDE POUR LA PRéPARATION ET L'EXéCUTION DE TESTS FONCTIONNELS

Document Sample
GUIDE POUR LA PRéPARATION ET L'EXéCUTION DE TESTS FONCTIONNELS Powered By Docstoc
					       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 »
                                             Liste des liens entre les thèmes et les fonctionnalités
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
                                                          --
                                                           --
                                                          --




                                      Cas détaillés                       Jeux d’essais




                                            Scénarios de tests :                                  Programmes de chargements
                                            Prérequis                                             et fichiers de données
                                            Transactions à exécuter
                                            Données transactionnelles
                                            Résultats attendus


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
                                 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   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


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 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

     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 TYPE DE PIECE        SENS                CODE CGS              CC
               PAIEMENT
      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 Débit                      NON                  01
                                  RB
      040-10 4                    Autre que RC et Crédit                     NON                  11
                                  RB
             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                                               ROANNE
                             479                                           ST ETIENNE
                             493                                           VALENCE


      Chargement automatique des données
       Séqu        Entités         Fichiers d’input    Script autotester     Transaction/              Commentaires
       enc.
                                                                             programme
       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/                   Commentaire
                                                                  programme
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     Lancement de l’exécution du programme
   010-2     Lancer la transaction « SE38 »
   030-1     Indiquer le nom du programme ZAJOUHLP                                                       Passage à l’écran de saisie des paramètres de sélection
   030-2     Appuyer sur le bouton EXÉCUTER                                                              COGEST : Programme d’aide à la mise en place de la journalisation
   030-3
   050-1     Saisie des paramètres de sélection :
   050-2               Nom du programme d’interface : ZARLVB01
   050-3               Nom de la variante d’interface : V_ZARLVB01_672
   090-1               DC : 672
   090-2               Date de traitement : 01.12.1998
   090-3     Appuyer sur le bouton EXÉCUTER
   090-4     Lancer la transaction « SE38 »
   090-5     Indiquer le nom du programme ZARLVB01                                                       Affichage de la fenêtre de choix de la variante
   100-1     Appuyer sur le bouton EXÉCUTER AVEC VARIANTE
   100-2     Sélectionner la variante : V_ZARLVB01_672                                                   Passage à l’écran : COGEST – Interface relevés et règlement
   100-3     Appuyer sur le bouton EXÉCUTER                                                              automatique
   100-4
             Modifier la société:                                                                        Passage à l’écran de sélection des paramètres d’impression batch
  1020-1               Société : RGA
  1020-2 Dans le menu : ‘Programme / Exéc. Arrière plan’
             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 :                                                        Passage à l’écran de synthèse des jobs
                       Nom du job : ZARLVB01
             Appuyer sur ‘ENTER’
             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                                        Visualisation des ordres spool
Appuyer sur ‘ENTER’                                                                       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’                                                                     Vérifier le total des relevés intégrés pour l’établissement :
Appuyer sur ‘ AFFICHER ‘                                                                         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                                                               Vérifier l’ensemble des données en comparaison du tableau des
Appuyer sur ‘ AFFICHER ‘                                                                   résultats ci-dessous
Lancement de l’exécution du dossier Batch-Input
Lancer la transaction « SM35 »
Saisie des paramètres de sélection :                                                      Accès à l’écran « Batch input : synthèse des dossiers »
          Nom de dossier : ARLV01*                                                        Dans la rubrique ‘Dossier restant à traiter’ :
Appuyer sur ‘ENTER’                                                                       Nom de dossier : ARLV01JJHHMM
                                                                                          Transaction :
Double cliquer sur le Dossier                                                             Affichage du message ‘1 dossier transféré en arrière plan’
         Sélectionner le Mode exécution « Arrière-plan »
Appuyer sur ‘EXÉCUTER
Appuyer sur ‘ENTER’ pour actualiser l’affichage                                           Reprendre le n° des pièces comptabilisées (créées) dans RGA
Lorsque la rubrique ‘Dossier traité’ apparaît                                             Vérifier :
Appuyer sur ‘PROTOCOL’                                                                        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