Comment tester en « mode agile » ?

18 05 2009

Comme promis aux nombreux lecteurs m’ayant fais la demande, je vous présente cet article traitant des tests en mode agile. Il s’agit d’une vulgarisation et je tente de vous présenter les principes et points importants à prendre en compte.

SCRUM, XT programming et autres acronymes du même acabit sont légions depuis quelques années et sont très en vogue parmi les développeurs. En fait il s’agit de développer le plus rapidement possible quelques fonctionnalités et de mettre tout aussi rapidement en production (d’où le terme de sprint que nous verrons plus tard) !

Et le test me direz-vous ?

Les activités de tests sont bien entendu réduits à au maximum… mais… il faut savoir qu’il y a une méthodologie spécifique concernant les activités de tests et qui s’insère naturellement et simplement en mode agile.

En premier lieu je passe en revue les deux méthodes de développements les plus connues dans le mode agile. En effet, elles représentent la majorité des projets de ce type (nos chers développeurs les préfèrent aussi). Il s’agit du SCRUM et de l’eXtreme Programing.

Méthode SCRUM :
La définition du mode agile est en partie basée sur la remarque suivante : « … L’approche course de relais pour le développement de produits…peut être en conflit avec les objectifs de vitesse et de flexibilité maximum. A l’inverse, une approche holistique comme au rugby— quand une équipe essaie d’avancer en restant unie, en se passant le ballon de main en main— peut mieux servir les exigences de compétitivité d’aujourd’hui ». Hirotaka Takeuchi et Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, Janvier 1986.

Ainsi le SCRUM est un processus agile qui permet de produire la plus « grande valeur métier » dans la durée la plus courte. Du code est produit à chaque sprint (toutes les 2 à 4 semaines).

Le métier (les utilisateurs par exemple) définit les priorités. L’équipe de développeur s’organise elle-même pour déterminer la meilleure façon de produire les exigences (ou backlog) les plus prioritaires.

Et à chaque fin de sprint, tout le monde peut voir fonctionner le produit courant et décider soit de le livrer dans l’état, soit de continuer à l’améliorer pendant un sprint supplémentaire.

Les grands principes du SCRUM :

  • Equipe responsable, en auto-organisation
  • Avancement du produit / code par une série de « sprints » de 5 jours maximum
  • Exigences définies comme des éléments d’une liste appelée « backlog du produit »
  • Pas de prescription de pratiques d’ingénierie
  • Utilisation de règles génériques permettant de créer un environnement agile pour un projet

eXtreme programming :
En 2001, aux États-Unis, dix-sept acteurs clés du développement logiciel se sont réunies pour débattre de leurs méthodes respectives, dites méthodes agiles. Les plus connus d’entre eux étaient :

  • Ward Cunningham l’inventeur du Wiki via WikiWikiWeb
  • Kent Beck, père de l’extreme programming et cofondateur de JUnit
  • Ken Schwaber et Jeff Sutherland, fondateurs de SCRUM
  • Jim Highsmith, prônant l’ASD
  • Alistair Cockburn pour la méthode Crystal clear
  • Martin Fowler et Dave Thomas
  • Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD (Développement rapide d’applications).

Ces nombreux experts réussirent à extraire de leur méthodes respectives des critères pour définir une nouvelle façon des développer des logiciels. De cette réunion devait émerger le Manifeste Agile, considéré comme la définition du développement agile et de ses principes.

Ainsi leurs conclusions furent :

Principales causes identifiées de l’échec des projets :

  • Mauvaise compréhension du besoin : 51%
  • Estimation et planification déficiente : 48%
  • Technologies mal maîtrisées : 45%

Méthodes classiques trop lourdes :

  • Manque de réactivité
  • Excès de documentation

But : produire un logiciel de qualité en respectant les délais et le budget grâce à un ensemble de pratiques efficaces poussées à l’extrême.

Dans la pratique les choses sont bien différentes… En effet, les délais et budgets sont à peine respectés (comme dans les projets en mode classique – processus en V et autres) et la qualité est inconnue de la plupart des développeurs.

En fin de compte les problèmes concernant les tests sont les mêmes sur tout les projets. Le principal étant la non connaissance des bonnes pratiques de tests par les chefs de projets (ou scrumMaster) et les développeurs (ou CoWboyZ).

Ainsi le mode agile possède aussi quelques bonnes pratiques à mettre en œuvre et faire respecter par les ScrumMaster et autres chefs de projet. Voici celles que j’ai apprises et optimisées lors de mes missions.

