Comparaison QF-Test vs. WinRunner
Introduction
QF-Test est un outil de test GUI écrit en Java et avec Jython comme langage de script. En décembre 2005/janvier 2006, nous avons évalué cet outil pour savoir s’il pouvait servir de nouvel outil de test GUI pour le SwingEditor de notre produit CMS. Ce document contient l’information qui a causé la décision pour ou contre le nouvel outil de test GUI.
Cible
L’objectif du processus d’évaluation est de décider si nous voulons remplacer (au moins pour le développement futur) WinRunner comme outil de test GUI par QF-Test et de documenter les raisons de cette décision.
Conclusion
La conclusion n’a pas été faite pendant la phase d’évaluation car d’autres options ont été prises en compte pour créer plus de tests pour le Swing Editor. Mais finalement nous avons décidé d’acheter des licences de QF-Test.
Epilogue
Tout comme la conclusion qui a été retardée après la création du rapport d’évaluation, cet épilogue ne fait pas non plus partie du rapport d’évaluation original. Tout le reste est tel quel, c’est-à-dire que vous pouvez simplement lire le rapport original d’il y a maintenant presque deux ans.
Aujourd’hui, nous utilisons toujours QF-Test – et nous utilisons toujours WinRunner, car nous n’avons pas réussi à trouver le temps de convertir les tests dans WinRunner en tests dans QF-Test. Il n’y a aucun moyen de convertir automatiquement ces tests et donc chaque test doit être converti à la main. Mais nous sommes sur la bonne voie. Certains tests ont déjà été déplacés.
Je suis toujours heureux que nous ayons pris la décision de passer à QF-Test. Alors que je dois toujours maintenir les tests WinRunner et que j’ai récemment eu de gros problèmes avec Java 1.6 et Windows Vista, QF-Test fonctionne aussi bien sur Java 1.6/Windows Vista que sur Windows XP avec Java 1.5 ou 1.4.
C’est toujours un plaisir d’écrire des tests dans QF-Test car ils sont faciles à créer. Dans une certaine mesure, je pourrais dire que c’est le framework que j’ai construit entre-temps. Il me permet d’avoir des tests qui lisent dans l’arbre de code comme :
- Créer le document « A
- Ecrire du texte dans le document
- Enregistrez
- Faire des vérifications
Où chaque ligne pointe vers une fonction/procédure dans le cadre que j’ai construit. Mais c’est QF-Test qui m’a permis de construire un tel cadre.
De même, les développeurs de CoreMedia qui n’écrivent pas de QF-Test tous les jours se sentent très à l’aise avec QF‑Test. La plupart du temps, il me suffit de les présenter pendant une ou deux heures et ils commencent tout de suite.
QF-Test s’améliore encore de version en version. Il n’est donc pas étonnant que certains défauts que j’ai mentionnés aient été corrigés entre-temps. Comme par exemple le « lazy variable expansion bug » comme je l’appelle, qui n’était pas un bug mais une approche différente pour gérer l’expansion des variables. Et d’excellentes nouvelles fonctionnalités ont été introduites, comme les dépendances que j’utilise beaucoup entre-temps.
Et un dernier mot sur la taille de l’entreprise : Bien sûr, je me suis complètement trompé sur la taille de l’entreprise et je suis heureux de connaître d’autres personnes à QFS maintenant.
Mark Michaelis, ingénieur logiciel assurance qualité, testeur certifié ISTQB
Le rapport d’évaluation complet peut être consulté ici (PDF).
Évaluation de QF-Test/qftestJUI chez CoreMedia, January 2006 – Mark Michaelis, CoreMedia, Allemagne.
(L’ancien nom qftestJUI est remplacé par QF-Test).
