Dix règles pour la gestion des tests SAP

Pas tous, mais beaucoup d'obstacles dans la gestion des tests peuvent être éliminés à l'avance grâce aux règles suivantes.

Règle 1

Rédigez un concept de test : pourquoi l'équipe de gestion des tests devrait-elle faire l'effort de rédiger et de faire approuver un concept de test alors que les ressources sont limitées et que les délais sont serrés ?

Tout l'art consiste à garder le concept aussi bref et concis que possible et à représenter par des graphiques des faits complexes, comme par exemple un environnement de test avec de nombreuses interfaces.

Parmi les éléments essentiels d'un concept de test, on trouve par exemple la définition des objets et des objectifs du test, des critères d'acceptation et de la procédure d'acceptation, ainsi que la représentation de l'infrastructure de test (systèmes SAP, voies de transport, dates de transport). Faites approuver le concept par le développement et les spécialistes.

Règle 2

Investissez suffisamment de temps dans la qualité des cas de test. Les départements spécialisés n'ont souvent pas le temps de créer les cas de test. Par conséquent, ceux-ci sont "recyclés" à partir d'anciens projets, sont trop généraux, trop granulaires ou ne concernent pas les fonctions à tester et à réceptionner.

Résultat : les testeurs spécialisés testent trop ou trop peu, mais pas les fonctionnalités nécessaires. Les progrès sont trop lents, le taux d'erreur trop élevé et les améliorations de la qualité trop faibles. Les départements spécialisés (et non l'informatique) devraient absolument prendre le temps nécessaire à la création des cas de test.

Règle 3

Hiérarchisez vos cas de test. Souvent, le département spécialisé A souhaite tester toutes les nouvelles fonctionnalités dans les moindres détails et soumettre le logiciel déjà implémenté à un test d'intégration complet, y compris le test par lots et le test de bout en bout, en intégrant des systèmes tiers et d'autres systèmes.

Le département B, quant à lui, choisit, en fonction des délais et des ressources, une approche pragmatique avec seulement quelques cas de test. Il est important de trouver la bonne mesure pour l'étendue des tests.

Une bonne pratique consiste à classer les cas de test par ordre de priorité. Une bonne approche est le Risk-Based-Testing. Ici, les cas de test sont notamment pondérés en fonction de l'ampleur des dommages en cas de dysfonctionnement.

Règle 4

Prévoyez plusieurs cycles de test. Le premier cycle de test démarre généralement de manière très chaotique. Il y a des blocages, les testeurs ne connaissent pas encore l'application et de nombreuses erreurs se produisent.

Le nombre élevé de corrections peut entraîner des effets de bord qui nécessitent de retester des cas de test déjà terminés avec succès. En moins de temps qu'il ne faut pour le dire, le cycle de test est terminé.

Faites donc une pause après le premier cycle et donnez au développement la chance de corriger toutes les erreurs critiques. Lancez ensuite un nouveau cycle avec un état consolidé des logiciels et des données, au cours duquel vous testerez au moins tous les cas de test classés élevés et moyens du premier cycle.

Règle 5

Occupez-vous à temps de l'environnement de test. Une situation typique : les cas de test sont prêts, les collaborateurs du domaine spécialisé veulent commencer, mais le test ne peut pas être lancé parce que le système SAP n'est pas disponible.

Les raisons en sont multiples. Le système n'a pas été réservé à temps et est occupé par d'autres projets. Ou encore, le développement n'a pas pu déployer le logiciel sur les systèmes de test ou ne l'a pas fait complètement.

Souvent, il manque aussi des interfaces importantes et nécessaires ou des ID d'utilisateur et des autorisations appropriées. Planifiez donc votre environnement de test suffisamment tôt et surveillez son déploiement complet et correct.

Vous posez le premier pilier en définissant les critères d'entrée du test dans le concept de test. Si des conditions essentielles ne sont pas remplies, vous ne démarrez pas du tout.

Définissez précisément dans le concept ou dans un plan d'environnement de test quels systèmes SAP avec quel stock de données sont nécessaires et à quel moment, quelles interfaces doivent être connectées via quels systèmes tiers, quels ID d'utilisateurs avec quelles autorisations doivent être mis à disposition et quand les corrections logicielles doivent être transportées.

Règle 6

Utilisez un outil intégré de gestion des tests et des défauts. L'outil le plus souvent utilisé pour la gestion des tests et des défauts est Excel.

Cela fonctionne très bien jusqu'à un nombre de 100 à 150 cas de test avec un faible volume de défauts. Dès que le volume augmente, il devient de plus en plus problématique de s'en sortir avec ses propres solutions Excel.

En particulier, il manque souvent une vue d'ensemble des défauts et des cas de test. Il est également difficile de générer l'état global actuel ou l'avancement des tests, le cas échéant avec des prévisions.

Souvent, les feuilles de calcul Excel (et surtout les macros) ne peuvent être entretenues que par quelques personnes ou, dans le pire des cas, par un expert.L'utilisation d'un outil intégré de gestion des tests et des défauts est un meilleur choix.

