À propos de CoreMedia
CoreMedia est le leader des logiciels sociaux innovants centrés sur les personnes. La société, basée à Hambourg, en Allemagne, a réussi à se positionner sur le marché très dynamique de la technologie Internet. L’entreprise se caractérise par sa culture innovante et créative, et par l’accent mis sur l’apprentissage collectif. Ces valeurs se retrouvent également dans la technologie de CoreMedia : CoreMedia développe des logiciels qui permettent à son personnel, ses partenaires et ses clients d’atteindre leurs objectifs rapidement, de manière créative et productive.
Fondée en 1996 et basée à Hambourg, en Allemagne, CoreMedia compte plus de 150 employés et entretient un réseau mondial de partenaires de mise en œuvre qui comprend 500 consultants professionnels.
ÜPlus de 200 sociétés dans le monde entier font confiance aux solutions de gestion de contenu (CMS) et de gestion des droits numériques (DRM) de CoreMedia, notamment ARD, Bertelsmann, BenQ, BILD, Continental, DAK, DaimlerChrysler, debitel, Deutsche Telekom, GMX, IKK, NEC, MLP, Motorola, Nokia, O2, Panasonic, Plus, PREMIERE, Quelle, Qualcomm, Samsung, SEAT, Sony Ericsson, T-Mobile, T-Online et Vodafone. CoreMedia est également à la base des services en ligne fournis par plus de 80 institutions publiques et organismes administratifs.
CoreMedia a reçu de nombreux prix internationaux ces dernières années, faisant l’éloge de sa culture et de ses logiciels innovants, notamment le European Business Award, la reconnaissance en tant que meilleur innovateur, et l’inclusion dans la liste Deloitte Technology Fast 50 des entreprises à croissance rapide.
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).