De Winrunner à QF-Test

QF-Test chez CoreMedia :
La robustesse des tests est importante

Extrait d'un article de Mark Michaelis, ingénieur logiciel, assurance qualité, CoreMedia AG, Hambourg, Allemagne :

À propos des mauvais outils d'automatisation des interfaces graphiques : Je pense aussi que l'automatisation des tests d'interface graphique est peut-être l'une des choses les plus difficiles à faire dans le domaine des tests. Il faut une longue évaluation pour obtenir le bon outil d'automatisation, surtout pour en faire accepter un par toute l'équipe.

Pour Java (Swing Applications), nous sommes passés de WinRunner (utilisé depuis des années) à QF-Test. WinRunner n'a pas été accepté par l'équipe en raison de son langage propriétaire, la TSL. En revanche, QF-Test est développé en Java et utilise Jython comme langage de script. Un excellent début pour les développeurs Java. Il y a beaucoup d'autres avantages de QF-Test, mais je n'en mentionnerai que trois ici :

• Comme QF-Test est écrit en Java, il n'a aucun problème pour traiter les dernières versions de Java. Passer du test avec Java 1.5 au test avec Java 1.6 a été un jeu d'enfant
• Les tests peuvent être écrits de manière à ce que les responsables puissent également lire facilement ce que le test fait réellement sans entrer dans les détails.
• Un support important pour les tests pilotés par les données (Data driven Testing). Jamais autant de cas de tests n'ont été effectués en si peu de temps...

A propos de la robustesse de l'automatisation des tests d'interface graphique : Je pense qu'il y a deux choses qui doivent être faites pour que les tests soient aussi robustes que possible. L'une est déjà mentionnée dans l'article de StickyMinds que vous avez cité : Impliquer les développeurs. Il est certain qu'il faut ajouter des crochets de test dans l'application. Le plus simple est de donner aux éléments de l'interface graphique un identifiant unique (en Java : en utilisant setName()).

Ensuite, il faut créer des cartes d'interface graphique (un terme que j'ai appris de WinRunner, mais que j'ai également adopté pour QF-Test) : Placer les règles d'identification des éléments de l'interface graphique dans une base de données/un fichier propre. De cette façon, vous n'avez qu'à toucher ce fichier pour de légères modifications de l'interface graphique.

Mais la meilleure chose à faire est de créer un cadre de test. Par exemple, pour chaque action de menu (chaque au sens de XP : chaque action actuellement utilisée), j'ai créé une fonction de bibliothèque. Les développeurs n'ont qu'à appeler cette fonction de bibliothèque et n'ont pas besoin de se soucier de savoir s'il y a des boutons radio ou une liste déroulante derrière. Si l'élément de l'interface graphique change de type, seul le cadre doit être ajusté.

Des fonctions encore plus complexes ont été déplacées dans le cadre. Par exemple, pour le CMS, j'ai créé des fonctions de cadre qui créent automatiquement des documents (en utilisant l'interface graphique). Il est donc très facile pour les développeurs d'obtenir des montages de test avec lesquels ils peuvent travailler.

Enfin, pour en revenir au code, j'ai ajouté une interface graphique de test à l'application. Cela présente deux avantages :

• Je peux accéder à l'intérieur même de l'application.
• Les développeurs peuvent facilement voir que je fais cela et comment et peuvent donc s'en occuper pendant le remaniement du code.

Le fait d'avoir ces trois choses : GUI Maps, GUI Automation Test Framework, GUI Test Facade J'ai enfin obtenu un ensemble très robuste de tests d'interface graphique.

AdditionalEvaluation report of CoreMedia

(Les textes originaux allemands et les citations sont traduits en français).