Ci-dessous le processus de développement logiciel en mode agile :

image1_agile

On constate que le processus fonctionne un peu comme un sous-marin, avec des compartiments devant rester étanches, sous peine de ne plus respecter le processus…

  • Ainsi, les métiers définissent leurs besoins et exigences, ils les communiquent au chef de produit
  • Le chef de produit en fais une synthèse et en propose une priorisation au chef de projet (ou ScrumMaster)
  • Ensuite, le chef de projet les prends en compte et détermine les exigences (ou backlogs) qui seront développés par son / ses équipes « agiles ».
  • Sachant que les users métiers ne doivent parler qu’uniquement au chef de produit et que celui-ci est le seul à parler avec le chef de projet
  • Enfin, les développeurs et testeurs ne peuvent pas parler avec les users ni les chefs de produit

Ce mode de « communication en mode étanche » a été préconisé à l’époque afin d’assurer la tranquillité de l’équipe de développement et s’assurer que ceux-ci ne seraient pas dérangés. Ainsi, les créateurs du mode agile crurent assurer en partie par ce biais le respect des délais et des budgets.

Mais, les effets pervers de ce mode étanche sont :

  • Pas ou peu de cahier des charges / spécifications en entrée des développements
  • Les besoins et exigences des utilisateurs sont filtrés et surtout réinterprétés par trois personnes différentes ayant chacun des priorités et objectifs différents
  • Pas de traçabilité des exigences
  • Des effets de ralentissements ou « d’à peu près » car quand un développeur a une question sur une fonctionnalité à coder, il ne peut la poser qu’au chef de projet qui demandera au chef de produit qui demander aux utilisateurs. La réponse (si la question a bien été posée) prendra le chemin en sens inverse…
  • Les testeurs non presque pas de documentation et doivent souvent attendre la fin du  deuxième sprint pour avoir une certaine visibilité sur ce qu’il y aura à tester

Finissons cette description du processus logiciel en mode agile par la communication au sein de l’équipe agile.

  • En début de chaque sprint (tous les lundis donc car un sprint = 5 jours) il y a une réunion de démarrage qui doit aborder le planning, les outils, etc.
  • Pendant les sprints il y a une réunion quotidienne ne devant pas avoir lieu dans une salle (ceci reste un mystère pour moi j’avoue) mais plutôt dans un lieu incongru et très bruyant comme la salle à café ou équivalent. Cette réunion ne doit pas dépasser 15 minutes (avec des questions comme : les problèmes rencontrés, etc.)
  • Le reste de la communication est assurée par les « Instant Messenger » comme MSN et équivalent (même si les développeurs et testeurs sont dans le même bureau, ce qui est hallucinant à vivre je vous l’avoue !)

Synthèse des fondamentaux de l’agile :

  • Sprint et itérations très courts
  • Une équipe ne communiquant que par son scrumMaster
  • Spécifications « rédigées » pendant les sprints
  • Pas de plan de tests – scripts « one shot »

Ci-dessous le séquencement d’un projet agile :

image2_agile

Au sein d’un projet il y a plusieurs releases. Chaque release est composé de plusieurs sprint. Tous les 3 ou 4 sprints une release / package est construite par les développeurs (en 1 journée grand maximum). Puis, le package doit-être mis en production. Si vous avez lus mes articles précédents vous constaterez bien vite qu’il manque une étape importante avant la mise en production… (Roulement de tambour… suspens…), il s’agit des tests avant la mise en production. Comme :

  • Les tests de performance
  • Les tests d’exploitabilité
  • Les tests d’installations
  • Les tests de MEP à blanc, etc.

Bonnes pratiques :

  • Mettre en place une machine d’intégration continue qui assurera la « récolte » des développements, leurs sauvegardes et leurs versions
  • Prévoir, définir et mettre en œuvre les tests devant valider les packages :
  • Souvent cette étape se résume à un combat pour l’imposer auprès des chefs de projet qui trouve que les tests ne font pas partie du mode agile et ralentissent le processus. Ces mêmes chefs de projet qui subitement changent d’avis après des mises en production sans tests préalable… C’est ce que l’on appel l’expérience par l’échec.

image3_agile
Détaillons les activités de tests dans le mode agile en prenant un exemple concret :

Dans le schéma ci-dessus j’ai modélisé une release comportant uniquement deux sprints, une étape de packaging et la mise en production (MEP).

