KDT et Ranorex

blog-post

Ranorex est l'un des outil de tests fonctionnels les plus utilisés du marché. Il présente la particuarité de pouvoir piloter des applicatons sur diverses plateformes: Windows, Web, mobiles. Ranorex reprends la syntaxe Xpath, l'enrichit et l'utilise pour repérer tout élement faisant partie d'une application. Afin didentifier dun bouton dans un formulaire sur une page web, la syntaxe utilisée est composée de 2 parties;

  • Identification du navigateur: TODO; jouter syntaxe
  • Requête Xpath habituelle permettant d'identifier l'objet dans le document html, //div/form[@name='fooForm']/button[#'btnSend']

En combinant les différentes facilités et concepts mises à disposition par Ranorex: Modules, repository des élements, SmartForlders, Test cases, Test Suites..., il est possible de créer des tests structurés, réutilisables et paramètrables

Ranorex permet d'utiliser diverses sources de données, allant de simples fichiers CSV, fichiers excel vers des datasources de bases de données à travers les API .Net uxquelles il a accès naturellement, grâce à l'ecosystème Microsoft dans lequel il évolue

Dans un projet d'automatisation des tests, il est utile de rappeler les divers contributeurs qui peuvent y intervenir. La MOA qui défnie les scénarios de tests à coder, les developpeurs qui produisent du code et requiert d'assurer la non regression, et bien évidemmen l'équipe automatisation qui a la charge de créer et maintenir les cas de tests sous le système de testing choisi.

Dans la pratique, l'équipe MOA fournit les cas de tests aux spécialistes d'automatisation. Qui créent le code représentatif des scénarios, et le mettent à disposition pour l'exécution. A ce niveau là, plusieurs techniques d'exécution et de publication des résultats peuvent être utilisés, parmi lesquelles nous citons

  • le lancement manuel la demande
  • le lancement automatique lors de chaque génération (Build) du code source
  • le lancement automatisé planifié (à une heure en dehors des plages où l'environnement n'est pas monopolisé pour une campagne de test de recette...)
Le jeu de données joue un role important, il est utilisé pour à la fois pour :
  • introduire les données nécessaires à l'exécution des tests
  • Déterminer le chemin d'exécution des modules à exécuter pour constituer la fonctionnalité à tester
  • Je donne l'exemple d'un choix de livraison de colis, si l'adresse de livraison est différente de l'adresse de la facturation, il est nécessaire d'appeler le module de sasie d'adresse une fois de plus.
D'une part, Les équipes MOA ont l'habitude de créer des documents descriptifs des cas de test, de scénarii et de suivi d'exécution pour le reporting et l'inventaire de l'état d'avancement. D'autre part, l'automatisation des tests nécessitent l'utilisation d'un fichier de données pour rendre paramètrables les scénarii et modules anciennement créés, et par conséquent faciliter l'intégration des nouveaux cas de tests si les autres équipes en demandent suite à la criticité non prévisible d'une fonctionnalité. Les deux équipes ont donc tout intêret à travailler ensemble et se mettre d'accord sur un format intermédiaire (format du JDD créé par les testeurs automaticiens). Nous suggérons également aux automaticiens de prendre le temps de créer des documents descriptifs avec des copies des écrans de l'applicatif, afin d'exhiber la correspondance entre les zones à saisir et les données qui leurs correspondent dans les cellulles du tableur du JDD. Les testeurs applicatifs vont donc s'approprier le fichiers de JDd et saisir leurs cas de tests les plus critiques pour qu'ils soient intégrés automatiquement dans le mécanisme de lancement des tests de non regression. Bien évidemment, toutes les bonnes pratiques doivent être respectés comme par exemple :
  • l'utilisation de comptes utilisateurs ou contrats dédiés aux tests
  • communication au préalable lors de l'évolution de chaque écran qui a tendance à le rendre bloqué,
  • mettre en place une réunion de suivi pour mainteir les différentes équipes aux mêmes niveaux d'information