This transcript has been edited lightly for clarity and brevity.

Emma: Hello listeners, it’s your host Emma. Today it’s a warm welcome to Torsten Welp, Software Quality Architect at Mobiliar, one of our Tricentis customers. Torsten is an expert in scaling DevOps and all sorts of other things.

This is the first episode of our Insurance Testing Innovation series, where I’ll be chatting with leaders who lead the charge in testing complex insurance software that customers can depend on.

Today, we are spotlighting Mobiliar, the Swiss Mobiliar insurance company and the oldest private insurer of Switzerland. You cater for all insurance needs in a fully digitized capacity for thousands of customers, so the demands of your software are understandably very high. Torsten, you’ve partnered here with us here for many years, previously also at Viseca Credit Card Services, so you’re used to operating in highly regulated industries.

At Mobiliar you work entirely Agile, and I understand you underwent that transition to align better with customer needs. How has this transformation impacted the quality of your software?

 

Torsten: With digital transformation, we decided to implement an Agile development organization. That means we work with feature teams, release trains and solution trains; we don’t have any projects anymore, or fixed milestones. Automatically, we switch to shift left and DevOps, meaning all disciplines develop and operate software in one feature team. This means the embedded tester works closely together with software developers and product owners.

Due to the short release of software units named microservices, the quality assured is more technically driven. We release software 30 times a day into production. But technical-driven has some disadvantages because it’s more than checking only the quality of technical components or its integration into the application and scale.

“You cannot automate everything or believe in monitoring application numbers that the performance is high at any given moment; 9.5 out of 10 on the scale, for example. Our experience is that humans are also needed. We need a customer view in all development activities.”

 

Torsten: For example, we are using feature toggles, giving us the possibility to enable or disable features during runtime in production, so that you have two different views of the application usage. We also have special user groups trying out this new functionality and giving us direct feedback: if it’s feasible or not, what is missing. This idea of rapid feedback cycles is that it gives better software in usage out of the technical view. Another example is the customer survey. We’re asking our customers on a regular basis for feedback, for example, whether the performance of applications is running up-to-speed or not.

Emma: It’s great that you’re clearly so customer-driven, especially in that DevOps Agile environment where you’re releasing phenomenally quickly at 30 times a day. The fact that you’re also factoring in the user experience, their opinion, is awesome.

You mentioned you have faster release cycles, which you said is not without its difficulties. I guess you’re seeing reduced production errors as well if you’re having your customers test those different environments?

 

Torsten: Yes, that’s right. One interesting bit of feedback is that we are sometimes too fast. Too fast means too many changes, and the user needs to be aware of them and learn them, and they also need some stability. You cannot change it too often, and then this is feedback from the customer.

Emma: I guess that’s a good predicament to have because we hear so often in our industry that you want to achieve quality at speed. Clearly you’re achieving quality at a very high speed, but you want to take account of the user experience for them to familiarize and really sink into the software.

Torsten: Exactly.

Emma: We have been working on many different aspects across different organizations, and one thing that’s very exciting for us is that you’ve been working closely with us in implementing our Continuous Testing Framework.

How has the Tricentis Continuous Testing Framework helped shape your testing practices at Mobiliar so far?

 

Torsten: As mentioned we do continuous deployment and continuous releasing on a daily basis. This kind of releasing; we name it Agile releasing on-demand.

“All the buzzword topics—like shift left, DevSecOps, continuous releasing, observability—are established by Mobiliar. To point out this speed, when we build new software, the expectation is that we get the test results within one hour. It doesn’t matter if it is progression or regression, it must be tested very fast. So you have automated the test before you build the software. That’s clear test-driven development.“

 

Torsten: What are our challenges for the software quality team? Everything outside of the feature teams is complex to test, because we have complex business processes and integration of these software units. There are sometimes errors in system integration and end-to-end testing. Defect leakage is one topic we’re aware of.

At Accelerate in Vienna in 2019, we saw the presentation about the Continuous Testing Framework by Jori Ramakers. There we found out that we have around 60% of this framework in place in our organization, and for the other 40%, we get some really good advice how to manage testing at an enterprise level. That’s where we have weaknesses in this area. Topics are test tool integration, reusing test artifacts, the role of the enterprise test architect, and the possibilities to have additional system testing teams.

Emma: Great. It sounds like you have had many insights across the board then that you’re feeding into your continuous testing CI/CD pipeline at Mobiliar. It’s awesome to know that the seed was planted way back in 2019 at Accelerate. 60% of what you’re applying comes from this framework; that is phenomenal, especially when you’re talking about the results that you’re seeing such as test results within one hour. I like this Agile releasing on demand; you’re really advanced in terms of your agility.

Part 1 outro

 

