Entretien avec Christophe Bliard, développeur et co-fondateur de HipTest, maintenant nommé CucumberStudio, la première plateforme de test continu dédiée aux équipes Agile et DevOps.

Introduction

Je m'appelle Christophe Bliard, développeur chez SmartBear et l'un des 5 co-fondateurs de HipTest, maintenant connu sous le nom de CucumberStudio.

En mai 2018, nous avons rejoint SmartBear, un leader sur le marché des tests. SmartBear possède également d'autres produits tels que Swagger, SoapUI, TestComplete et Zephyr.

Qu'est-ce que CucumberStudio et quels problèmes la plateforme résout-elle ?

CucumberStudio est une plateforme de test continu collaborative dédiée aux équipes Agile et DevOps. Elle favorise la collaboration entre les équipes commerciales et techniques grâce à son support natif pour le BDD (Développement Dirigé par le Comportement).

CucumberStudio offre une solution au manque de collaboration et de compréhension au sein des équipes. En utilisant le BDD, les différents membres de l'équipe peuvent comprendre quelles fonctionnalités doivent être développées.

De plus, CucumberStudio propose une fonctionnalité appelée "Documentation Vivante", ce qui signifie que la documentation mise à jour est toujours accessible, permettant à chacun d'avoir un instantané instantané de ce qui a été développé. L'atout supplémentaire est que cette documentation est rédigée en texte clair que tout le monde peut comprendre.

Un autre point fort de CucumberStudio est l'automatisation des tests. Vous pouvez générer des scripts exécutables pour le framework de votre choix – nous en supportons près de 25. Un réel gain de temps.

Qu'est-ce que le Développement Dirigé par le Comportement (BDD) ? Et quelle est la différence avec le Développement Dirigé par les Tests (TDD) ?

Le BDD est une méthode Agile qui favorise la collaboration entre les différents intervenants travaillant sur le même projet (développeurs, testeurs, chefs de produits, entreprises, etc.). Il vise à livrer la fonctionnalité requise le plus rapidement possible.

En utilisant des exemples écrits avec une syntaxe et une terminologie communes, toute l'équipe peut comprendre les actions que le produit doit effectuer. Ces exemples sont écrits en syntaxe Gherkin : "Étant donné... Quand... Alors." Ils sont ensuite traduits en spécifications exécutables, garantissant ainsi que le code correspond aux critères d'acceptation définis au préalable.

Les deux méthodes, BDD et TDD, sont complémentaires et couvrent des aspects très différents de la qualité logicielle. Avec le TDD, un développeur écrit une série de tests pour s'assurer que le code correspond aux spécifications tout au long du processus de développement de la fonctionnalité.

Avec le BDD, les scénarios (ou exemples) sont écrits en mode collaboratif entre les développeurs, l'équipe produit et l'équipe qualité. Les discussions mènent à une vision partagée de la nouvelle fonctionnalité, garantissant ainsi un développement en phase avec les besoins de l'équipe produit. Et comme avantage supplémentaire, les scénarios peuvent ensuite être traduits en tests exécutables pour compléter ceux écrits en utilisant la méthode TDD.

Exemple d'un scénario BDD :

Pourquoi et comment utilisez-vous Scalingo ?

Nous avons opté pour que CucumberStudio soit hébergé sur une "Platform as a Service" afin de gagner du temps. En utilisant Scalingo, nous pouvons concentrer notre temps et nos efforts sur la production de code, qui est notre réelle valeur ajoutée.

Juste pour le fun – nous sommes parmi les plus anciens clients de Scalingo. Lorsque CucumberStudio était HipTest, nous avons hébergé sur Scalingo en décembre 2015 !

CucumberStudio est un monolithe Ruby on Rails, ce qui signifie que plusieurs conteneurs XL reçoivent les requêtes web. Les tâches à exécuter sont empilées dans une base de données Redis, puis dépilées par des tâches en arrière-plan – jobs différés ou sidekiq (les jobs différés et sidekiq sont deux bibliothèques Ruby qui permettent l'exécution de tâches asynchrones). Plusieurs types de travailleurs ont été définis pour consommer les tâches de différentes manières.

Chaque type de travailleur a un nombre et un type de conteneur différent pour effectuer le travail plus rapidement. Notre fichier Procfile peut contenir plus de 10 lignes. Cette architecture nous permet de maintenir facilement une moyenne de 1500 RPM.

“ This architecture means we can easily keep up an average of 1500 RPM. ”

Christophe Bliard, Dev & Ops at CucumberStudio

Le déploiement sur Scalingo est effectué avec un multi-buildpack, incluant les buildpacks Ruby, Node, EmberJS et Datadog.

Nous utilisons Ruby parce que notre application est une API Ruby on Rails. Node et EmberJS parce que l'interface utilisateur est une SPA (Single Page Application) écrite en EmberJS. Nous avons choisi Datadog pour leur agent qui fournit des retours sur les métriques d'utilisation de la mémoire, CPU.

Nous utilisons PostgreSQL comme base de données et Elasticsearch comme moteur de recherche. De plus, lorsque nous avons d'abord créé notre entreprise, nous avons utilisé PostgreSQL comme moteur de recherche, mais avec la charge croissante et la complexité, nous avons préféré passer à Elasticsearch. À ce jour, la base de données PostgreSQL contient plus de 225 Go de données.

Notre service open source CucumberStudio Publisher est également hébergé sur Scalingo. Il génère automatiquement des suites de tests dans différents langages de programmation à partir de scénarios écrits sur CucumberStudio. Nos clients peuvent également télécharger et exécuter CucumberStudio Publisher depuis leurs machines de développement.

Pour chaque application, nous utilisons le Drain de Logs de Scalingo dédié à Datadog et AppSignal pour les retours d'erreur.

Enfin, avec l'API de base de données Scalingo qui facilite le téléchargement de sauvegardes, nous pouvons voir de nouveaux flux de travail, tels que la reconstruction d'environnements de test locaux sur des serveurs physiques dans nos propres bureaux.

Avez-vous des histoires à partager en coulisses ?

Lorsque l'entreprise (HipTest) a été lancée, nous avons adopté le concept que le support devait être partagé par tous les membres de l'équipe. Autant que je sache, vous appliquez le même principe chez Scalingo. Il s'est très vite révélé que nos développements de "produit" étaient constamment interrompus par des sessions de support et nous avions l'impression de perdre en efficacité.

C'est pourquoi nous avons décidé de faire des rotations. Chaque semaine, l'un d'entre nous prenait entièrement la partie support. Cette personne était surnommée "Batman" – celui qui sauve la mise pour le client.

De toute évidence, il y avait des moments où le service de support était submergé de discussions. Nous avons donc ajouté un "Robin" à notre Batman comme soutien lorsque les choses devenaient trop mouvementées.

Plus tard, nous avons recruté quelqu'un de totalement dédié à la fourniture de soutien. Le problème que nous rencontrions ici était que cette personne était basée en France et que nous avions beaucoup de clients américains.

Cette personne passait donc beaucoup de temps le soir à répondre à diverses demandes de l'autre côté de la planète. Nous avons donc décidé de réintroduire le rôle de Batman pour l'aider – surtout quand il est le soir en France.

Suivez CucumberStudio sur Twitter.