Squash TM est une solution libre, sous licence LGPL v3, de gestion du patrimoine de tests, à l'instar de Salomé-TMF ou encore TestLink. Il permet de gérer l'ensemble des étapes d'une recette, généralement fonctionnelle, de la gestion des exigences à l'exécution des campagnes de test, en passant par les cas de tests, les scénarios, la gestion des anomalies, les comptes-rendus d'exécution, le reporting, etc. Pour la partie gestion des anomalies, il ne réinvente pas la roue et s'interface actuellement avec l'outil (libre) Mantis, mais d'autres sont prévus comme JIRA.
Par rapport à d'autres solutions, il est aussi nativement multi-projets, chaque utilisateur pouvant accéder à l’ensemble des projets sur lesquels il a les droits, et inter-projets, un projet donné pouvant référencer les items d’un ou plusieurs projets tiers (cas de test, exigences…). Toujours par rapport à la concurrence, libre ou propriétaire, Squash TM est également une application légère ne nécessitant pas le déploiement d'ActiveX comme Quality Center ou d'applet Java comme Salomé-TMF. Techniquement, l'application web se base sur les frameworks Java et Javascript suivants : Spring 3, Spring MVC, Hibernate, JasperReport et JQuery.
Fin mars dernier est sortie la version 1.1 de Squash TM. Cette nouvelle version apporte de nombreuses nouveautés : versionning et workflow de gestion des exigences, gestion des pré-requis et de la criticité d'un cas de test, import en masse de cas de tests, organisation de plan de test en suites de test, etc. L'ensemble des fonctionnalités est disponible sur le site du projet.
Le projet Squash
Squash TM est la première brique d'une suite d'outils (existants ou à venir) libres ayant pour but de structurer et d'industrialiser les métiers du test : le projet Squash. Ce dernier sera composé à terme des composants suivants
- Squash TM (Test Management) : Gestion du référentiel de tests, outil pivot de la suite ;
- Squash TA (Test Automation) : Automatisation des tests de non régression : modélisation des scripts, lancement des campagnes automatisées, reporting, etc. Sa disponibilité est anticipée pour la fin du mois ;
- Squash Data : Gestion des jeux de données : extraction, échantillonnage, anonymisation, stockage, chargement dynamique, maintenance, etc. ;
- Squash SC (Services Center) : Pilotage et administration de Centre de Services Qualité Logicielle : planning, gestion des ressources, suivi des demandes, GED, supervision des outils et environnements.
D'ailleurs, Squash Test est plus qu'une suite logicielle, qui serait juste là pour dire "tenez, voici l'outil et débrouillez-vous !". C'est aussi un projet qui cherche à développer et proposer une méthodologie, un référentiel, une organisation, … autour des métiers du test et de la qualification logicielle au sens large. Initié il y a un an par des PME spécialisées dans le domaine du test logiciel, le projet Squash est aussi poussé par des universitaires et quelques grandes entreprises qui le déploient en interne. Pour finir, sachez qu'il fait partie des projets retenus par le groupe thématique Logiciels Libre du pôle Systematic.
Captures d'écran
Les incontournables captures d'écran… Vous en trouverez plus sur la page dédiée
La bibliothèque des campagnes de test :
L'interface d'exécution optimisée (oui, c'est Bing ;-) :
Et sinon, vous pouvez tester directement sur le site de démonstration qui contient des données… de test :-)
Aller plus loin
- Squash TM (1360 clics)
- Le projet Squash (474 clics)
- Code source de Squash TM (136 clics)
- Site de démonstration de Squash TM (716 clics)
- Release Notes de Squash TM 1.1 (51 clics)
- Téléchargement de Squash TM 1.1 (119 clics)
- Salomé-TMF sur LinuxFr.org (138 clics)
- Groupe Thématique du Logiciel Libre du pôle de compétitivité Systématic (81 clics)
# Bon début...
Posté par Erwan Le Gall (site web personnel) . Évalué à 8. Dernière modification le 23 avril 2012 à 19:47.
Le workflow suggère plein de choses intéressantes. Par contre c'est clairement pas fini, ça sent l'outil sur mesure en train de se transformer en outil générique. Au bout de 20 minutes de tests :
Et les bons points :
Je sais pas encore si je l'utiliserai dans les mois qui viennent, mais je vais clairement regarder de près.
[^] # Re: Bon début...
Posté par Dring . Évalué à 6. Dernière modification le 24 avril 2012 à 14:21.
Pour la partie gestion à un bugtracker, juste un retour d'expérience sur comment ça marche les tests "chez nous", pour plusieurs centaines de projets et autant de développeurs, répartis sur 3 pays.
On a d'un côté un bugtracker (un JIRA) qui sert à :
De l'autre côté, un outil de suivi de test (QualityCenter), qui sert à :
Et oui : on gère d'un côté les défaut dans QC (pour ce qui est détecté pendant les phases de tests) et de l'autre les bugs dans JIRA (pour ce qui est détecté en production). D'ailleurs, quand un défaut détecté en recette ne peut être corrigé (soit parce que c'est trop compliqué et non bloquant, soit parce que finalement c'est une nouvelle fonctionnalité), on crée une demande de changement dans JIRA, pour la planifier dans une version ultérieure.
Bref, tout ça pour dire que l'idéal serait qu'un outil comme SquashTest propose une gestion intégrée des défauts de recette. Ainsi, un défaut est clairement lié à une exécution de test, à une ou plusieurs exigences, … Et n'est pas mélangé à des demandes de changement et des bugs "de production".
De manière plus générale, le site de test de Squash ne répondait pas quand j'ai voulu l'essayer ; les copies d'écran laissent apparaître quelque chose manquant de fini sur la partie présentation, avec peu de possibilités de personnalisation. Mais je garderai un oeil sur ce projet à partir de maintenant, car trouver un remplaçant à QC serait… un pur bonheur (ActiveX suxxxent !)
[^] # Re: Bon début...
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 2.
Je peux me tromper, mais l'outil s'interfaçant directement avec le bug tracker, il est tout à fait envisageable de mettre en place dans ton cas une instance de JIRA reliée à Squash pour les défauts de recette et une autre instance indépendante pour les "bugs de prod".
Chez moi, ça marche, au moment de la rédaction de ce message.
[^] # Re: Bon début...
Posté par Dring . Évalué à 2.
C'est effectivement une piste ; mais est-ce que dans ce cas on perd tout ou partie des fonctionnalités de navigation défaut/cas de test/exécution de test/exigence qui sont vraiment naturelles dans un outil comme QC (que j’exècre par ailleurs).
[^] # Re: Bon début...
Posté par El Titi . Évalué à 4.
Marrant, on a les mêmes besoins ici.
Et effectivement QC a une interface ripoux à base d'active X avec tout les problèmes afférents à la sécurisation des postes sous Active Directory, des formulaires ala web des années 80 pour la soumission des défauts.
Néanmoins pour le cas que tu cites je crois qu'il existe un plugin à l'étude chez nous "JAM":
https://plugins.atlassian.com/plugins/com.go2group.jira.plugin.mercury_kit
Il permet de synchroniser les 2 outils en automatique.
Je n'ai pas eu de retour pour savoir s'il était concluant.
Une alternative à QC est à suivre.
Déjà que Selenium remplace avantageusement QuickTest Pro pour une grande majorité d'IHM.
[^] # Re: Bon début...
Posté par Dring . Évalué à 2.
Ah, un retour d'expérience dans ce domaine m'intéresse fortement. Ici, on utilise les deux, mais Selenium est plutôt utilisé par l'IT, et QTP par les utilisateurs (avancés). Mais du coup, l'IT commence à s'en servir, à mon grand désespoir.
[^] # Re: Bon début...
Posté par El Titi . Évalué à 4.
Pour être plus précis je suis en désaccord avec ton point de vue. A mon sens un defaut recette doit être traite comme n'importe quel autre demande de changement avec un outil unique et approprié. Je suis d'accord avec le fait qu'il faut garder une certaine tracabilite par rapport aux exigences mais c'est un autre domaine qui ne releve du test. Même si l'outil de test doit lui aussi permettre de vérifier que les exigences sont couvertes. Il est donc important que l'outil de suivi des demandes de changements puissent référencer les cas de test qui sont associes a une demande de correction d'un défaut et vice versa. Mais ils doivent s'interfacer et pas s'intégrer. Sinon on fait le boulot en double.
En ce sens la solution Jira + QC a un temps de retard sur la plateforme Jazz/RTC d'IBM. Leur architecture permet de lier les éléments entre eux au moyen de ressource. En plus il s'agit d'un bus sur lequel chaque outil de génie logiciel s'intègre plutôt que de créer des ponts entre outils dans tous les sens. Et en plus ça permet d'être distribué sur plusieurs sites. Par exemple un défaut peut être crée sur un serveur et référencer un demande de changement d'un autre projet sur un autre site et un projet peut être hébergé sous git l'autre sous svn on pourra les modifier de la mememanier si on les autorisations. Il suffit de créer un connecteur par outil plutôt les interconnecter tous. Atlassian et sa solution centralisée et faite de brics et de brocs est à des années lumières. Mon seul regret c'est proprio.
Si tu es intéresse tu peux télécharger une version complète limitee a quelques développeurs pour te rendre compte. Le seul truc positif pour le libre est qu'ils ont publie les spécifications de tout ça en libre acces. Dommage qu'ils n'aient pas libère le bus Jazz, l'implementation comme ils l'ont fait pour Éclipse. Si tu es intéresse par cette spécification d'une solution complète de gestion de cycle de vie va faire un tour sur OSLC : http://open-services.net/. Ha même l'éditeur d'un certain Mylyn qui participe;)
[^] # Re: Bon début...
Posté par El Titi . Évalué à 3.
Pour ce qui concerne les tests et l'interfacage avec le change management: http://open-services.net/bin/view/Main/QmSpecificationV1
[^] # Re: Bon début...
Posté par El Titi . Évalué à 3.
Et sinon il semble, d'après le contenu de la dépêche, que Squash ambitionne de proposer une solution complète de gestion de la qualité et des tests.
Pour une initiative libre c'est très louable et prometteur.
J'invite les acteurs concernés par ce projet à lorgner sur la concurrence.
Notamment, jetez un coup d’œil sur celle proposée par IBM qui s'appuie justement sur la plateforme de collaboration Jazz.
https://jazz.net/projects/rational-quality-manager/?ref_content=ribbon
Je pense que certains principes d'architecture son vraiment bien pensés notamment le couplage lâche qui s'appuie sur REST et sur la définition des ressources qui elle s'inspire largement de RDF.
http://open-services.net/bin/view/Main/ResourceGuidelines
Qui sait ? Peut-être, qu'une solution plus ouverte et plus solidement conçue amènera les pontes d'IBM à revenir sur leur position et a libérer enfin le coeur de leur application Jazz comme ils l'ont fait pour Eclipse et à ne se différencier que sur les solutions proposées par intégration de produit sur leur bus, comme ils le font pour RSA avec leur architecture en plugin.
Sinon, petite question à l'auteur de la dépêche.
Il me semble qu'il était impliqué dans le développement de SQUALE, la solution de qualimétrie qui n'a, semble t'il, pas autant percé que son autre concurrent libre Sonar.
Squash est-il lié a ce produit (l'homonymie m'interpelle) ?
S'il prenait la peine de répondre, je lui en serais reconnaissant (d'ailleurs, je crois mes souvenir qu'il a bossé pour ma boîte ;)
[^] # Re: Bon début...
Posté par El Titi . Évalué à 3.
Et le coeur dont je parle qui implémente OSLC est Jazz Foundation:
https://jazz.net/projects/jazz-foundation/
[^] # Re: Bon début...
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 27 avril 2012 à 20:28.
Effectivement, c'est bien moi :-) J'ai été impliqué au démarrage de Squale, pour laisser ma place ensuite. Et effectivement, Sonar a mieux percé et mieux su créer le buzz autour de son projet. Je connais d'ailleurs très bien certains de leur équipe. Les bonnes idées de Squale peuvent d'ailleurs toujours être implémentées dans Sonar sous forme de plugin. Tout ce qui a été produit par Squale, que ce soit le code source ou les modèles de qualité sont librement disponibles.
La réponse courte : Non. La réponse plus longue : Non, mais il y a des connexions indirectes entre les deux projets. Déjà les deux traitent de Sofware QUAlity (d'où l'homonymie ;-), ensuite quelques personnes (2 ou 3, pas plus) se retrouvent sur les deux projets. Ceci explique cela !
[^] # Re: Bon début...
Posté par djano . Évalué à 2.
Je trouve que ce logiciel a un très fort potentiel.
Par contre, l'ergonomie et la facilité de prise en main de ce logiciel pourrait être bien meilleure a mon avis et devrait être retravaillée:
Les actions sont peut visibles derrière l’icône flèche.
Globalement, en tant que testeur, il devrait être plus évident, plus facile de trouver comment démarrer l'exécution d'un test et mener sa progression. Les actions devrait être plus mises en avant pour cette catégorie d'utilisateurs.
La navigation dans l'arbre de gauche ne peut pas se faire avec les touches du clavier et nécessitent donc beaucoup de clics.
Je trouve que la vue par défaut a l'air d’être essentiellement basée sur les besoins du test manager ou sur les rapports.
# génie logiciel
Posté par BAud (site web personnel) . Évalué à 5.
peu de monde connaît QC² àmha :-)
Pour ceux qui seraient intéressés par ces sujets (ou connexes), il y a le tag génie_logiciel pour retrouver les sujets sur ce thème.
# positionnement par rapport à cTest
Posté par Bubu . Évalué à 1.
Bonjour,
J'espère ne pas être complètement à coté de la plaque.
Comment se positionne Squash par rapport à ctest (de kitware, ils ont aussi à leur actif cmake, et ceux-ci marchent de concert)?
Bubu.
[^] # Re: positionnement par rapport à cTest
Posté par BAud (site web personnel) . Évalué à 5.
d'après http://linuxfr.org/news/petit-%C3%A9ventail-des-outils-de-construction-builder-libres (je ne connais pas trop ctest) :
[^] # Re: positionnement par rapport à cTest
Posté par El Titi . Évalué à 5. Dernière modification le 26 avril 2012 à 10:56.
Oui,
En résumé les tests unitaires sont souvent pris en charge par des librairies (ex : JUnit). Ils ne sont applicables que pour le code métier et peuvent donc être enchaînés automatiquement pour valider tout changement lors de build. Ils s'appuient parfois sur du bouchonnage grâce à des frameworks dédiés lorsqu'il y a des dépendances avec d'autres composants (ex EasyMock). Rajoute un petit test qui met en erreur lors de la découverte d'un nouveau bug et
git bissectest ton ami pour retrouver une régression. On utilise aussi des outils de couverture de code pour vérifier que les tests couvrent un maximum de cas (ex : Emma).Pour ce qui est de la partie interface utilisateur il n'y a pas de autre solution que d'enregistrer des scénarios de tests qui simulent le différents événements d'une IHM. Ensuite ceci est enregistré sous forme de macros dans un langage dédié et peut donc être modifié pour s'adapter aux changements mineurs d'interface. Ces outils doivent donc être adaptés pour chaque bibliothèque graphique. Mercury propose donc Quicktest Pro qui couvre beaucoup de bibliothèque. Pour des interfaces web, Sélénium fait largement l'affaire.
Après il reste à décrire des scénarios de tests fonctionnel qui permettent à la maîtrise d'ouvrage de valider la conformité du produit par rapport aux specs. Certaines parties ne sont pas automatisables. Les scénarios sont donc décrits étape par étape et lors d'une campagne de test, le testeur déroule les cas de test, valide les étapes et soumet les défauts lorsqu'il en rencontre. Mercury, leader du domaine, propose l'outil Quality Center à cet effet. C'est là je pense que se situe le produit présenté dans la dépêche. Ce qui est intéressant c'est qu'on dispose enfin d'une solution de test complète et libre avec tous les produits que j'ai cité.
Le bémol qui a été soulevé plus haut est que lorsqu'on découvre un défaut il est renseigné dans l'outil de test alors que des outils de suivi de demande de changement existent déjà, sont plus complets et sont souvent utilisés en amont du projet en phase de développement pour suivre les nouvelles fonctionnalités et pas seulement les défauts. Par ailleurs les défauts peuvent aussi être découverts en prod et soumis dans ces mêmes outils. Ici on parle de JIRA mais c'est pareil pour n'importe quel bugtracker (je préfère le terme issue tracking qui est plus juste pour traiter toutes les demandes pas seulement les bugs). Pour un outil de suivi de test fonctionnel il est donc important de pouvoir s'interfacer avec un outil de suivi des demande de changement plutôt que de réinventer la roue. Autant ça ce comprend pour Mercury qui cherche à étendre son périmètre dans les outils de gestion du cycle de vie (ALM) face à ses concurrents comme IBM, autant pour un outil libre c'est un peu dommage.
Dsl pour le style télégraphique mais vraiment les tablettes android sont pas au point (troll inside)[NdM : mise en forme et qqs corrections apportées depuis][^] # Re: positionnement par rapport à cTest
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
Ton commentaire contenant pas mal d'informations intéressantes, je me suis permis d'y apporter qqs corrections et remise en forme, sans en modifier le fond.
Sinon, Mercury a été dévoré par HP il y a quelques temps déjà (mi-2006) et depuis le nom de Mercury a complètement disparu…
[^] # Re: positionnement par rapport à cTest
Posté par El Titi . Évalué à 2.
Merci !
Etant derrière un PC, j'aurais pris la peine de le réécrire si on pouvait rééditer ses commentaires à posteriori ;)
Le problème avec la tablette Samsung, c'est que même en se relisant, on ne peut pas poser un point d'insertion comme on le veut. C'est archi buggué.
J'ai l'habitude de taper mes textes en une fois pour ne pas interrompre le fil de mes idées et de me relire ensuite (vie le bouton "prévisualiser")
Là, il faudrait que je relise chacun des mots que j'écris et les corrigent à la volée.
J'espère que ca s'améliore avec Android 4.
[^] # Re: positionnement par rapport à cTest
Posté par djano . Évalué à 2.
Mercury = HP Quality Center = Quality Center
Non?
[^] # Re: positionnement par rapport à cTest
Posté par djano . Évalué à 2.
Pour Selenium, n'enregistrez surtout pas de test tel que le capture/replay vous le donne!
Le moindre changement dans une seule page web peut impacter des centaines de cas de tests.
J'avais pensé construire un petit framework autour de l'application: une page web = une classe qui permet d'effectuer les fonctions métiers offertes par cette page web. Le tout était lié selon le principe des "fluent interfaces" qui permettait d’enchaîner les appels de fonctions les un a la suite des autres.
Le but étant la facilité de relecture, même par un non programmeur, la facilité de maintenance de la suite de tests Selenium en cas de changement, et aussi la facilité d'ajouts de nouveaux cas de test après la création du min framework.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.