Si vous ne pouvez pas le tester, ne le faites pas

Dans le domaine des applications IBM i, le mantra “Si vous ne pouvez pas le tester, ne le faites pas” sert de rappel crucial. Les tests jouent un rôle primordial dans la garantie de la sécurité et de la fiabilité des données critiques et des applications sur la plateforme IBM i. Ce principe souligne l’importance de tester rigoureusement tout changement, mise à jour ou modification avant de les mettre en œuvre. L’affirmation résume l’idée qu’une précipitation dans les changements sans un test adéquat peut entraîner des complications imprévues, mettant potentiellement en péril l’intégrité de l’environnement IBM i. En respectant des pratiques de test rigoureuses, les organisations peuvent atténuer les risques, identifier les vulnérabilités et maintenir la robustesse de leurs applications IBM i, favorisant un environnement informatique stable et sécurisé.

Nous comprenons tous l’importance des tests.

Dans chaque industrie, les tests et la validation sont des éléments fondamentaux du développement de produits et représentent de 20 à 30 % du coût de développement. (réf. McKinsey – “Testing and validation: From hardware focus to full virtualization?”)

La société leader planifie des scénarios de tests et de validation à travers les fonctions et intègre les procédures de tests et de validation des clients dès le début du processus de développement.

Ils exploitent largement la simulation virtuelle et font des tests virtuels une condition préalable à tout test physique.

Ils modifient leurs processus de développement de produits (PDP) en intégrant des boucles de simulation virtuelle, et ils mettent en place des boucles de rétroaction et d’amélioration solides à chaque étape des tests.

Qu’en est-il de la pratique des tests sur la plateforme IBM i ?

Dans l’industrie du logiciel, les tests virtuels sont le paradigme, donc les tests devraient être plus accessibles, mais nous pouvons encore constater que les tests sur la plateforme IBM i ne sont pas encore aussi bien intégrés qu’ils devraient l’être. 

Les tests sur la plateforme IBM i peuvent ne pas être aussi populaires en raison de plusieurs facteurs :

1. Systèmes hérités : La plateforme IBM i héberge souvent des applications héritées qui ont été développées avant que les pratiques de tests modernes ne gagnent en importance.
2. Écart de compétences : Il peut y avoir une pénurie de testeurs familiarisés avec les subtilités spécifiques des tests sur l’environnement IBM i.
3. Stabilité perçue : Certaines organisations considèrent les applications IBM i comme stables et fiables, ce qui conduit à moins d’accent mis sur les tests.
4. Contraintes de ressources : Des ressources limitées, y compris le temps et le budget, peuvent conduire à des efforts de test réduits.
5. Manque d’outils : Il peut y avoir un manque d’outils de test spécialisés pour la plateforme IBM i.
6. Critique pour l’activité : Les organisations peuvent considérer les applications IBM i comme critiques pour l’activité, ce qui conduit à une réticence à apporter des modifications nécessitant des tests.
7. Facteurs culturels : La culture d’entreprise et les pratiques historiques peuvent influencer les priorités en matière de tests.

Malgré ces défis, la modernisation des pratiques de tests et la reconnaissance de l’importance des tests rigoureux peuvent contribuer à résoudre ces problèmes et à garantir la qualité des applications IBM i.

Les tests de logiciels suivent un processus commun

Les tests de logiciels impliquent un processus structuré avec diverses tâches et étapes pour garantir la qualité des applications:

1. Définition de l’environnement de test : Cela englobe des tâches telles que la préparation des identifiants de connexion et l’initialisation des données.
2. Développement des cas de test : Cela implique la création de scénarios complets pour valider la fonctionnalité de l’application.
3. Sécurité/Autorité : Les tests comprennent l’examen des différents niveaux d’accès utilisateur à des fins de sécurité.
4. Écriture de scripts : Génération de scripts détaillés comprenant les saisies de données et la navigation.
5. Exécution des scripts : Permet d’exécuter les tests et idéalement, vous voudrez être en mesure de revoir l’enregistrement du test en cas d’erreurs plutôt que de devoir refaire tout le test depuis le début.
6. Analyse des résultats des tests : Implique la sélection des éléments à comparer et la réalisation de comparaisons.
7. Soumission de rapports : Les rapports de défaut ou de succès impliquent la documentation des problèmes, la tenue de registres et la création d’indicateurs de performance clés.
8. Englobant Pgm, DB et UI : Les tests devront couvrir la logique du programme, les bases de données et les interfaces utilisateur, y compris les écrans 5250 pour la plateforme IBM i.

Faire face, analyser et éventuellement résoudre tous ces points aidera certainement à rendre les tests plus accessibles sur la plateforme IBM i.

IBM i Test de bout en bout

La figure 1 illustre les fonctionnalités qu’un outil de test de bout en bout devrait couvrir.   

Figure 1 – Test de bout en bout IBM i

Plus ces fonctionnalités sont automatisées, plus il est probable que l’outil soit accepté par les utilisateurs finaux.

Mais ce n’est pas tout, ce qui est également pertinent, c’est l’expérience utilisateur lors de l’enregistrement du scénario de test et la flexibilité pour corriger l’enregistrement réalisé. Imaginez que vous ayez enregistré un cas de test impliquant une fonction interactive avec 30 écrans et qu’à la fin, vous vous rendez compte que vous avez saisi les mauvaises données sur l’écran 25… la dernière chose que vous voulez faire est de tout recommencer à zéro. Si l’outil pouvait permettre la flexibilité de le corriger sans avoir à refaire l’enregistrement, ce serait un grand avantage pour l’utilisateur final.

La Figure 2 illustre la fonctionnalité relative à la flexibilité de correction de l’enregistrement.

Figure 2 – Flexibilité pour corriger l’enregistrement du test

Couverture de code

Un autre point précieux est l’intégration de la fonctionnalité de la couverture de code. Cette fonctionnalité est disponible avec l’API IBM lancée par la commande système CODECOV.

RDi l’intègre et offre la possibilité de visualiser les lignes de code réellement exécutées par un programme. Cela signifie qu’en exécutant un test, il devient possible de voir quelles lignes de code ont été exécutées et lesquelles ne l’ont pas été, ce qui donne également le pourcentage de lignes de code parcourues par le test. Il s’agit d’une information précieuse, car si nous obtenons par exemple une couverture de code de 30%, nous comprendrions que notre test n’est pas suffisant. Ce que nous rechercherions serait au moins une couverture de 80%. Il s’agit d’un indicateur clé de la qualité du test global.

Maintenant, pour obtenir une couverture de 80%, nous devrons peut-être exécuter le même programme (c’est-à-dire le même test) plusieurs fois avec des données d’entrée différentes. En fin de compte, nous créerons différentes variantes de tests et devrons fusionner leurs couvertures de code respectives. La fusion nous dira donc quelle est la couverture de code globale de toutes les lignes de code à travers toutes les variantes de test.

Disposer d’une information de fusion de la couverture de code dynamique disponible grâce à une UDF SQL dans un processus de flux de travail automatisé axé sur les tests est évidemment bienvenu.

La Figure 3 illustre les fonctionnalités de la couverture de code et de la fusion de la couverture de code.

Figure 3 – Fusion de la couverture de code et KPI

Si vous souhaitez en savoir plus, vous pouvez visiter la page produit ReplicTest.