CucumberStudio

Saving developers time by reducing Ops intervention with the help of Scalingo

Interview with Christophe Bliard, developer and co-founder of HipTest, now named CucumberStudio, the first continuous testing platform dedicated to Agile and DevOps teams.

Introduction

My name is Christophe Bliard, a developer at SmartBear and one of the 5 co-founders of HipTest, now known as CucumberStudio.

In May 2018, we joined up with SmartBear, a leader in the testing market. SmartBear also owns other products such as Swagger, SoapUI, TestComplete and Zephyr.

HipTest Team
HipTest Team

What is CucumberStudio and what problems does the platform solve?

CucumberStudio is a collaborative continuous testing platform dedicated to Agile and DevOps teams. It fosters collaboration between business and tech teams through its native support for BDD (Behavior-Driven Development).

CucumberStudio provides a solution to the lack of collaboration and understanding within teams. By using BDD, the various team members can understand which features should be developed.

What’s more, CucumberStudio offers a feature called “Living Documentation,” which means that updated documentation is always accessible, so everyone can have an instant snapshot of what’s been developed. The added extra is that this documentation is written in plain text that everyone can understand.

Living Documentation - HipTest
Living Documentation - HipTest

Another strong point with CucumberStudio is test automation. You can generate executable scripts for the framework of your choice – a we support nearly 25 frameworks. A true time-saver.

What is Behavior-Driven Development (BDD)? And what’s the difference with Test-Driven Development (TDD)?

BDD is an Agile method that fosters collaboration between different stakeholders working on the same project (developers, testers, product owners, businesses, etc.). It aims to deliver the required feature as quickly as possible.

By using written examples with a common syntax and terminology, the entire team can understand the actions the product should perform. These examples are written in Gherkin syntax: “Given…When…Then.” They’re then translated into executable specifications, thereby ensuring that the code corresponds to the acceptance criteria defined beforehand.

The two methods, BDD and TDD, are complementary and cover very different aspects of software quality. With TDD, a developer writes a series of tests to make sure the code corresponds to the specifications throughout the feature development process.

With BDD, the scenarios (or examples) are written in a collaborative mode between the developers, the product team, and the quality team. The discussions lead to a shared vision of the new feature, thereby ensuring development in line with the needs of the product team. And as an added bonus, the scenarios can then be translated into executable tests to complement those written using the TDD method.

Example of a BDD scenario:

Given user « JohnDoe » is registered on the site
When user « JohnDoe » logs in
Then a welcome message is displayed

Why and how do you use Scalingo?

We have opted for CucumberStudio to be hosted on a “Platform as a Service” in order to save time. By using Scalingo, we can concentrate our time and efforts on producing code, which is our real added value.

Just as a fun fact – we are among Scalingo’s oldest clients. When CucumberStudio was HipTest, we hosted on Scalingo in December 2015!

CucumberStudio has been hosted on Scalingo since December 2015!

Christophe Bliard, Dev & Ops at CucumberStudio

CucumberStudio is a Ruby on Rails monolith, which means that several XL containers receive the web requests. The jobs to be executed are stacked in a Redis database and then unstacked by background jobs – delayed_jobs or sidekiq (delayed_jobs and sidekiq are two Ruby libraries that enable asynchronous jobs to run). Several types of workers have been defined that consume jobs in different ways.

Each type of worker has a different number and type of container to do the job more rapidly. Our Procfile file can cope with more than 10 lines. This architecture means we can easily keep up an average of 1500 RPM.

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

Christophe Bliard, Dev & Ops at CucumberStudio

Deployment on Scalingo is carried out with a multi-buildpack, including Ruby, Node, EmberJS and Datadog buildpacks.

We use Ruby because our application is a Ruby on Rails API. Node and EmberJS because the user interface is an SPA (Single Page Application) written in EmberJS. We have opted for Datadog for their agent-providing feedback on memory usage metrics, CPU.

We use PostgreSQL as a database and Elasticsearch as a search engine. Furthermore, when we first set up our business we used PostgreSQL as a search engine, but with the increasing load and complexity, we preferred moving on to Elasticsearch. To date, the PostgreSQL database contains over 225 GB of data.

Our open source service CucumberStudio Publisher is also hosted on Scalingo. It automatically generates test suites in different programming languages from scenarios written on CucumberStudio. Our clients can also download and execute CucumberStudio Publisher from their development machines.

On each application, we use Scalingo’s Log Drain dedicated to Datadog and AppSignal for error feedback.

Finally, with the Scalingo database API which makes downloading backups easier, we can see new workflows, such as rebuilding local test environments on physical servers in our own offices.

Any behind-the-scenes stories to share?

When the company (HipTest) was launched, we adopted the concept that providing support should be shared by all the team members. As far as I know, you apply the same principle at Scalingo. It very quickly turned out that our “product” developments were constantly interrupted by support sessions and we felt we were losing out on efficiency.

That’s why we decided to take it in turns. Each week one of us took on the support side entirely. This person was nicknamed “Batman” – the one who saves the day for the client.

Obviously, there were moments when the support service was overrun with discussions. We therefore added a “Robin” to our Batman as backup when things got too hectic.

Later, we took on someone who was totally dedicated to providing support. The problem we encountered here was that this person was based in France and we have a lot of American clients.

So this person spent a lot of time in the evening answering various requests from the other side of the planet. We therefore decided to reintroduce the role of Batman to help her out – especially when it’s evening time in France.

Follow CucumberStudio on Twitter.

More stories

Inspiring tales from companies building their projects on Scalingo

See all customer case_studies