Itération 1 – Planning du sprint 1 (ou S1) :

  • Lundi 2 février au matin : réunion de démarrage (1 heure maximum – A). Le scrumMaster explique aux 3 développeurs et au testeur unique les backlogs (B) devant être développés et testés
  • Lundi 2 au vendredi 6 février matin les développeurs on les tâches suivantes :
  • Prise de connaissance des backlogs fourni par le scrumMaster
  • Développements (codage en Java – C) des backlogs (et des classes de tests bien entendu) :
  • + Tests unitaires (D) en utilisant Junit et Javadoc au sein du framework Eclipse
  • Chaque les développeurs « commit » leurs bouts de code. Ce code est pris en charge dans le processus d’intégration continue (E)
  • Lundi 2 au vendredi 6 février matin le testeur a les tâches suivantes :
  • Prise de connaissance des backlogs
  • Lecture des rapports de tests générés par Junit
  • Création des scripts de tests (sous Selenium – F)
  • Vendredi 6 février après-midi :
  • Le scrumMaster décide lors de la réunion matinale quotidienne de mettre fin au sprint 1 (S1) ce vendredi en fin de journée car il estime que les objectifs ont été atteints. Il envoi un mail pour en prévenir le chef de produit.

Planning du sprint 2 (S2) :

  • Lundi 9 au 13 février matin : réunion de démarrage (1 heure maximum). Le scrumMaster explique aux 3 développeurs et au testeur unique les backlogs devant être développés et testés
  • Lundi 9 au 13 février matin les développeurs on les tâches suivantes :
  • Prise de connaissance des backlogs fourni par le scrumMaster
    Développements (codage en Java) des backlogs (et des classes de tests bien entendu) :
    + Tests unitaires en utilisant Junit et Javadoc au sein du framework Eclipse
    Chaque les développeurs « commit » leurs bouts de code. Ce code est pris en charge dans le processus d’intégration continue
  • Lundi 9 au vendredi 13 février matin le testeur a les tâches suivantes :
    Prise de connaissance des backlogs S2
    Lecture des rapports de tests générés par Junit du S2
    Création des scripts de tests (sous Selenium) pour le S2
    + Le testeur doit aussi faire en parallèle (dès le lundi après la réunion) :
    Lancement et surveillance des scripts du S1 (H)
    Remontée des anomalies sur les backlog du S1 au scrumMaster (uniquement à lui – qui est juge et partie sur la décision de corriger ou pas les anomalies remontées par le testeur – G)
  • Vendredi 13 février après-midi :
    Le scrumMaster décide lors de la réunion matinale quotidienne de mettre fin au sprint 2 (S2) ce vendredi en fin de journée car il estime que les objectifs ont été atteints. Il envoi un mail pour en prévenir le chef de produit et indique qu’une mise en production est possible sans problème
    La MEP est effectué par un des développeurs. Juste avant de partir en week-end il lance l’installation en étant sur à 100% que tout se déroulera bien (I)

Fin de l’itération 1

J

Voici donc le fonctionnement typique d’une équipe agile classique. Suivant vos expériences, vous vous apercevrez qu’il y a de nombreuses erreurs de jugement et de très importants manques aux niveaux des tests !

Je vais lister ci-dessous les bonnes pratiques pouvant être mises en œuvre dans un projet agile. Sachant que ces bonnes pratiques devront être présentées et défendues auprès du scrumMaster, par le testeur.

L’intervention des bonnes pratiques est signalées par une lettre dans le planning ci-dessus et expliquées en détails ci-dessous :

image4_agile

Lien vers l’article traitant des tests unitaires.

Publicités




Que sont les tests d’exploitabilité ?

5 04 2009

Définition des tests d’exploitabilité :
Dans une entreprise (E1), l’entité responsable des applications et SI est à 99,8% nommée « la production ». Sa responsabilité concerne le fait de s’assurer et surveiller que ces applications sont en ligne (pour des sites Web par exemple), soient accessible par les clients et que les commandes effectués par ces mêmes clients puissent arriver et être traitées par les gens de l’entreprise E1.
La plupart du temps les « gens d’la prod’ » sont totalement invisible au commun des mortels que nous sommes. Ils sont présents le jour et la nuit et restent plutôt invisible.
Si un jour vous les croisez vous pourrez les remercier pour leur travail car il n’est pas si facile et vraiment très peu valorisé dans la plupart des sociétés.

« Mais quel rapport avec les tests tonton MAT ? »

