The Squash adventure began 10 years ago. Here is a review of the evolution of our product and pricing strategies and the reflections that led to the release of our new product offer, effective from the beginning of 2021.
Squash TM
On the Test Management part, we wanted an efficient, user-friendly test management tool for testers (primarily those from our company Henix) who use it intensively.
We also wanted an accessible tool (i.e. free for small companies, not too expensive for others) in order to widely implement good testing practices and contribute to the professionalization of tester's job.
Squash TM was designed and has been evolving since the beginning with this in mind, with quarterly and then half-yearly versions (Squash TM 1.22 will be released at the end of 2020).
In the spring of 2021, we will release a major version (Squash TM 2.0) with updated ergonomics (rewriting of the front in angular while keeping the same back, therefore with a standard version upgrade).
Our objectives of 10 years ago have generally been achieved, since the tool has been widely distributed (around 2000 downloads per month) in open source, major accounts have adopted it as their only legacy test tool (up to 4000+ users), good test practices have spread and Henix's service activity has increased from 50 to 250 people in 10 years.
On this module, our product challenge (for the next decade?) is to continue to enrich functionally on the axes:
Positioning tests more at the heart of application design, and then test assets as living documentation of the application assets,
Provide different representations of tests according to methodology, organization, project lifecycle from natural language, structured (gherkin) interpretable, then executable.
And we are currently studying the possibility of proposing an integrated agility management tool ourselves, with the objective of supplying a new Squash_Agile product at the end of 2021 that will enable Scrum/Kanban and SAFe/LeSS agility frameworks to be tooled.
From Squash TA to Squash Autom and Squash DevOps
On the Automation and DevOps part, and more broadly the shift-right, our path has been less linear. Initially, we wanted to offer a complete automated test environment, accessible to testers with a technical taste as well as to developers. So, in 2012, we released the Squash TA module, which was both a studio and an automated test execution environment. We then (slowly) understood 3 things:
Developers or automation specialists had not waited for us to choose their preferred development environment (studio) and had no intention to change it.
It is expensive (and out of our native "Software Quality" expertise) to make a "universal" studio especially if we want to adapt to the specificities of all systems under test.
And above all, the 'test' issue of a successful digital transition is not to automate tests, but rather to tool the process between functional tester, automation engineer, developer and devops so that the "right" test is automated at the "right" time. Concretely, in most of our customers' Systems Under Test (*), we believe that the economic optimum is to automate little, as the application stabilizes by ensuring that each automated test will be useful and can be maintained. The right way to ensure this is to integrate the automated tests into the CI/CD pipeline and sort between regression and false positives during development.
We therefore released Squash TF 1.x at the end of 2018, which was an automated test execution environment, reusing the Squash TA architecture. This module is now encountering architectural limitations that have prompted us to completely rewrite it during this year 2020 with the following principles:
Micro-service architecture, especially for deployment and operability reasons in DevOps environment.
Separation between the features allowing automation (for testers and automation engineers) and those allowing the integration of automated tests (for the pipeline manager) within the DevOps factory. This gave rise to 2 products (cleverly) named Squash_Autom and Squash_DevOps.
Removal of the adherence with Squash TM so that each of the 3 products Squash TM, Squash_Autom and Squash_DevOps are independent.
On the 2 new products, we are looking to bring value even for companies or projects not using Squash TM:
The use of Squash Autom "alone" allows to unify/homogenize the use of different automatons (Selenium, Cypress, SoapUI, Appium...) and different studios (Robot Framework, Cucumber, UFT, Agilitest...) while generating a common reporting format (Allure type).
The use of Squash DevOps "alone" allows to orchestrate all the automated tests, integrate them into the DevOps pipeline (CI/CD) and then post the results to the recipients (the pipeline itself, the test asset tool or the framework for reporting and aggregating test results).
In all these developments, we have always sought to ensure backward compatibility, i.e. that tests written with Squash TA or Squash TF continue to work from version to version and with the installation of Squash_Autom and Squash_DevOps.
Monetizing means (also) perpetuating
We were fortunate to be able to launch and develop the project for a long time without really worrying about monetization, both because we benefited from research tax credit grants in 2011-2013 and because the future benefits in terms of reputation for Henix were enough for us. Then we realized that without monetization, we would not have the means to develop the product as we had hoped over time.
So, we experimented with different classic models in the Open Source world, such as selling support, dual licensing, fixed licensing, etc. We then tried out different models. We finally opted for an "open core" model with:
a free Community version made up of open source core and freemium modules
a commercial version, with annual subscription, composed of the Community version and commercial plugins.
In the choice of the free vs. paid functionalities, we try to position the cursor in order to provide a fully functional (not restricted) Community version. The paid version (Premium) is differentiated with additional connectors (to paid tools in general) or additional value-added, but not essential, features and support. In our opinion, the existence and maintenance of this Community version (with the same core) limits the "vendor lock in" and allows our customers to have the best possible counter-power in case of abuse by the publisher: switching back to the Community version by giving up the commercial features.
For the pricing mechanics of Squash TM Premium, we looked for a simple identical model, for SaaS and server version. We chose the (former) Jira Server model with price ranges according to the number of users declared, which seemed to us both simple to understand and to implement. We opted for a price base (in the server version) of 50 users for 6,000 euros (10 euros / user / month), unchanged since the beginning (with a cost of 3 to 10* less than our historical competitor, but which seems sufficient to us).
For the other modules, Squash Autom and Squash DevOps (which are composed of services and not applications and where the notion of user has less meaning), we chose to set the price of the Premium version as a percentage of the Squash TM price base (in this case 75% for Squash Autom and 75% for Squash DevOps). And for customers wishing to use Squash_Autom or Squash_DevOps in commercial version without Squash TM, we will base our pricing on the number of users of their test repository. Current customers of the commercial version of Squash TF (called Enterprise version) will be offered the Premium versions of Squash Autom and Squash DevOps without additional costs (until 2022).
With agility and DevOps, testing is positioned at the heart of IS manufacturing and digital transition, the coming decade promises to be exciting!!
The Squash Product Team.
(*) This remark concerns our customers' current IS, which are characterized by many lines of code and a high sensitivity of tests to the data (it is different for example on embedded computer architectures or pure micro-service or API architectures).