Pour vérifier la parité entre un processus en lot COBOL hérité et son remplacement Java, un testeur manuel doit exécuter les deux systèmes avec des ensembles de données d'entrée identiques et effectuer une réconciliation champ par champ. La méthodologie implique un échantillonnage stratifié des enregistrements, en priorisant les transactions de grande valeur, les dates limites (par exemple, 29 février, changements d'année) et les cas limites de virgule flottante, plutôt que de procéder à une comparaison exhaustive. Les testeurs doivent exporter les sorties dans des formats neutres (comme CSV) et utiliser des outils de différenciation tout en inspectant manuellement les champs financiers critiques pour détecter les écarts d'arrondi. Une attention particulière doit être accordée aux conversions de date julienne et au comportement arithmétique des décimales empilées (COMP-3) par rapport aux implémentations de virgule flottante IEEE 754. Enfin, la validation des sommes de contrôle et les comparaisons de hachage de l'ensemble des fichiers de sortie servent de test préliminaire avant de commencer l'analyse détaillée des champs.
Dans une banque multinationale, j'ai été chargé de valider la migration d'un traitement de cumul d'intérêts nocturne d'un système COBOL sur IBM Mainframe vers un microservice Spring Boot fonctionnant sous Linux. Le système hérité avait traité des milliards de transactions pendant des décennies en utilisant l'arithmétique décimale empilée COMP-3 et les formats de date julienne (YYDDD), tandis que la nouvelle application Java utilisait BigDecimal et des calendriers grégoriens standard. Le problème central était d'assurer une sortie identique au bit près ; même une seule différence de centime à travers des millions de comptes constituerait un défaut financier critique, et des différences subtiles dans les modes d'arrondi ou les calculs d'années bissextiles pourraient se traduire par des variations significatives.
Une solution considérée était une comparaison de fichiers exhaustive de tous les enregistrements de sortie. Cette approche offrait une couverture exhaustive et une certitude absolue que chaque octet correspondait. Cependant, les avantages étaient compensés par des inconvénients graves : l'ensemble de données contenait plus de cinquante millions d'enregistrements, rendant la comparaison manuelle humainement impossible dans la fenêtre de traitement de nuit, et le bruit important provenant des variations de métadonnées attendues (comme les horodatages) masquerait les véritables défauts de données.
Une autre option était un échantillonnage aléatoire simple d'un pourcentage fixe d'enregistrements, disons un pour cent. Bien que cela fournisse un aperçu statistiquement significatif et soit rapide à exécuter, les inconvénients étaient inacceptables pour l'audit financier : l'échantillonnage aléatoire pourrait facilement manquer des cas atypiques à fort impact, comme un type de compte spécifique avec des règles d'arrondi uniques ou des transactions se produisant le 29 février 2024, ce qui avait historiquement déclenché des bogues dans la logique de conversion des jours juliennes.
La solution choisie était une stratégie d'échantillonnage stratifié combinée à des scripts de différenciation automatisés pour la validation manuelle. Nous avons catégorisé les enregistrements par niveaux de risque : le niveau 1 incluait tous les comptes avec des soldes dépassant un million de dollars et toutes les transactions aux limites de date (fin de mois, fin d'année, jours bissextiles), tandis que le niveau 2 couvrait des échantillons aléatoires provenant de différents types de produits. Cette approche a été sélectionnée car elle équilibrerait la nécessité d'une certitude absolue sur les transactions à haut risque avec les contraintes pratiques du temps de test manuel.
Pour le niveau 1, nous avons effectué 100 % de réconciliation manuelle au niveau des champs en utilisant Beyond Compare et des scripts Python personnalisés pour mettre en évidence les différences, tandis que pour le niveau 2, nous avons vérifié les sommes de contrôle agrégées et contrôlé des champs individuels au hasard. Le résultat fut la découverte d'un défaut critique où COBOL tronquait les résultats de calcul intermédiaire à cinq décimales, tandis que la division par défaut de BigDecimal de Java maintenait une échelle de manière imprévisible, causant une variance de 0,01 $ sur des comptes à intérêt élevé. Une fois identifiée, nous avons ajusté le mode d'arrondi de Java à HALF_UP avec une échelle explicite, atteignant ainsi une parité parfaite.
Comment détectez-vous la corruption d'encodage lors de la validation de fichiers à largeur fixe migrés de EBCDIC vers ASCII ?
De nombreux testeurs inspectent visuellement les données dans des éditeurs de texte, manquant que les mainframes COBOL utilisent souvent le code page EBCDIC CP037 tandis que les systèmes Java utilisent UTF-8. Des caractères spéciaux comme les symboles monétaires (€, £) ou les lettres accentuées dans les noms de clients peuvent être mal mappés. Pour vérifier, vous devez ouvrir les fichiers dans un éditeur hexadécimal pour comparer les représentations au niveau des octets, en veillant à ce que les espaces finaux dans COBOL (souvent hex 40) ne soient pas confondus avec des terminateurs nuls dans Java (hex 00), et que les champs décimaux empilés (COMP-3) soient déballés correctement sans corruption de bit de signe.
Pourquoi deux calculs mathématiquement équivalents pourraient-ils donner des résultats différents en COBOL par rapport à Java, même lorsque les deux utilisent des types « décimaux » ?
Les candidats supposent souvent que BigDecimal garantit un comportement identique à celui de la décimale empilée de COBOL. Cependant, COBOL effectue une arithmétique en base 10 avec une précision fixe dictée par la clause PIC (par exemple, PIC 9(9)V99), tronquant les résultats intermédiaires à chaque étape d'opération selon les règles de l'entreprise. Java's BigDecimal, par défaut, maintient une précision arbitraire sauf si vous définissez explicitement un MathContext et un RoundingMode. La solution consiste à répliquer la logique de troncature de COBOL en enchaînant les opérations avec des appels setScale() explicites et en faisant correspondre le mode d'arrondi hérité (souvent HALF_UP ou HALF_EVEN) à chaque étape intermédiaire, pas seulement au résultat final.
Comment validez-vous l'exactitude temporelle lorsque le système hérité ignore l'heure d'été (DST) tandis que la nouvelle application Java utilise UTC ou l'heure locale avec une prise en compte de l'heure d'été ?
C'est souvent manqué car les testeurs comparent les horodatages de manière superficielle. Si le travail COBOL hérité s'exécute en EST (Eastern Standard Time) toute l'année tandis que le service Java utilise America/New_York (qui passe à l'EDT), les transactions ayant lieu entre 2 h 00 et 3 h 00 le deuxième dimanche de mars auront un décalage d'une heure. Pour résoudre cela, les testeurs doivent convertir les deux horodatages en un format canonique (par exemple, les millisecondes d'époque UTC) lors de la validation manuelle, vérifier que les paramètres de coupure de traitement de fin de journée (souvent « 23:59:59 ») sont interprétés de manière cohérente et s'assurer que la logique de limite de date (par exemple, « dernier jour ouvrable du mois ») ne change pas en raison de l'heure manquante au printemps ou de l'heure supplémentaire en automne.