Et bien, depuis quelques années déjà, (a long long years ago – façon début de légende), « les gens d’la prod’ » ne sont plus seul ! Un service, se situant juste avant la production, est souvent en charge de TESTER les applications avant de les confier à la production. Ce service est souvent nommé « Exploitation, pré-exploitation ou pré-production » (cela dépend de l’entreprise).
Ce service est donc en charge de vérifier certains aspects des applications qui seront ensuite installées par le service « production ».
Pour comprendre les tests devant être effectués par l’exploitation il faut tenter de comprendre un peu plus le travail journalier des « gens d’la prod’ ».

La « production » est donc focalisée sur la disponibilité et la qualité des services qu’elle doit délivrer, tout en garantissant la capacité à prendre en compte les évolutions du SI. Elle est la garante de la « mise en production » des modules faisant partie du SI de l’entreprise, ainsi que de la surveillance de ces modules. Ceci au niveau, performance, disponibilité, sauvegarde, etc.

Il existe des indicateurs pour mesurer tous ces points à vérifier et surveiller. Ils sont mesurés par rapport à des métriques claires et cohérentes en ligne avec les besoins métier. La plupart du temps ces indicateurs se trouvent réunis dans un document nommé SLA (Service lLevel Agreement) ou OLA (Operation Level Agreement). Il existe des outils dédiés pour mesurer la performance de ces indicateurs, mais j’u reviendrai plus tard.

Pour surveiller ces indicateurs, la production s’appuie donc sur des processus clairement définis et adoptés (espérons le du moins) dont l’objectif est le même pour remplir ses missions. Les missions principales sont :
Maintien de la disponibilité des services

  • Piloter
  • Exploiter et administrer

Maintien de l’intégrité de l’infrastructure

  • Maintenir l’infrastructure
  • Intégrer en production
  • Supporter

Qualité et cohérence des processus

  • Manager
  • Mesurer et améliorer
  • Capitaliser

Assurer la mise en production de nouvelles applications
Ainsi, la préoccupation permanente de la production est la recherche de l’excellence opérationnelle. Pour l’obtenir, elle applique les quatre règles visant à garantir l’intégrité de son périmètre :

  • Tous les outils standards (ou défini comme tel) et uniquement les outils standards sont implémentés et utilisés
  • Tous les projets sont initialisés via un processus formel dans lequel la production intervient pour l’intégration en production
  • Seuls les systèmes testés techniquement sont sous la responsabilité de la Production
  • Faire face aux risques majeurs. Et pour cela établir un Plan de Retour à l’Activité (PRA)

our que ces quatre règles puissent être vraie il faut que le service « exploitation » tests plusieurs points avant que les applications ne passent dans le service « production ». La recette d’exploitation a donc pour rôle, en tant que partie de la recette technique, de vérifier et homologuer l’exploitabilité de la solution à mettre en œuvre et sa conformité aux normes d’exploitation instaurées par la production.

Ci-dessous je développe les différents types de tests d’exploitation. Il en existe surement d’autres ou bien certain de ces tests sont déjà pris en compte par la production. Quoiqu’il en soit ces tests doivent être réalisés. Et ceci, par le service que vous voulez !

Le périmètre des tests d’exploitation concerne les :

Tests de conformité aux normes d’exploitation :

  • Vérification de la conformité aux normes et standards d’exploitation des procédures et documentations
  • Vérification de la prise en compte des consignes d’exploitation et de support (gestion des incidents et gestion des problèmes)

Test du plan de production / plan de bascules :

  • Validation des documentations des plans de production
  • Recette du plan de production
  • Vérification des procédures de mise en production (change management)
  • Validation de l’ordonnancement

Tests des procédures de supervision :

  • Vérification de la conformité des messages d’erreur aux normes et standards
  • Tests de détection et de gestion des anomalies
  • Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :

  • Tests de charge
  • Crash test
  • Reprise de traitement
  • Mode dégradé

Tests des servitudes de production :

  • Recette des sauvegardes / restauration et procédures
  • Recette des purges, historisation et archivage ainsi que les procédures

Plan de Capacité :

  • Vérification de la mise à jour du plan de capacité
  • Vérification du trafic réseau et des classes de services

Tests du PRA (le plus sympa à tester)