Pour les utilisateurs SAP, les composantes Test Workbench et Help Desk de SAP Solution Manager s'imposent. Ils n'entraînent pas de frais de licence, l'effort de mise en œuvre est gérable (trois à cinq jours-personnes) et les utilisateurs sont familiarisés avec les interfaces SAP.

Règle 7

Réalisez un test de lancement. Les efforts que vous investissez dans un kick-off bien préparé sont récupérés dans les tests quotidiens.

Des sujets tels que les objectifs, les procédures, les délais, les portes de la qualité, les contraintes de test, le reporting des tests et des défauts ainsi que les réunions de règles et les téléconférences doivent figurer à l'ordre du jour.

Même s'il y a beaucoup de participants, invitez toutes les personnes concernées comme les testeurs spécialisés, l'équipe de gestion des tests, le développement, le cas échéant le contrôle des lots et la direction du projet au kick-off.

Cela facilite la communication ultérieure et permet d'éviter de nombreuses questions inutiles. Ce qui a fait ses preuves, c'est de mettre à disposition les documents de lancement et les rapports d'état, mais aussi les concepts, dans un média facile d'accès comme MS SharePoint.

Règle 8

Ne commencez pas les tests trop tôt. Le scénario habituel : les dates de test et d'acceptation sont fixées. Les testeurs spécialisés sont planifiés. Les décideurs veulent que le projet soit un succès.

Et l'équipe de développement se bat encore contre de graves et/ou nombreuses lacunes dans le logiciel. Le responsable du développement souhaite repousser le test ; la direction du projet veut tenir la date à tout prix.

Souvent, on cède au désir des responsables et on lance le test en connaissant les déficits et les risques qui y sont liés. Que se passe-t-il ?

Les premiers tests d'acceptation peuvent encore se dérouler de manière positive. Mais ensuite, on trouve beaucoup d'erreurs, il y a des blocages de test. Les testeurs sont frustrés. Et surtout, cela se répercute négativement sur les comités de projet, sur les services spécialisés impliqués et, dans certaines circonstances, sur la direction.

D'où la recommandation suivante : même si vous êtes soumis à une forte pression pour respecter la date prévue de début des tests techniques, reportez les tests si le logiciel n'est pas encore prêt à être testé. Vous vous épargnez ainsi qu'aux testeurs beaucoup d'ennuis et évitez surtout de nuire fortement à l'image de votre projet.

Que peut-on faire à titre préventif ? La définition et le contrôle de quality gates ont fait leurs preuves. Définissez dans le concept de test les conditions préalables qui doivent être remplies pour le lancement des tests.

Il s'agit par exemple de la preuve de tests de développement documentés, de la création d'une documentation utilisateur, de la mise à disposition de l'infrastructure de test ainsi que de la liste des erreurs non résolues avec une date de correction. Si la Quality Gate n'est pas respectée ou si elle ne l'est pas suffisamment, il n'y a pas de go pour le test.

Règle 9

Interrompre les tests en cas de blocage des tests. L'absence de fonctionnalités importantes, un nombre élevé de bugs ou des restrictions dans l'infrastructure de test, comme des systèmes non performants, peuvent entraîner des blocages de test.

Les testeurs ne peuvent pas démarrer en raison de la situation globale actuelle. En parallèle, il y a une forte pression pour effectuer des travaux de routine au bureau. Bien sûr, il n'est pas amusant de renvoyer les testeurs chez eux dans des fenêtres étroitement synchronisées.

Mais les conséquences négatives telles que des testeurs insatisfaits et la panique dans les départements spécialisés ou éventuellement au sein du conseil d'administration en raison de la qualité insuffisante du logiciel sont, en cas de doute, plus importantes. Vous pouvez profiter de l'interruption pour consolider le logiciel.

Règle 10

Communiquez avec les testeurs. Un facteur de réussite essentiel pour votre projet est la communication régulière avec les testeurs. Il est important d'être transparent sur la situation actuelle, l'état des erreurs, les restrictions, etc. Organisez régulièrement des réunions sur le statut et les erreurs avec les testeurs et le développement.

Les réunions quotidiennes de type "stand-up" ont par exemple fait leurs preuves. Essayez de parler directement à chacun d'entre eux chaque jour afin d'en savoir plus sur les situations concrètes de test et d'erreur présumée. Faire appel à des développeurs pour tester ou retester des erreurs dans des situations complexes a également fait ses preuves.

Conclusion

Chaque projet de gestion des tests dans l'environnement SAP se déroule différemment et le déroulement parfait du projet n'existera jamais. Mais beaucoup de choses seront plus faciles avec les règles de base mentionnées ci-dessus.

En fin de compte, il s'agit d'amener la qualité du logiciel à un niveau nécessaire pour l'exploitation productive dans le cadre d'un processus accepté par tous les participants. Le fait que toutes les erreurs ne soient pas corrigées avant le "going live" est plutôt la règle que l'exception.