Pourquoi avons-nous choisi QF-Test plutôt que Squish ?

Rapport d'évaluation QF-Test du groupe R.J. Lee

L'équipe de QF-Test m'a demandé comment nous avons choisi et utilisé QF-Test ici à RJ Lee Group. J'ai fait des recherches sur une douzaine de programmes de test GUI ; seuls QF-Test et Squish semblaient pouvoir répondre à nos besoins. J'ai téléchargé les versions d'évaluation des deux, les ai configurées pour notre système, et ai écrit quelques tests dans les deux. J'ai expliqué les deux à notre testeur manuel et l'ai laissé les essayer. J'ai également expliqué les deux à notre développeur principal. Ensuite, nous en avons discuté tous les trois, nous avons constaté que les deux répondaient à tous nos besoins techniques, puis chacun d'entre nous a choisi individuellement QF-Test plutôt que Squish.

Voici pourquoi :

• J'ai été en mesure d'installer QF-Test sans un seul e-mail de support technique parce qu'il a une meilleure documentation et une meilleure qualité de code. (Le manuel continue d'être très utile, il est facilement consultable lorsque je dois faire référence à quelque chose).
• La base de données des widgets/composants de QF-Test est plus organisée que celle de Squish, et permet de remanier les noms des widgets plus facilement.
• C'était important pour nous car notre application comporte de nombreux champs, qui changent de nom et de fonction en fonction de l'évolution des processus métier.
• Notre chef d'équipe a apprécié que les langages de script de QF-Test soient des langages JVM, contrairement à Squish.
• Notre ancien testeur manuel, devenu testeur d'automatisation et d'exploration, était plus à l'aise avec l'interface de QF-Test pour enregistrer les clics.
• Le facteur décisif le plus important était que QF-Test pouvait parfois forcer la mise au point de l'USE, mais personne n'aimait le fait que Squish envoyait les événements scriptés à la fenêtre sur laquelle l'OS mettait le focus. Avec QF, nous pouvions effectuer plusieurs tâches pendant que le script s'exécutait en arrière-plan.

Nous automatisons nos tests plus rapidement que l'ajout de nouvelles fonctionnalités, de sorte que les tests augmentent à chaque version. C'est bien mieux que le document de test manuel qui s'allongeait à chaque version :-)

J'ai utilisé des scripts Jython pour chronométrer des actions de test comme la recherche, l'ouverture d'enregistrements et le démarrage de l'application. Les résultats du chronométrage (avec le numéro de build et l'hôte) sont enregistrés dans une base de données, ce qui nous permet de suivre les performances avec une granularité beaucoup plus grande. Nous utilisons également des actions en boucle pour trouver les fuites de ressources.

J'aime beaucoup les scripts dans la JVM. Pouvoir stocker le contenu d'un champ de texte dans une variable pour une vérification ultérieure est formidable. Il en va de même pour savoir combien d'éléments se trouvent dans un tableau avant et après l'application d'un filtre. Au fur et à mesure que QF-Test s'installe dans notre environnement de développement, je passe plus de temps à écrire des tests en Jython. C'est le domaine dans lequel je pense que QF-Test pourrait être amélioré. J'aime ce qu'il peut faire maintenant - mais vos ingénieurs peuvent-ils faire en sorte que l'intégration des scripts fasse autre chose de cool ? Je fais des choses comme ouvrir une série d'enregistrements et trouver le temps moyen d'ouverture, changer chaque champ dans un formulaire et vérifier les exceptions dans le journal, essayer de casser le filtre en exécutant des permutations de chaînes de recherche, etc.

Vous faites un outil formidable. Merci,

Logan White Stack du groupe R.J. Lee