Ci-dessous je détaille plus avant chaque test. Quand je parle de plan de tests je veux signifier que les tests sont tous rédigés et exécutés dans un référentiel de tests (TESTLINK, QUALITY CENTER, etc.). Si cela n’est pas le cas « c’est le mal ! ». Plaisanterie mise à part, TOUS les types de tests doivent être basés dans un référentiel de tests. Au final, tous ces types de tests représentent les exigences devant être pris en compte et à ce titre devenir des exigences de tests dans le référentiel de tests.
Bien entendu une stratégie des tests d’exploitabilité doit être définie (vous n’y échapperez pas bande de canaille !).
Mais voyez plutôt mes autres articles sur le sujet.

Tests de conformité aux normes d’exploitation :
Les normes d’exploitation regroupent les règles et conventions qui régissent :

Les normes d’exploitation regroupent les règles et conventions qui régissent :

  • L’installation d’une application en tant qu’ensemble de programmes permettant d’assurer une tâche ou une fonction particulière
  • Le nommage, la définition et l’installation d’un environnement en tant qu’instance d’une application avec ses différents composants (logiciels, interfaces, traitements, bases de données, etc.) s’inscrivant dans un contexte d’utilisation en relation avec la gestion de cette application : production, développement, intégration, recette, etc.
  • Le nommage et la définition d’un traitement ou d’un job (ou batch) en tant qu’opération automatisée (script, programme, etc.)
  • Les normes d’écriture des scripts (shell) lanceurs ou applicatifs
  • Le nommage et la définition d’une chaîne d’ordonnancement regroupant les traitements dans un ensemble cohérent et interdépendant (Crontable ou ordonnanceurs d’un éditeur)
  • La définition des interfaces en tant que flux entrant ou sortant d’une application
  • Les normes et définitions des sas de transfert en tant que lieu d’échange de fichiers inter-applications

Le plan de tests d’exploitabilité listera donc la conformité des points suivants :

  • Recette du dossier d’exploitation :
    • Schéma d’architecture technique de l’application
    • Nommage et description de l’arborescence applicative (binaires, données, logs, …)
    • Description et nommage des composants de l’application (serveurs, bases de données, logiciels, …)
    • Nommage des tablespaces, schémas et objets Oracle des SGBD de l’application
    • Identification et nommage des users applicatifs
    • Description des flux de l’application
    • Consignes de reprise
    • Description du fonctionnement en mode dégradé
    • Description des répertoires à purger, historiser et archiver (consignes, fréquences, rétention, …)
    • SLA de l’application

Recette du dossier d’ordonnancement :

  • Schémas des chaînes d’ordonnancement applicatifs
  • Description des chaînes job par job (batch ou chaine de batch)
  • Calendriers de planification des chaînes
  • Description des interfaces
  • Liste des codes retour
  • Description des cas d’erreur
  • Procédures de reprises
  • Gestion des logs

Recette du dossier de supervision :

  • Description des processus sensibles de l’application
  • Description et seuils de volumétrie des  tablespaces
  • Description et seuils de volumétrie des filesystems à surveiller
  • Consignes d’exploitation sur anomalies

Recette du dossier de sauvegarde :

  • Noms et description des polices de sauvegarde (arborescence, type, fréquence,  …)
  • Noms et descriptions des chaînes de sauvegardes (type, planning, rétention,…)
  • Schémas des chaînes de sauvegarde

Test du plan de production :
Le plan de production décrit et prépare le déploiement de l’application devant être installée dans le SI de E1. Il comprendra les composants applicatifs packagés sous une forme respectant les normes E1 et permettant un déploiement tel quel, quel que soit l’environnement concerné. La documentation fournie en phase de test d’exploitabilité sera complétée des éléments suivants :

  • Packages fonctionnels
    Check-lists de déploiement
    Dossiers d’installation
    Procédures de mise en œuvre en production
    Procédures et plannings de changements en production (formations, mise à jours contrats maintenance, …)

L’installation des composants cibles applicatif ou techniques de l’application sera réalisée conformément aux guides d’installation applicatifs fourni et / ou aux spécifications d’architecture.

Le plan de test du plan de production comprendra :

  • Validation des documentations de déploiement
  • Recette des check-lists de déploiement
  • Recette de la documentation d’installation
  • Tests des procédures de mise en œuvre en production
  • Validation des ordonnancements batchs (fenêtres de déclenchement, périodicité, temps de traitement, conformité de la gestion des codes erreurs, …)
  • Recette fonctionnelle de l’environnement

