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