Présentation de R.T.M.R : Outil de gestion des cas de test

Les années 2005-2011 ont été pauvres en termes de nouveaux projets assez matures, robustes et bien pensés pour la gestion des cas de test. 2012 s’avère être un meilleur crû avec des projets open sources prometteurs : R.T.M.R et Squash. Ces deux outils ont des positionnements fonctionnels et techniques assez différents. Dans ce premier article, nous examinerons R.T.M.R.

Cette effervescence est finalement logique puisqu’elle correspond au marché. En effet, la part du test logiciel – qui n’est finalement souvent qu’une variable d’ajustement pour absorber les dérapages du développement – augmente. Pas forcément à cause d’une prise de conscience, mais surtout à cause d’une séparation des fonctions et des responsabilités entre différentes entités (la systématisation des centres de services et de l’externalisation y est pour beaucoup).

Avis sur la solution R.T.M.R

La version du client étudiée est la 1.10.1.4 :

RTMR_capture_ecran_vue_projet

Capture d’écran de l’application avec la vue projet

Avantages

  • Documentation complète et en Français.
  • Import/Export Excel : partiel (format CSV).
  • Il est possible de définir des liens entre les  exigences et les cas de test.
  • Les cas de test sont correctement divisés en étapes de test dans la conception et dans l’exécution.
  • Si on fait un glisser/déposer d’une exigence dans une campagne, les tests liés y sont ajoutés.
  • Système de versioning des cas de test.  Si un test est modifié après son exécution, la version correspondante du test — au moment de son exécution — est bien affichée dans l’historique des exécutions (et pas la dernière version).
  • Bonne idée : la notion de paramètre d’exécution de la campagne. Elle peut donner des informations sur les caractéristiques de l’environnement utilisé.
  • Bonne idée : synchronisation du cas de test durant une exécution. C’est une solution acceptable par rapport à l’impossibilité de mettre à jour un cas de test durant son exécution (interrompre l’exécution d’un test, le mettre à jour et continuer l’exécution).
  • Techniquement, le Framework Qt est un bon choix.
  • Le fait d’avoir une interface LDAP classe tout de suite le logiciel dans les applications d’entreprise.
  • Projet régulièrement maintenu.
  • L’application est stable.

Inconvénients

  • IHM quelque peu déroutante, surtout si on la compare à Quality Center.
  • Système de reporting limité. Pas de matrice de couverture fonctionnelle (rédaction/conception des cas de test).
  • On ne peut pas filtrer l’affichage. Pour les recherches, faire CTRL+F sur les exigences ou les tests.
  • Pas de possibilités pour implémenter une démarche de chiffrage de l’activité de test dans l’outil. Les exigences devraient avoir les champs complexité et risque, au minimum.
  • Projet récent — pas de communauté, peu d’entrées dans le forum.
  • Manque de visibilité sur la Roadmap et la stratégie de licence.
  • Techniquement, Solution de cryptographie trop obscure, ne respecte pas les principes de Kerckhoffs.
  • Techniquement, le code du projet ne s’appuie pas assez sur des composants externes réputés, trop de code source spécifique.
  • Client web limité à Firefox.

Axes d’amélioration

  • Le projet devrait inclure un gestionnaire des défauts découverts durant la recette un peu plus complet. Même s’il était minimaliste, cela créerait une solution tout-en-un (quitte à ajouter des possibilités d’export et de synchronisation).
  • Séparation du jeu de données dans les cas de test au moment de la conception : Il y a bien la possibilité de joindre des pièces jointes sur un cas de test, mais la pièce jointe n’est plus disponible au moment de son exécution. Ou alors implémenter la notion de paramètres de cas de test.
  • Il n’y a pas la possibilité d’affecter des tests à des testeurs dans le composant des campagnes (à moins de faire des campagnes dédiées). L’outil n’est donc pas trop fait pour un travail avec une équipe de test de plusieurs personnes.
  • Il faudrait pouvoir organiser les campagnes de test en arborescence.
  • Améliorer la barre d’outils en la rendant contextuelle aux objets affichés.
  • Possibilité d’avoir quelques champs paramétrables/utilisateurs sur les objets de l’application.Le code source devrait s’appuyer sur des composants tout faits et fortement paramétrables qui ont aussi l’avantage d’épargner bien des problèmes de maintenance :

Interfaces

Il existe une interface vers les outils de bugtracking suivants :

Il existe aussi une interface vers LDAP pour l’authetification des utilisateurs de l’application.

Licence et stratégie

Pour l’instant le projet est en GPL, mais le projet semble être fermé à la contribution sur le cœur de l’application :

  • Le code source n’est pas disponible sur un repository publique (SourceForge, Git).
  • Le fichier de configuration contient une clé de licence et le code source semble trahir la volonté d’implémenter une licence (message NO_LICENSE_AVAILABLE)… à moins que cela soit les restes d’un vieux développement abandonné.

Ce qui m’amène à la conclusion que le développeur accepte volontiers les développements d’extensions, mais a une stratégie de changement de licence pour les prochaines versions (open-source, mais pas libre).

Architecture technique

Plateformes supportées

  • Windows.
  • Linux (des paquets Debian 32 et 64-bits existent).
  • MacOS X.

Serveurs

  • Base de données : PostgreSQL.
  • Démon/service développé en Qt/C. Il gère la gestion des sessions et fait l’intermédiaire avec les applications clientes. multiprocessus : un processus père, puis un processus système par session.

Clients

  • Application développée à partir du Framework Qt 4.6
  • Depuis l’été 2012, un plug-in Firefox a été développé de manière à encapsuler le client riche dans le navigateur. L’apparence de l’extension est rigoureusement identique à l’application.

Pour utiliser le client Firefox – que l’on ne peut pas lancer depuis le menu outils du navigateur – il faut se fabriquer un petit fichier HTML qui contiendra le code suivant :

<object id="rtmrapp" TYPE="application/x-rtmr" CODEBASE="http://rtmr.net/downloads/Windows/nprtmr.xpi" width="100%" height="100%">
Test plugin
</object>

Schéma de l’architecture et des flux

Bien entendu, les ports réseau utilisés sont paramétrables.

RTMR_architecture_technique_flux_applicatifs

Schéma de l’architecture et des flux de l’application

Le démon C communique avec les applications dans un protocole texte qui peut être optionnellement encrypté. Clé de 1024 bits (constante dans le code source, cf. utilities.c)

Conclusion

Un projet intéressant, mais qui doit absolument progresser sur les points suivants :

  • Clarifier la feuille de route  du projet et la stratégie de licence.
  • Refondre l’IHM et en améliorer l’ergonomie.
  • Améliorer le reporting et permettre l’emploi de quelques champs personnalisés.
  • S’appuyer sur des composants techniques éprouvés.

Je ne comprends pas vraiment la stratégie multiplateforme pour la partie cliente. L’auteur a fait le choix d’un client lourd contre une interface web. Autant développer un client exclusivement pour Windows. Ainsi, on pourrait bénéficier des possibilités de la plateforme et notamment des interactions possibles avec la suite Office. En outre, si la cible visée est les MOA/AMOA, il faut savoir que cette plateforme a une position de quasi-monopole pour cette population d’utilisateurs.

Pour aller plus loin

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *