Interview autour des activités de test de la Sacem

Voici un résumé de l’interview de Doriane Zohar, Responsable Assurance Qualité et Recette de la Sacem. Dans cet entretien, réalisé en avril 2022, elle évoque le contexte dans lequel évolue son équipe de test ainsi que les différents outils utilisés pour mener à bien ses missions. Pour accéder à l’intégralité de cet entretien, vous pouvez cliquer sur la vidéo en fin d’article.

Pourriez-vous commencer par nous présenter le rôle de la Sacem ?

La Sacem, c’est la Société des auteurs, compositeurs et éditeurs de musique. L’un des objectifs principaux de la Sacem est de collecter les droits d’auteur sur le territoire français de manière à pouvoir redistribuer leurs droits aux créateurs de musique.

Quel est votre poste au sein de la Sacem ?

Je suis aujourd’hui Responsable Assurance Qualité et Recette pour une équipe d’environ 30 testeurs fonctionnels.

Quel a été votre parcours pour en arriver là ?

Je travaille à la Sacem depuis 11 ans. Avant cela, j’ai commencé mon parcours en tant que développeur, puis j’ai très vite embrayé en faisant des formations. Je suis arrivée à la Sacem en tant qu’opérateur de saisie puis j’ai évolué en tant que testeur, analyste, test manager et aujourd’hui, je suis responsable assurance qualité.

Comment est organisée votre équipe ?

Mon équipe est composée de test leads par domaine fonctionnel et ensuite, nous avons les analystes de test qui vont tester réellement les applications. Nous avons aussi une petite équipe d’automaticiens (qui représente 10 % de l’effectif de l’équipe de test).

Quel est l’enjeu majeur pour vous dans vos missions actuelles ?

La Sacem a un SI assez complexe comprenant près de 200 applications. Notre objectif aujourd’hui, c’est d’avoir le taux de couverture le plus haut possible. Nous testons déjà plus de 100 d’entre elles. Nous souhaitons donc nous lancer pleinement dans l’automatisation pour augmenter la couverture de test. L’année dernière, par exemple, nous avons augmenté notre périmètre de 235 % en un an sur l’automatisation, donc c’est sur la bonne voie.

Quels types d’application testez-vous ?

La majorité de nos applications sont des applications web dont les IHM sont accessibles via des navigateurs. Beaucoup d’entre elles sont des applications internes, mais certaines sont exposées comme le portail, c’est-à-dire notre site web, qui contient des espaces sécurisés. Nous testons également des applications mobiles ainsi qu’un petit nombre de clients lourds.

Quel est le type de test manuel que vous pratiquez prioritairement ?

À la Sacem, nous avons mis en place une stratégie globale de test qui englobe les 8 critères qualité qui sont décrits dans la norme ISO 25010. Mon équipe ne va pas couvrir tous les tests, mais notre stratégie globale permet de couvrir tous les critères.

Les tests unitaires étant faits par les développeurs, mon équipe va couvrir :

• des tests fonctionnels, donc les tests d’IHM, les tests de bout en bout qui intègrent aussi des tests d’intégration
• des tests de compatibilité (tests d’API ou tests d’échanges de fichiers)
• des tests de portabilité
• des tests de validation avec nos utilisateurs finaux.

Dans ce contexte, quand avez-vous commencé à envisager d’utiliser Squash ?

Nous nous sommes pleinement lancés avec Squash en 2019. À l’époque, nous étions à la recherche d’un outil qui répondrait à la fois à la méthodologie Agile et à la méthodologie Cycle en V. On a entendu parler de Squash via nos relations professionnelles. Donc nous l’avons évalué et je pense que le tester, c’est l’adopter. Nous avons alors été convaincus et nous avons désormais une quarantaine d’utilisateurs Squash.

Quel(s) outil(s) vous utilisiez précédemment pour la gestion de votre référentiel de tests ?

