The genesis of Squash AUTOM and Squash DEVOPS
This article was originally published in French.
A look at our projects Squash AUTOM and Squash DEVOPS and their genesis.
Squash TM is a test case manager. It enables you to collect multiple test cases, to write, organize, and execute them, and to present the results of these executions.
In the beginning, tests executions were manual: someone had to execute all of the steps described and report the results.
Manual execution enables you to cover all the needs of functional testing, but it is not optimal: if some tests can only be executed manually, many of them could be automated.
Automated tests enable new uses: they can be executed much more often, outside working hours if necessary, and therefore can intervene earlier in application development cycles.
With Squash TA and Squash TF, we have made a first step towards these new types of use, by allowing the implementation and the execution of automated tests.
With Squash AUTOM and Squash DEVOPS, we want to go further.
Functionally, Squash AUTOM and Squash DEVOPS are automated test execution tools. Using a list of automated tests, which are defined in one or multiple test repositories, they coordinate the execution of the required tests from existing execution environments to a deployed SUT (system under test).
Test execution reports can be published for one or multiple recipients, test case managers, and viewing and reporting platforms.
A quality gate, fed by these same execution reports, can be implemented.
Test executions can be started on request (Squash AUTOM) or as a step of a CI/CD pipeline (Squash DEVOPS).
The list of tests to execute is either dynamically fed by one or multiple test case managers or explicitly constructed. The tests to execute can make use of any number of test automatons.
Since we think it is essential that these features are open and that everyone can contribute, we provide a set of open specifications with an open source reference implementation, all offered in the framework of the OpenTestFactory.
Squash AUTOM and Squash DEVOPS are two “distributions” of this reference implementation adapted to their specific needs.
They allow for a simple and quick adaptation to new needs: new continuous integration tool, new automation framework, adaptation to an existing asset of automated tests in a framework developed internally, publication of reports in a BI tool, etc.
They also allow the integration of new features by third-party companies or in-house developers.
The heart of the reference implementation is made of an orchestrator and a number of specifications that determine the interactions between components and plugins.
The orchestrator is no longer Jenkins (contrarily to Squash TA / Squash TF) but an implementation specific to these tools, because its evolution rhythm turned out to be unmanageable.
We are not the only ones to have chosen this path. In the absence of a neutral de facto standard allowing tools to integrate pipelines, Gitlab, Github, JFrog, and Atlassian amongst others have also chosen this path.
The orchestrator’s features remain the same. The components and plugins are directed towards our needs (automated frameworks, test case managers, with publication tools for the test reports). Ultimately, the orchestrator provides the same basic features as any other orchestrator.
The specifications that determine the interactions between components and plugins were carefully examined so that they are simple to understand and to use.
They are based on known technologies that are largely supported (REST API, JSON exchange format) and enable simple developments and implementations.
Thanks to this use of known, largely supported technologies, they do not impose any specific language or software environment.
The reference implementation is written in Python, and the additional components of the Squash AUTOM and Squash DEVOPS “distributions” are mostly written in Java.
The chosen architecture, a set of micro-services communicating via an event channel, provides great flexibility for the implementation, whether it is for an installation on an isolated system, a unique Docker container, or a Kubernetes cluster.
Therefore, Squash AUTOM and Squash DEVOPS can be easily integrated in numerous contexts, without any particular technology or architecture.
Finally, security being the main priority, execution requests are managed via the use of signed JWT tokens. Communication with the execution environments from which the tests will be executed can be done via SSH (from the orchestrator to an execution environment) or via an agent installed on the execution environment and that regularly polls the orchestrator (from the execution environment to the orchestrator).
In future articles, we will come back in more details on what these choices allow for, and how they can help you on a daily basis.
Martin Lafaix
Architect
Learn more:
