TCS Organization and Test Automation History

Founded in 1896 by a group of cyclists in Geneva, Touring Club Suisse (TCS, www.tcs.ch ) is the leader in the mobility sector in Switzerland, with more than 1.5 million members. TCS provides services beyond insurance and road assistance, including education and driving courses, vehicle equipment tests (child car sits, tires, etc.), and juridical assistance. It is also active in the tourism sector, managing campings all around Switzerland.

Many of us with good experience in the IT sector have seen at least one IT project that, like a skeleton in the closet, stayed in the company’s memory. I arrived at TCS while the company was undertaking this type of project. The project lasted 2 years (pure waterfall approach) but needed 2 more years to be “stabilized.” The objective was to replace the old ERP developed on the IBM AS400 platform with a modern cloud solution based on Salesforce.

It went “so wrong” that after a few months from the go-live, the company mandated an external audit to assess the technical debt and define a stabilization plan. The audit, among other things, discovered that the manual testing effort was way too big and that tests had to be automated.

As part of the stabilization program, I was in charge of filling the Test Automation gap. I hired one of the most skilled developers I knew to build a Test Automation framework using Selenium and Cucumber. We managed to build something quite solid: Gherkin tests defined in JIRA via XRay, implemented via Selenium Web Driver with the Page Objects approach, and a Jenkins job that executed the tests nightly and reported back results to JIRA. This project also had unit tests for testing the testing code. At the end of the mission, we handed over the testing framework to the internal developers with no previous experience with Selenium.

Nice job in the end, but not the easiest thing to maintain. The biggest constraint was that only two internal developers were trained to work with it. Over time, their availability for maintaining and extending the framework was too low compared to the time allocated to fixing bugs and developing new features.

The framework covered most of the main business processes. However, the heavily customized Salesforce instance, with heavy web pages and slow background batch processes, made some of the automated tests flaky. Nonetheless, we managed to address most of the random and timing related issues, sometimes in the test code, sometimes directly on Salesforce.

A Jenkins Cucumber report in a tabular format. It lists the steps, scenarios, and features of the business processes.

Jenkins Cucumber reports for the Selenium-based framework

A screenshot of the salesforce application. The highlighted source link on the left panel opens multiple folders on the right.

Code repository of the Selenium-based framework

I also managed to involve business analysts and developers and have them take ownership of the framework. Nightly runs were checked every morning, and production deployments were accepted only with the green light from the automated regression tests.

The feedback I received from the developers maintaining this framework was pointing at the technological stack complexity as the number one pain point. The dependency from WebDriver was also an issue, especially when tests failed due to a UI element change that is not visible to the end users (see also Chapter 2, “Selenium:​ Best Practices and Pain Points”).

NIS Project Introduction

The General Director of TCS is the sponsor of the NIS project. The project goal is to provide TCS with a standard Policy and Claim Administration System (PCAS) to speed up the time to market and build products aligned with our customer’s needs. At the same time, the management wanted to align TCS systems and adopt international industry standards.

The new PCAS system will replace all the custom code developed in Salesforce to manage the product catalog and the logic related to the sales process and contract life cycle. Claims management is also part of the project’s scope.

The PCAS is a COTS solution built in Java and running on a JBoss server with an MS SQL Server database.

SalesForce will stay as master for all customers’ data (CRM), and all these data will be pushed to the PCAS.

In addition to the out of the box GUI provided by the PCAS, the project will introduce a new GUI system to allow contact center agents to perform quick sales operations and respond effectively to customer requests.

Integration and interfaces will be one of the main topics because, besides SalesForce, the PCAS will interface with SAP, the tcs.ch website, the TCS mobile app, and other systems, internal and external. All these integrations will be based on REST APIs developed in the IBM API Connect platform. API testing will be crucial for the success of this project.

The following picture shows a high-level architecture diagram of the project’s scope, with more than 40 interfaces to systems within and outside the TCS domain.

An architectural diagram of policy and claim administration system. It has e-com, sales, back office, claim, and service management sections.

High-Level Architecture View of the NIS Project

This NIS project started after a pilot phase where we became familiar with the new system and evaluated the pros and cons. During the pilot phase, where the PCAS went live with a single TCS product, the testing effort was an issue. The pilot project’s relatively small team did not have enough capacity to test all the delivered features, and the UAT phase was quite intense. Many issues were found during UAT but promptly addressed.

During the NIS project , therefore, a small team for Test Automation was created. Besides myself in the role of Test Automation stream leader, we added to the team an experienced Test Automation engineer, and a senior business analyst with development and QA background.

Test Automation Stream, NISTA Setup

NISTA stands for NIS Test Automation , and it is the acronym we use for the Test Automation stream of the project.

With the first option, you have fewer refactoring risks, but you also lose parts of the automation benefits since you have to do more manual tests.

With the second option, you need to consider that the UI or the APIs are not ready yet, and are subject to frequent changes: therefore, higher refactoring risk. However, the automation scripts will be ready to be exploited sooner than with the first option.

We decided to go with the second option, but have one Sprint of delay with respect to the implementation sprints. This way, we would have time to practice and work with a more stable system, on the already implemented and manually tested Stories. Our main objective is to have sufficient coverage before the final UAT phase so that the UAT will focus on validating the delivered features more than finding bugs.

We do not have predefined coverage objectives; our primary goal is to cover all the main business processes on the GUI and at the API level. We are going to set our Sprint and coverage objectives along the way based on the delivered features