Nous utilisions HP Quality Center. Nous avons choisi aussi Squash parce qu’en termes de « mindset », c’était très proche de Quality Center et nos équipes ont donc très vite pris le pli. Il a forcément fallu faire un peu d’accompagnement au changement. On a installé la version gratuite, on a fait des présentations aux différents testeurs de nos équipes, puis on leur a mis à disposition l’outil avec un projet par personne. Ils pouvaient faire leurs différents essais pendant une demi-journée dédiée, le tout avec l’aide de la chaîne YouTube « Squash Team » dans laquelle il y a des trucs, astuces et modes opératoires.

Vous avez donc fait appel à une prestation côté Henix qui est éditeur de Squash ?

Oui, il y a des techniciens qui sont venus et qui nous ont accompagnés pour la reprise de nos scripts automatisés et de nos campagnes manuelles. Nous avons été accompagnés par Henix sur nos questions. Puis, le changement d’outillage s’est fait en mode « big bang », nous avons fait la migration avec Henix et, du jour au lendemain, on a débranché QC et on est passé sur Squash.

Et depuis juillet dernier, avez-vous pu prendre en main la nouvelle interface de Squash TM ?

Nous faisons un upgrade par an donc une montée de version sur deux. Nous avons commencé à utiliser cette interface depuis le mois de janvier 2022. Il a fallu un petit temps d’adaptation mais, finalement, les équipes me remontent que c’est bien plus clair, plus facile à utiliser et que ça répond totalement à leurs attentes.

Y a-t-il d’autres fonctionnalités clés de Squash TM qui répondent à vos besoins ?

Depuis que nous avons Squash, nous écrivons désormais tous nos tests (même les tests manuels) en BDD. Ainsi, en plus de nous préparer plus facilement l’automatisation de nos tests, tout le monde partage le même langage et les développeurs comprennent aussi forcément beaucoup mieux les anomalies quand ils voient que le test est rédigé en BDD.

L’autre point positif autour de Squash TM, ce sont aussi les graphiques qui sont générés automatiquement. Il ne faut pas oublier que dans notre ancien outil, nous étions obligés de paramétrer à chaque fois un graphique pour pouvoir l’afficher dans notre suivi. Ce sont des petites choses qui nous font gagner un peu de temps, mais mises bout à bout, nous sommes bien plus efficaces avec cet outil.

Utilisez-vous d’autres outils de la suite Squash ?

Utilisant Jira comme recueil des US, oui, nous utilisons Xsquash tous les jours. C’est vraiment un plugin qui nous est utile pour synchroniser automatiquement les US d’un projet Jira dans l’Espace Exigences de Squash. À l’heure où nous prônons la transparence au sein de la Sacem, le fait de pouvoir aussi uploader les cas de test et le rapport d’exécution dans Jira permet de créer une émulation entre les PO et les développeurs. En tous cas, les développeurs nous posent beaucoup moins de questions, car ils savent ce qui est testé, comment c’est testé et ils peuvent donc reproduire les cas d’erreurs de leur côté.

Depuis 2020, nous utilisons aussi le plugin Jira Bugtracker pour remonter les anomalies depuis Squash TM vers Jira.

Nous sommes également utilisateurs de Squash TF pour gérer l’automatisation de nos tests. Aujourd’hui, nos testeurs fonctionnels font de la conception de test et utilisent le workflow interne de Squash pour faire des demandes d’automatisation à nos automaticiens. Derrière, nos automaticiens utilisent du Cucumber principalement, mais aussi du Selenium ou encore UFT. Donc ils gèrent la demande d’automatisation puis le script automatisé peut être lancé via Squash TM directement. L’avantage, c’est que nos testeurs fonctionnels sont intégrés dans les équipes produit. Les demandes d’exécution de scripts sont très souvent faites par le PO ou par les développeurs lors d’une livraison et ils sont complètement autonomes, avec le testeur intégré.

Nous sommes en train de migrer vers Squash AUTOM qui devrait être installé d’ici une semaine ou deux peut-être.

Faisiez-vous de l’automatisation avant d’utiliser Squash TF ?

Avant Squash, nous utilisions surtout l’automatisation pour générer des jeux de données.

