Retour sur l'évolution de notre stratégie produit
L'aventure Squash a débuté il y a 10 ans. Voici un retour sur l'évolution de nos stratégies produit et tarifaire et les réflexions qui ont abouti à la sortie de notre nouvelle offre produit, effective à partir de début 2021.
Squash TM
Sur la partie Test Management, nous voulions un outil de test management efficace, agréable à l'utilisation pour les testeurs (en premier lieu ceux de notre société Henix) qui l'utilisent de manière intensive.
Nous souhaitions également un outil accessible (ie gratuit pour les petites sociétés, pas trop cher pour les autres) de manière à outiller largement les bonnes pratiques de test et contribuer à la professionnalisation du métier de testeur.
Squash TM a été conçu et évolue depuis l'origine dans cette optique, avec des versions trimestrielles puis semestrielles (la 1.22 sortant fin 2020).
Au printemps 2021, nous sortirons une version majeure (Squash TM 2.0) avec une ergonomie actualisée (réécriture du front en angular tout en gardant le même back, donc avec montée de version standard).
Nos objectifs d'il y a 10 ans sont globalement atteints puisque l'outil s'est diffusé largement (environ 2000 téléchargements par mois) en open source, des grands comptes l'ont adopté comme unique outil de patrimoine de test (jusqu'à 4000+ utilisateurs), les bonnes pratiques de test se sont répandues et au passage l'activité service d'Henix est passée en 10 ans de 50 à 250 personnes.
Sur ce module, notre enjeu produit (pour la décade à venir ?) est de continuer à enrichir fonctionnellement sur les axes :
positionner davantage les tests au cœur de la conception applicative puis le patrimoine de test comme documentation vivante du patrimoine applicatif,
fournir des représentations des tests différentes selon la méthodologie, l'organisation, le cycle de vie projet depuis le langage naturel, structuré (gherkin) interprétable, puis exécutable.
Et nous étudions actuellement la possibilité de proposer nous-mêmes un outil intégré de gestion de l'agilité avec un objectif de fourniture d'un nouveau produit Squash Agile fin 2021 permettant d'outiller Scrum/Kanban et les cadres d'agilité à l'échelle SAFe/LeSS.
De Squash TA à Squash Autom et Squash DevOps
Sur la partie Automatisation et DevOps, et plus largement le shift-right, notre cheminement a été moins linéaire. Nous voulions initialement proposer un environnement complet de tests automatisés, accessible aux testeurs à goût/potentiel technique comme aux développeurs. En 2012, nous avons donc sorti le module Squash TA qui était à la fois un studio et un environnement d'exécution de tests automatisé. Nous avons alors (lentement) compris 3 choses :
Les développeurs ou automaticiens ne nous avaient pas attendus pour choisir leur environnement de développement privilégié (studio) et n'avaient pas d'intention d'en changer.
Il est coûteux (et hors de notre expertise native "Qualité Logicielle") de faire un studio "universel" surtout si on veut s'adapter aux spécificités de tous les systèmes sous test.
Et surtout l'enjeu 'test' d'une transition digitale réussie n'est pas d'automatiser des tests, mais plutôt d'outiller le process entre le testeur fonctionnel, l'automaticien, le développeur et le DevOps de manière que le "bon" test soit automatisé au "bon" moment. Concrètement, dans la plupart des Systèmes sous Tests de nos clients (*), notre conviction est que l'optimum économique consiste à automatiser peu, au fur et à mesure que l'application se stabilise en s'assurant que chaque test automatisé sera utile et pourra être maintenu. La bonne manière de s'en assurer est d’intégrer les tests automatisés au pipeline de la CI/CD et de trier entre régression et faux positifs en cours de développement.
Nous avons donc sorti fin 2018 Squash TF 1.x qui était un environnement d'exécution de tests automatisés, réutilisant l'architecture de Squash TA. Ce module rencontre aujourd'hui des limites en termes d'architecture qui nous ont incité à le réécrire complètement durant cette année 2020 avec les principes suivants :
Architecture micro-service, notamment pour des raisons de déploiement et d'exploitabilité en environnement DevOps.
Séparation entre les fonctionnalités permettant d'automatiser (à destination des testeurs et automaticiens) et celles permettant d'intégrer les tests automatisés (pour le gestionnaire de pipeline) au sein de l'usine DevOps. Cela a donc donné naissance à 2 produits (astucieusement) nommés Squash Autom et Squash DevOps.
Suppression de l'adhérence avec Squash TM de manière à rendre chacun des 3 produits Squash TM, Squash Autom et Squash DevOps indépendants.
Sur les 2 nouveaux produits, nous cherchons à pouvoir apporter de la valeur, même pour les sociétés ou projets n'utilisant pas Squash TM :
L'utilisation de Squash Autom "seul" permet ainsi d'unifier/d'homogénéiser l'usage des différents automates (Selenium, Cypress, SoapUI, Appium...) et des différents studios (Robot Framework, Cucumber, UFT, Agilitest...) tout en générant un format de reporting commun (type Allure)
L'utilisation de Squash DevOps "seul" permet d'orchestrer l'ensemble des tests automatisés, de les intégrer au pipeline DevOps (CI/CD) puis de poster les résultats vers les destinataires (le pipeline lui-même, l'outil de patrimoine de test ou le framework de reporting et d'agrégation des résultats de test).
Dans toutes ces évolutions, nous avons toujours cherché à garantir une compatibilité ascendante, c'est à dire que des tests écrits avec Squash TA ou Squash TF continuent à fonctionner de version en version et avec l'installation de Squash Autom et Squash DevOps.
Monétiser, c'est (aussi) pérenniser
Nous avons eu la chance de pouvoir lancer et développer le projet pendant longtemps sans vraiment nous soucier de la monétisation, à la fois car nous avons bénéficié de subventions/CIR en 2011-2013 et parce que les retombées futures en termes de réputation pour Henix nous suffisaient. Puis nous avons réalisé, que sans monétisation, nous n'aurions pas les moyens de faire évoluer le produit comme nous l'espérions sur la durée.
Nous avons alors tâtonné en expérimentant différents modèles classiques dans le monde Open Source comme la vente de support, la double licence, la licence fixe... Nous avons finalement opté pour un modèle "open core" avec :
une version Community gratuite composée d'un cœur open source et de modules freemium
une version commerciale, avec souscription annuelle, composée de la version Community et de plugins commerciaux.
Dans le choix des fonctionnalités gratuites vs payantes, nous cherchons à positionner le curseur de manière à fournir une version Community pleinement fonctionnelle (non bridée). La version payante (Premium) se différencie avec des connecteurs supplémentaires (vers des outils payants en général) ou bien des fonctionnalités supplémentaires à valeur ajoutée, mais non indispensables, ainsi que le support. Selon nous, l'existence et le maintien de cette version Community (avec le même cœur) limite le "vendor lock in" et permet à nos clients d'avoir le meilleur des contre-pouvoirs en cas d'abus de l'éditeur : repasser sur la version Community en renonçant aux fonctionnalités commerciales.
Pour la mécanique tarifaire de Squash TM Premium, nous avons cherché un modèle simple identique, pour le SaaS et la version serveur. Nous avons choisi le modèle de (feu) Jira Server avec des tranches en fonction du nombre d'utilisateurs déclarés, qui nous a semblé à la fois simple à comprendre et à mettre en œuvre. Nous avons opté pour une base tarifaire (en version serveur) de 50 utilisateurs pour 6000 euros (10 euros/utilisateur/mois) inchangée depuis l'origine (avec un coût de 3 à 10* moins cher que notre concurrent historique mais qui nous parait suffisant).
Pour les autres modules, Squash Autom et Squash DevOps (qui sont composés de services et non d'applications et où la notion d'utilisateur a moins de sens), nous avons choisi de fixer le prix de la version Premium comme un pourcentage de la base tarifaire de Squash TM (en l'occurrence 75% pour Squash Autom et 75% pour Squash DevOps). Et pour les clients souhaitant utiliser Squash Autom ou Squash DevOps en version commerciale sans Squash TM, nous baserons notre tarification en fonction du nombre d'utilisateurs de leur référentiel de test. Les clients actuels de la version commerciale de Squash TF (appelée version Entreprise) se verront proposer les versions Premium de Squash Autom et Squash DevOps sans surcoûts (jusque 2022).
Avec l'agilité et le DevOps, le test se positionne au cœur de la fabrication des SI et de la transition digitale, la décennie à venir s'annonce passionnante !!!
L'Equipe Produit Squash.
(*) Cette remarque concerne les SI actuels de nos clients, caractérisés par beaucoup de lignes de code et une grande sensibilité des tests aux données (c'est différent par exemple sur des architectures de calculateur embarqué ou des architectures pures micro-service ou d'API).