Tests des procédures de supervision :
Ils consistent à simuler des cas d’erreur construits selon les composants à superviser identifiés dans la documentation d’exploitation.
Ces tests ont pour but de vérifier la validité de la détection des anomalies et la conformité des messages d’erreur ainsi que la bonne application des consignes de gestion de ces anomalies :

  • Vérification de la conformité des messages d’erreur aux normes et standards
  • Tests de détection et de gestion des anomalies
  • Validation des consignes
  • Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :
En complément des tests de performance qui valident la conformité de l’application aux exigences de temps de réponse et d’optimisation système, les tests de robustesse doivent permettre de valider la conformité du comportement en charge de l’application aux exigences d’exploitation d’E1.

Les cas de tests permettront la restitution de l’ensemble des attendus recensés :

Tests de charge en mode nominal (utilisation CPU, I/O, volumétrie, …)

  • Reprise de traitement batch sur incident de production
  • Crash test (comportement et stabilité sur arrêt d’un serveur)
  • Temps de bascule sur instance Oracle passive
  • Performances en mode dégradé (max 50% en clustering sur perte d’1 nœud)

Tests des servitudes de production :
Les tests des servitudes de production tests le fonctionnement des sauvegardes/restauration et leur conformité avec les procédures et modalités décrites dans la documentation afférente.

Les cas de tests identifiés restitueront la couverture des exigences suivantes (informations figurants pour exemple – à adapter selon le contexte / projet / SLA de E1) :

  • Sauvegarde des données (schémas Oracle, documents GED, traces, etc.)
    Sauvegarde application (exécutables, fichiers de configuration, briques techniques, etc.)
    Sauvegarde système (création d’images du système d’exploitation vierge d’application, etc.)
    Sauvegarde Oracle à chaud en mode begin backup
    Sauvegardes SAN durée max 15 mm
    Durée de restauration données + application 2h max
    Durée de restauration système complet 8h max
    Validation de l‘intégrité des éléments restaurés

Tests de PRA :
Un Plan de Reprise d’Activité est mis en œuvre après un sinistre majeur (perte de salle machine, incendie, attentats, inondations et autres catastrophe naturelle ou d’origine humaine). Il doit permettre un retour à l’activité dans des délais définis. Souvent, ce retour ce fait en mode dégradé, de manière temporaire jusqu’au retour en mode normal (arrivée de nouveaux serveurs, réplication du SI effective, etc.).
Dans le PRA figure donc le RACI (le qui fais quoi, comment et quand ?) ainsi que les actions devant être mises en œuvres ainsi que leurs ordonnancement clairement définis, approuvés par tous les acteurs du PRA avec les procédures réellement appropriées par tous.

Certes, il n’est pas facile de tester l’intégralité d’un PRA mais néanmoins certaines situations doivent être répétées pour qu’il n’y ai aucune surprise pour aucun des acteurs dans les moments de crise – le PRA est là pour cela, sinon il ne sert à rien. Pour exemple, au moment de l’incendie (et inondation dans la foulée) du Crédit Lyonnais à Paris il y a quelques années, des pertes de données importantes ont été subies car ce type de risques / sinistres majeurs n’avait pas été assez pris en compte (entre autre).

Les cas de tests devront être choisis avec soins en ayant à l’esprit le ratio : risques / coûts / occurrence.

Par expérience, exécuter les tests de PRA quand tous les acteurs sont averties et sur le pont ne sert strictement à rien ! Pour cela, seul le DSI, le responsable de la production et un observateur externe doivent être au courant. Le résultat des tests sera ainsi très représentatifs de l’état de préparation et d’appropriation du PRA par les acteurs impliqués (et au final très amusant à vivre pour un consultant externe ;-).
Pour finir, il faut savoir que c’est souvent le service en charge de l’exploitation qui est en charge de développer et administrer les batchs, chaine de batch et autres ordonnanceurs. Ainsi, ils leurs incombent de développer et tester ces shells. Mais aussi d’administrer certaines plateformes et environnements. Cela dépend surtout de l’organisation de l’entreprise (E1).
Par conséquent, des tests spécifiques sont nécessaires pour vérifier et valider ces activités :
Tests de batch (des jobs et des jobstream) :

  • Tests unitaires – lancement, vérification du traitement désiré, vérification des fichiers log, traces, etc.
  • Tests d’intégration dans les plateformes et environnements

Tests de l’ordonnancement des batchs :

  • Tests unitaires
  • Tests d’intégration dans les plateformes et environnements

Tests des plateformes et environnements :

  • Installations des outils nécessaires
  • Création et paramétrages
Logique exploitation

Logique exploitation