QF-Test chez Thales Australia:
Gagner du temps avec les tests

Disons que l'automatisation de nos tests est un succès et que c'est un grand pas en avant. Je ne suis pas un expert de tous les autres outils disponibles, mais d'après ce que je sais, je ne vois pas comment j'aurais pu interfacer d'autres outils que QF-Test avec notre système, en outre dans un délai aussi court.

Les quelques points qui font de QF-Test l'application tueuse :-)

  • Une IHM mature et complète pour concevoir la suite de tests.
  • Un rapport synthétique généré automatiquement en HMTL.
  • Pas besoin de pirater la JVM ou l'application testée pour rendre les choses testables.
  • Scripting en Jython : Vous pouvez faire tout ce dont vous avez besoin avec cela.
  • Extension API : Elle permet de rendre QF-Test conscient des objets internes à l'application GUI.

En ce qui concerne le degré d'intégration du QF-Test dans notre processus : Nos tests de non-régression ont été presque entièrement mis en œuvre dans le cadre du QF-Test. Il prend environ trois heures à exécuter et me fait donc gagner beaucoup de temps.

En termes de retour sur investissement, il y a plusieurs aspects : En ce qui concerne le gain de temps, il me fallait généralement une journée entière pour effectuer les tests de non-régression. Ce délai a été réduit à trois heures. La grande différence, c'est que je peux faire autre chose avec le temps gagné ! L'avantage direct est que je peux maintenant effectuer des tests sur différentes versions de notre système (c'est-à-dire différentes branches) en parallèle, alors que c'était impossible auparavant (pas assez de temps).

Un autre aspect moins visible est qu'il améliore la communication avec le développement de logiciels. Il n'y a pas de "sentiments" ou de jugement personnel dans l'évaluation des résultats. Il est arrivé auparavant que les résultats soient légèrement différents selon la personne qui effectuait les tests. En effet, comme je l'ai mentionné, il s'agit d'un système en temps réel et, selon l'action que vous effectuez à un moment donné, le comportement du système peut ne pas être toujours le même. Le fait d'avoir automatisé les tests supprime (ou diminue) ces problèmes de temps.

Le développement logiciel ne peut plus dire que vous avez bourré ou mal utilisé le système pendant les tests (et vous demander de les refaire et donc de gagner du temps ...). Ce sont toujours les mêmes tests qui sont reproduits et si les résultats changent, c'est parce que le Système a changé. Parfois, les changements sont bons (amélioration des fonctionnalités, correction des bugs, temps de réponse plus rapide ....) mais l'automatisation reprend cela, ce qui est tout l'intérêt du test NRG : détecter les changements.

L'automatisation des tests présente cependant quelques inconvénients :
Premièrement, les tests doivent être maintenus ! Le SUT évolue et les composants doivent être mis à jour. De nouvelles fonctionnalités sont également introduites et doivent être ajoutées dans le champ d'application des tests.
Ensuite, les tests ne sont pas parfaits : ils ne sont pas à l'épreuve des balles et parfois un problème peut générer un effet domino et annuler le résultat complet. Si vous n'êtes pas devant la machine pendant le test, vous ne la verrez pas et perdrez peut-être trois heures. Donc, à chaque fois que cela se produit, je corrige le test et j'ajoute d'autres contrôles et protections. Mais de temps en temps, je dois relancer le test.

Le QF-Test ne détectera alors que les problèmes que vous lui avez appris à reconnaître. En comparaison, un testeur humain serait capable de détecter des comportements étranges du système. Encore une fois, c'est en temps réel et avec beaucoup d'algorithmes. Tout n'est pas prévisible. Cela signifie que des problèmes peuvent ne pas être détectés par QF-Test (ou plus précisément par la suite de tests que j'ai écrite). Ces problèmes sont généralement détectés plus en aval de la chaîne de test (IBB, V&V Testing ...), mais leur correction coûte alors un peu plus cher. Chaque fois que cela se produit, j'essaie d'améliorer la suite de tests, ce qui prend un peu de temps.

Vous vous demandez peut-être alors s'il y a un réel avantage à automatiser les tests :-\
Ma conclusion serait toujours oui, mais le retour sur investissement n'est pas à la hauteur. Le temps que vous ne passez plus sur les tests doit être consacré à différents sujets : la maintenance, les améliorations, l'analyse de ce que vous voulez tester et de la manière dont vous voulez le tester (pas toujours aussi simple qu'on pourrait le penser). Le gain que vous obtenez porte sur la qualité et la cohérence.

Denis Gauthier Intégration de logiciels, Thales Australie, Melbourne