Emma: Torsten doesn’t shy away from embracing Agile in its fullest sense and applying the entire framework, and in speaking openly about its benefits and challenges, there’s a lot to learn from him! Releasing software on demand, 30 times a day into production, Mobiliar keeps pace by testing quickly and smartly and embedding DevOps principles into the testing lifecycle. The enlightening customer feedback that sometimes releases come at them too fast reminds us that speed should not be the standalone focus.

Check out how the Tricentis Continuous Testing Framework can help you successfully navigate your Agile testing cycle.

Part 2

 

Emma: Something else which feeds into being Agile; all of your services are based on microservices, so you’re very mature in terms of your cloud journey.

I’d love to hear some of the benefits of utilizing microservices.

 

Torsten: First of all, I have to explain what microservices are. Microservices are small software units in an overall application; that’s the reason why they are microservices. They can be developed and released independent from other units, so they have to be upgraded and downgradeable when you deploy so that they are still working independent from other versions.

“A benefit of microservices is that feature teams can develop them independent from other feature teams. You get more speed in the Agile development process because communication is reduced. You don’t have to make any release plans and you don’t need release management; you can really have this Agile release on-demand. On-demand means I want to deploy in 10 minutes, so I deploy in 10 minutes, because I’m ready.“

 

Torsten: Another advantage is when you deploy a microservice in production, and you have an undetected error, the root cause analysis is much more simple because you change central production and not a monolith application. So identifying this error is much easier because normally you know what you have changed, and it’s monitored in this area.

Also, when you monitor microservices and something is slow, then you have an indication about what is slow in this area. With monolith, you are not aware about which part of the monolith is not working correctly in this area. Microservices are independent from cloud or on-prem; you can use them also on-prem, but in combination with cloud we are using a Software as a Service (SaaS) model. Software as a Service means that you don’t have any infrastructure anymore, you take this microservice and then this infrastructure is code. You define which RAM disk space and the CPUs the microservice is using, and you don’t have to set up a Linux machine, a Windows machine; that is all gone. So you get more flexibility and scalability for your IT applications.

Emma: Yes, that move from the monolithic applications to microservices is going to improve the scalability, and it’s really great to hear that you can better isolate bugs and faults leading to more resilient applications. In the end, it’s quite an empowering for your teams as they’re not as dependent on other teams in order to keep up those fast release cycles and keep up with that speed of innovation.

You’re obviously at the edge of innovation and being Agile. I’m sure there’s lots on the table, but of course, in being Agile, you don’t always know what’s around the corner in a few months’ time.

I’m interested to know what you have planned for right now and for 2022 as it stands. I’m aware that you test SAP applications and that’s a relatively new venture, so I imagine that might be high on the agenda?

 

Torsten: First of all, it’s SAP applications where we are really using test automation with Tosca; that’s a really good a challenge, as I mentioned, with end-to-end testing.

“One of the ends is the finance application; SAP of course. When those units are using the same automation tool, it’s much easier to combine an end-to-end test. When the tools are different, it’s not so easy in this area. We have to learn how end-to-end testing is really working with the applications in this area. Then we will work on the Continuous Testing Framework to implement the rules, and that always needs time.“

 

Torsten: Another thing [on our agenda] is better tool integration for test planning, for combined observability data with test automation. Observability is the monitoring of the software in production with several things, and then how the application is used in production is important for the test planning and the test scope within one hour, because you have one hour time to deliver the test results.

Emma: Sounds like you’re covering a lot of bases from the framework that you’re building your applications on through to testing it, as you say, with the test automation with Tosca for SAP. And once it’s out there in production, closely monitoring that to see that it’s up to speed and fulfilling the initial requirements.

In 10 words or less, what advice would you give to others working on digital transformations, particularly in a regulated field like insurance?

 

Torsten: There are a lot of things. Digital transformations change the company culture. Be patient and establish a learning mindset with a positive work culture; that’s my advice.

Emma: Brilliant. When Speaking with Adam Arakelian, Senior Director of Engineering at Dell, he shared that his DevOps mindset is also related to that. He sees it as a philosophy, it’s not that you just do Agile DevOps as a tool. It has to be embraced and be embedded into the culture in order to work, so it’s awesome to hear that you have a very similar outlook there.

If you could wave a magic wand, what would you change about the application development world today?

 

Torsten: I have a message for feature teams. Sometimes I think the shift left is too left, too independent. Feature teams, be aware that networking is a must, not only working independently.

Emma: Yeah. Shift left, but not so far left that you’re not talking to anybody; you have to strike that balance.

Part 2 outro

 

Torsten has expertly shed light on the DevOps lifecycle at Mobiliar, with his 101 on microservices contextualizing how they are able to release on-demand. In striving for more and continuously adapting to industry needs, Torsten recognizes that getting to grips with the end-to-end testing of SAP applications is critical to their success, as well as improving the observability of their applications to inform their testing.

One major takeaway: when shifting left, don’t shift so far left that you fall off the communication cliff!

Check out the latest podcast episodes for more insights from thought leaders like Torsten.