Les mauvaises pratiques observées

1. Ne pas structurer les tests en niveaux

Nous avons vu dans le second chapitre dédié à la gestion des releases qu’une mauvaise pratique consiste à ne pas définir une décomposition en cycles de celles-ci. Découlant de cet usage inapproprié, l’absence de classification des tests en niveaux s’observe alors.

Concrètement, cela se traduit par l’absence de folders regroupant les tests d’un même niveau, voire même en sous-niveau.

Nous rappelons ici le nom complet de notre outil : "Application Lifecycle Management Quality Center". Comme son nom l’indique, notre outil a pour rôle de couvrir l’ensemble des tests d’une release, donc l’ensemble de sa chronologie.

Ne pas structurer les tests selon cette dernière revient donc à ne pas afficher la lisibilité même du projet.

Malheureusement, force est de constater que nous avons observé cette mauvaise pratique trop fréquemment, et cela, à la fois dans les modules Release et Requirements en conjonction.

Si l’on considère maintenant l’unique niveau de test des technico-fonctionnels d’une équipe dédiée aux tests, les catégories d’exigence et les sous-niveaux de test devraient coïncider.

Mais là encore, nous observons cette mauvaise pratique : il est fréquent que les tests technico-fonctionnels de ce niveau ne soient pas classés...