QF-Test chez Swiss Life
Depuis 2012, nous utilisons QF-Test pour les tests de régression quotidiens de l’interface graphique de notre nouveau système de devis d’assurance EVApro et nous sommes très satisfaits.
Pour nous, l’utilisation de QF-Test présente principalement les avantages suivants :
- Approache générique: Avec QF-Test, il est possible d’enregistrer les actions de manière élégante pour chaque type de contrôle et de les résumer, par exemple les actions « définir une valeur » et « vérifier une valeur » pour les champs de texte et les zones combinées ou l’action « cliquer » pour les boutons.
- Fichiers de cas de test partagés pour les interfaces HTML et Java: L’application testée existe à la fois dans une variante RAP et une variante RCP. En raison de l’approche générique, il est possible d’utiliser les mêmes fichiers de cas de test (*.xls) pour le test des deux variantes.
- Enregistrement simple au sein de la demande: En raison de l’approche générique, les fichiers de cas test ne contiennent que des données relativement simples telles que (valeur définie, PersonDialog.BirthDate : DATE FIELD, 06/05/1978), grâce auxquelles un contrôle avec l’ID spécifié obtient la valeur de date spécifiée. Ces informations sont enregistrées automatiquement lorsqu’un utilisateur utilise l’application ; lorsqu’il ouvre une boîte de dialogue spéciale de l’application, un tableau apparaît, à partir duquel il peut copier les informations directement dans son fichier de cas test.
-
Petit fichier de la suite de tests, bien structuré et facilement lisible: Nous n’avons besoin pour RAP et RCP que d’un seul fichier partagé de la suite de tests (*.qft), qui est très petit (environ 150 KB) et bien structuré (XML). De plus, il est entièrement lisible : Contrairement à certains produits concurrents de QF-Test, ce fichier ne comporte aucune section cryptée ou propriétaire. Cela facilite aussi grandement la comparaison des différents états de développement de ce fichier dans notre système de gestion des versions.
-
Mise à niveau facile de RAP 1 à RAP 2: En raison de l’approche générique, le passage du PAR 1 au PAR 2 a été facile à réaliser : Seul le fichier de la suite de tests a dû être révisé, et pour la plupart des types de contrôle, il a même suffi de changer la référence de composant « classe », c’est-à-dire le type de composant, du composant générique approprié.
- Soutien compétent: Au cours de plusieurs ateliers d’une journée organisés sur notre site, un employé de Quality First Software GmbH (QFS) nous a apporté un soutien compétent pour développer en permanence le fichier de la suite de tests. En particulier dans le cas de contrôles plus complexes (tels que des tableaux), il nous a aidés grâce à une connaissance approfondie du produit, notamment par l’utilisation de scripts. Les questions posées par courrier électronique entre les ateliers ont toujours reçu une réponse rapide et compétente de la part de QFS.
- Excellente documentation: Le manuel et le tutoriel nous ont souvent aidés. Il est évident que les auteurs ne considèrent pas la documentation comme une corvée, mais sont convaincus de leur produit et veulent le décrire de manière complète et compréhensible. Ils y sont parvenus.
- Des options d’appel très confortables: Comme les valeurs variables peuvent être transmises lors de l’appel à QF-Test, nous sommes en mesure de les déterminer très confortablement grâce aux paramètres d’un fichier batch auto-écrit,
- quels sont les tests à effectuer (les 400 tests sur les 35 tarifs de notre système de devis d’assurance ? Seulement les cas tests d’un tarif donné ? Seulement un cas test particulier ?),
- quelle variante doit être testée (RAP ou RCP ?)
- quel est le niveau de développement à tester (version publiée ou locale instable ?)
- s’il faut déplacer la souris pendant le test
- si le QF-Test doit être lancé de manière interactive ou en arrière-plan
- quel navigateur utiliser dans la version dans le cas du RAP (Internet Explorer ou Firefox ?)
- quelle version de QF-Test utiliser.Chaque paramètre d’appel est soit un numéro (tarif ou test case), soit une lettre unique, donc très simple. Ainsi, notre service peut facilement créer et exécuter des cas de test sans avoir à connaître des détails complexes.
- Des solutions simples pour les changements de version : Pour les tests de régression de l’interface graphique, plusieurs applications doivent fonctionner ensemble :
- dans la variante RAP : le navigateur dans lequel l’application réelle est exécutée (par défaut Internet Explorer)
- le programme dans lequel les fichiers de cas test sont présents (Excel)
- l’outil de test de l’interface utilisateur graphique (QF-Test).
- Dans ces interactions, des problèmes peuvent bien sûr survenir si la version d’une des applications concernées est modifiée. Nous avons donc, par exemple, comme solution de contournement
- a testé la variante RAP avec une version de QF-Test différente de la variante RCP
- a utilisé à la place de la version actuelle d’Internet Explorer une version plus ancienne de Firefox dans la variante RAP.Ces solutions de contournement nous ont toujours aidés jusqu’à présent à faire le pont entre le moment où le fichier de la suite de tests était révisé lors d’un atelier ultérieur, où une nouvelle version de QF-Test était fournie ou où une version améliorée d’Internet Explorer était disponible. Grâce aux méthodes très confortables mentionnées ci-dessus, nous avons pu mettre en œuvre et défaire ces contournements toujours de manière relativement aisée.
Nous pouvons donc absolument recommander l’utilisation de QF-Test.
Auteur:
Dirk Stanke
Contact:
Max Gest
Application manager EVApro
Swiss Life AG, German Branch
Berliner Straße 85
80805 Munich
(Les textes originaux allemands et les citations sont traduits en français).