Ce qui est le plus intéressant avec Squash, c’est l’interaction qui peut être faite via l’outil pour les demandes d’automatisation. Donc on a mis en place un process pour identifier et valider ce qui doit être automatisé avant qu’un automaticien ne se lance dans le process d’automatisation. Après l’automatisation, on fait notre démo aux PO et à l’équipe Produit une fois qu’on a terminé nos tests et qu’on arrive en production.

Quelles sont les potentialités de Squash AUTOM qui vous poussent à l’installer ?

Sur la partie automatisation, ça va nous permettre d’avoir un suivi dans Squash TM de toutes les exécutions. Aujourd’hui, pour toutes nos exécutions qui sont programmées, nous n’avons pas de statistiques qui remontent dans Squash, car elles sont dans notre Jenkins. On souhaiterait pouvoir mettre différents suivis dans le rapport d’exécution des scripts automatisés pour qu’ils soient évalués à leur juste valeur. Donc nous espérons que Squash AUTOM pourra répondre à ce besoin.

Quels types de tests automatisés pratiquez-vous prioritairement ?

Il s’agit principalement de tests de non-régression (lancés automatiquement deux fois par semaine) qui nous servent énormément dans un contexte Agile.

Nous faisons aussi de l’automatisation des tests d’API pour nos tests de services REST.

La prochaine étape sera de pouvoir faire de l’automatisation au fur et à mesure pour tester nos applications, mais on n’en est pas encore là.

Est-ce que la logique DevOps vous intéresse également ?

Actuellement, nous sommes en pleine transformation de notre SI en s’inspirant du framework SAFe, dont les premiers trains sont partis. Nous avons commencé au mois de janvier à enclencher cette transformation et, forcément, la partie testing est très importante aussi donc nous nous y attelons et cherchons notre modèle inspiré de SAFe. Nous en sommes vraiment aux prémices donc.

Revenons à Xsquash, était-ce important que votre outil de test puisse interagir avec Jira ?

Oui, c’était même un prérequis lorsque l’on a choisi la solution Squash. L’outil de test idéal devait interagir avec nos outils existants, nous ne voulions pas être obligés d’effectuer le travail en double en recopiant à la main les exigences dans le référentiel de tests, etc. Il fallait que cela soit interconnectable et Squash a été choisi aussi pour l’interconnexion avec Jira ainsi que pour l’ouverture vers d’autres outils d’automatisation, tels que Katalon par exemple.

Le fait que le projet Squash soit évolutif est très positif pour nous.

Y a-t-il un axe de développement majeur que vous attendez côté Squash ?

Comme nous aimerions que les PO puissent écrire leurs fiches en Gherkin, ce serait bien que l’on puisse récupérer cela directement dans Squash sans avoir à les recopier.

Le Club Utilisateur Squash est hébergé une fois par an lors du Club Qualité Logicielle, est-ce que vous avez déjà participé à cet événement ?

Déjà deux ou trois fois oui. C’était bénéfique car il y a toujours des échanges avec d’autres utilisateurs et j’ai pu profiter de différents retours d’expérience intéressants lors des présentations.

Est-ce que vous avez aussi pu bénéficier de formations dispensées par Henix sur Squash auprès de vos équipes de test ? Ou de tout autre type de prestations ?

À date, la seule prestation à laquelle on ait fait appel, c’est pour la migration de notre patrimoine de tests quand on est passé de QC à Squash. En toute transparence, je n’avais même pas conscience que vous faisiez d’autres choses. Donc c’est noté pour la suite.

Une dernière remarque ?

Je voulais quand même dire un mot en particulier sur le Support Squash. Nous sommes très contents, car vous êtes toujours réactifs sur ce point. Nous avons toujours une réponse dans l’heure et la résolution se fait très rapidement aussi. Je tenais donc à les remercier car, quand on a un outil qui tombe ou une problématique et que je dois gérer parfois 50 personnes qui attendent la résolution, je suis très sereine de savoir que j’aurai des éléments de réponse au plus tard dans la demi-journée.

Découvrez l’intégralité de l’entretien dans la vidéo ci-dessous :