Interview with Christophe Bliard, developer and co-founder of HipTest, the first continuous testing platform dedicated to agile and DevOps teams.
My name is Christophe Bliard, a developer at HipTest and one of the 5 co-founders of the business. After several months spent working on the project in Séverine’s playroom (one of the 5 co-founders), we launched HipTest in 2015.
HipTest has scaled up and we are now 18 strong including a team of around 10 developers in Besançon.
What is HipTest and what problems does the platform solve?
HipTest 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).
HipTest 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, HipTest offers a feature called “Living Documentation” which means that updated documentation is always accessible, so everyone can have an instant snapshot of what has been developed. The added extra is that this documentation is written in plain text that everyone can understand.
Another strong point with HipTest is test automation. With HipTest, you can generate executable scripts for the framework of your choice (we support nearly 25 frameworks). A real time-saver!
What is Behavior Driven Development (BDD)? And what’s the difference with Test Driven Development (TDD)?
BDD is an agile method which aims to foster collaboration between different stakeholders working on the same project (developers, testers, product owners, businesses etc.), in order 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 are 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 HipTest 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 since HipTest has been hosted on Scalingo since December 2015!
HipTest has been hosted on Scalingo since December 2015!
HipTest 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 be 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.
Deployment on Scalingo is carried out with a multi-buildpack including Ruby, Node, EmberJS et 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 225.5 GB of data.
Our open source service HipTest Publisher is also hosted on Scalingo. It automatically generates test suites in different programming languages from scenarios written on HipTest, Our clients can also download and execute HipTest Publisher from their development machines.
Finally, the latest announcement about the Scalingo database API which makes downloading backups easier, means we can now envisage new workflows, such as rebuilding local test environments on physical servers in our own offices.
Any behind-the-scenes stories to share?
Organizing the support side
When the company 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 extra back-up 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 French time.
Working with Area17
From the very first code lines written for HipTest, we realized that the user interface (UI) and user experience (UX) represented two key challenges. To start with, we got along using our own means as “developers”. It wasn’t always perfect, but it worked. We then decided to build up a strong brand and design, as we were convinced that this would have a high impact in terms of client perception and therefore lead to growth. We worked with Area17, a design and communication agency. You can consult Area17’s work for HipTest at the following address: https://archive.area17.com/2018_hiptest/
What Scalingo features are you most eagerly awaiting?
I can’t wait for the new team and organization management system, which will mean I spend less time doing all the admin!
Likewise, with the size of our PostgreSQL database, some data migrations can prove to be difficult to manage, especially when they lock down the table for a time. With the new Business offer that Scalingo is proposing, with a master and a hot standby, not to mention Point In Time Recovery (PITR), I am more than confident in what the platform has to offer.
Follow Hiptest on Twitter.