Do you know Tricentis Tosca... has made CI/CD integration even easier? (part 1)

Welcome back! In my previous article about Tosca and CI pipelines I explained, among other things, how you can connect Tosca with Azure DevOps and a GitHub repository. The so-called Tosca CI client was used, which has become “legacy” in Tosca version 15.2. In the ever-transforming and innovative world of information and communication technology, in which cloud technology plays an increasingly important role, Tricentis has opted for more flexible “CI solutions”. For Tosca, these are the Tosca Execution Client, and the Tosca Server Execution API respectively. This article focuses on the Tosca Execution Client, and the Tosca Server Execution API will be discussed in my next article (part 2).

First, let's take a step back and analyze which trends are currently playing in the “Agile and DevOps world”, with a special focus on test tooling. According to Gartner we see a trend of DevOps towards so-called "Value Streams"; from “collaborative approach” to maximize results (DevOps) towards a continuous flow of optimization of value and quality (Value Streams). The CI for “Continuous Integration” is accompanied by the CI for “Continuous Improvement”, a term that has been used many times and can be easily categorized under CI/CD, but is a matter of definition. This is all still abstract, but what do the trends look like for test tooling in concrete terms?

If we look at an open source test automation framework such as Selenium, we see that Selenium has gone through a nice development period, partly thanks to an (inter)active worldwide online community. What started in 2004 as a “small Javascript project” by an engineer at Thoughtworks, grew into a mega open source project, from which almost every IT organization worldwide (whether partially or indirectly) still reaps the benefits. But rewind in time for a moment!

In the period after 2004, the “Selenium community” soon discovered that the “JavascriptTestRunner” was not yet completely flawless in web or GUI testing, due to the so-called "Same Origin Policy". To solve this problem, another engineer at Thoughtworks developed Selenium RC (Remote Control of Selenium 1). During that period, the name Selenium was introduced, derived from the chemical element “Se” with atomic number 34. With the subsequent introduction of the “WebDriver”, automatic testing of web applications became even easier: Selenium RC and WebDriver were “merged” into Selenium 2 in 2008. In the intervening period, a lot has changed in front-end development worldwide, especially how people started looking at web development. In the beginning, developers had fewer development tools at their disposal. For example, a front-end developer had only the Document Object Model (DOM) and a handful of web APIs to manipulate the content structure that a “Single Page” was supposed to represent. With the introduction of the “Abstraction Layer” such as JQuery, DOM manipulation became easier. At the same time, this meant that test tools, such as the popular Selenium, had to innovate and develop along with it. Innovative ideas in the front-end area (responsive designs, etc.) continue with the introduction of modern Javascript frameworks, such as React and Angular. Parallel to this, and partly due to stormy developments in the field of mobile technology, “Selenium side kick” Appium was born in 2011. Proper testing of mobile applications became more and more important, and still is very important!

The community further developed Selenium and through innovations in cloud technology, several IT companies came up with new ideas and initiatives for testing in the cloud using. Selenium, think of SauceLabs  and  BrowserStack . With the introduction of Selenium 4 at the end of 2021, a new “testing” era had begun, especially a period in which test automation was no longer just “a party” for test engineers.

Testing, and quality in general, is an integral and inseparable part of the entire software development process, from start to finish; The entire chain, from blueprint via drawing board and development to the end user. Test automation without CI/CD is not test automation. And this is (fortunately) reflected in the basic principles of DevOps and CI/CD. A test tool that is not “compatible” with other tools or does not have extensive integration options will not last long in the “CI/CD spectrum”. It is not without reason, that Tricentis recently acquired  Testim, an “AI-based SaaS test automation platform”. Testim is a cloud platform that covers almost all important “testing facets”. Think, for example, of preparing and executing the scripts, recording, maintenance, error handling, reporting and a number of other useful features. With Selenium “under the hood” in combination with The concept of “dynamic locators” allows more test levels at the same time.

Tosca Execution Client

And now back to what it's all about: the Tosca Execution Client! Let's assume a scenario where the customer hires a specialist to set up a distributed test process in an already set up Tosca infrastructure. To keep it simple, the “already set up Tosca infrastructure” in my case is a locally provisioned Tosca Commander, Tosca Server and DEX Agent. In addition, the Tosca Server is configured with the “http” protocol. For those who want to know more about configuring with “https”, keep an eye on my blogs!

How are we going to achieve a distributed testing process based on my “local scenario”? First of all, we need the tools to build the test tool chain. In this scenario, we first of all need the Tosca Execution Client as a “mediator” for executing the test events. The Tosca Execution Client can be downloaded from GitHub, where it is maintained by Tricentis (see link at the bottom of the article). Once you have downloaded the client, the folder structure will look like this (see figure 1).

In my case I created a local “CI” folder, in which I placed the “Tosca Execution Client” as a subfolder. In the subfolder are 3 files, and for our local Windows machine, we are going to use the Powershell script (“tosca_execution_clent.ps1”), a script-based client. The script uses the “Execution API” of the Tosca Server. The other script is for Linux machines. Before we start with the script, the starting situation on the Tosca server should look like this for the DEX monitor (see figure 2).

In other words, the connection between Tosca Server and DEX Agent must be OK/Successful. Furthermore, it is important to know that DEX in the new Tosca version (from 15.2) only works with AOS (Automation Object Service). Of course you also have to configure a few things in both Tosca Commander and Tosca Server, but this is assumed to be known. In Tosca Commander I have a workspace, in which I have created a Test Event with a simple intake test, see figure 3.

And now it's time for a first test with the Tosca Execution Client! How do we do that? As you know, the Tosca Execution Client is “script-based” and Tosca Commander is not needed for the test execution. The next step is to check in your workspace in question and then close your workspace properly. Next, navigate to the “Tosca Execution Client” folder and open the Powershell window at that level, as shown in Figure 4.

Let's start with a simple script-based test command. In figure 5 I have added a test command in which to execute a Test Event from Tosca workspace called “DEX”.

In the above command, first the client script (“tosca_execution_client.ps1”) is called, and then pass 3 parameters, namely:

• “toscaServerUrl”
• “events”
• “projectName”

The names of the above parameters speak for themselves. Note that the hostname of the Tosca Server can be identified as the URL of the Tosca Server, otherwise the client will not be able to communicate with the “Execution API” of the Tosca Server. In addition, it is important to know that organizational policies can block the running of Powershell scripts. To set up a script-based test infrastructure, it is important to include all stakeholders in the communication lines, including the team or department responsible for infrastructure and security.

If we then click ENTER, the Test Event becomes “0 | Run test” from the “DEX” workspace. When the Test Event on DEX is successfully completed, 2 additional sub-folders will appear in the “root folder” (see figure 6).

This concerns the sub-folders “logs” and “results”. The first folder stores the client logs and the second folder stores the test results. Relevant test results are also loaded into the “ExecutionList” folder of Tosca Commander. If we look at the DEX monitor on the Tosca Server, we see that Test Event “0 | Test” has been successfully executed by the Tosca Execution Client (see figure 7).

If we then open workspace “DEX” in Tosca Commander, we see that the test results in figure 8 are neatly displayed in the “ExecutionList”.

Now we have successfully realized the first part of “CI”, but we are not there yet! Do you want to know more and are you curious how it ends? Then keep an eye on my blogs! In part two, I will use CI tool Jenkins, link it to a GitHub repository and go deeper into the “Tosca Server Execution API”. Stay tuned!

More information about Tosca Execution Client and Tosca CI/CD:

• Tosca Execution Client (on Github)
• Tosca CI/CD documentation