• Encapsulation automatisée des tables de base de données. Identification, restauration et comparaison automatiques pour tous les environnements de test (5250, Web, batch).
• Détection des différences dans les données, l’interface utilisateur et les spools (différences entre les écrans/ champs ajoutés, modifiés /longueurs de champs)
• Simplification et optimisation du processus de réinitialisation des données (garantissant la reproductibilité des tests) en sélectionnant automatiquement uniquement les fichiers et tables nécessaires à chaque scénario de test.
• Création de sous-ensemble de données réellement utilisées par le scénario de test pour réduire les délais d’exécution et augmenter la fréquence des replays.

• Détails des lignes et du % de code couvert par un seul test ou merge des lignes et % par plusieurs tests (permet aussi de retracer toute surcharge du processus).
• Lors de la modification d’un objet, identification des tests qui l’impliquent, pour les relancer.
• Détection des modifications de programme non couvertes par un cas de test
• Récupération dynamique des infos via une UDF SQL ou dans un flux de travail automatisé.
• « Moteur d’encapsulation » intégrant n’importe quel objet (spool, dtaara, dtaq, objets IFS, joblog, etc…)

• Une seule commande pour enregistrer (à partir des actions de l’utilisateur) ou rejouer les scénari de test : la commande détecte automatiquement dans quelle modalité (enregistrement ou replay) elle doit s’exécuter et adapte son comportement pour copier, restaurer ou comparer les images de données.
• Enregistrement de scénari de référence, partage possible des scenari (enregistrement par l’utilisateur final du scénario de test, utilisé par le développeur lors du déploiement).
• Nombreuses options disponibles : créer des variantes de test en rechargeant un même jeu de données initiales, contourner les timestamps pour les comparaisons de replays, corriger les scenari/web services en cours…
• Rapports personnalisables (tendance état des tests / log messages avec lignes de code impliquées / %age couverture code / temps gagné).
• Masquage possible des sets de données présentés dans un dashboard.

• Planification automatique, en séquence ou en parallèle, avec un login identique ou différent.
• Lancement automatique avec différentes options, via d’autres commandes ou scripts
• Enregistrement de l’état des tests, des accès à la base de données, y compris les piles d’appels (call stack), des messages pertinents en cas d’échec et des métadonnées contextuelles (avec possibilité de laisser le job ouvert).
• Tests possibles selon les différentes autorités utilisateurs