This transcript has been edited lightly for clarity and brevity.

Emma: Hello, listeners. I am joined by two Managing Directors from two of our Tricentis partner companies; we have Roland Strahlhofer at Sixsentix and Amin Chirazi at Automators. This is going to be fun because the two of you actually know one another, both being based in Vienna and actually also in the same office building.

In this episode, we are spotlighting two of our Vienna-based partners, and they collaborate with us to help businesses world-over automate their software delivery with excellence.

Sixsentix is a leading provider of software testing services, visual analytics, and reporting for DevOps, whilst Automators is a leading consultancy in automated continuous testing and that of critical systems and processes. And of course, there are many overlaps in the solutions that you offer such as maturity assessments, SAP testing, and also in the industries you serve like banking and insurance to name just two.

What are the biggest innovations in testing that you’ve seen so far this year in 2022 for your clients?

 

Roland: I would say, I always call it the Exoskeleton of a QA engineer or a tester. I like to call them QA engineers because I think it’s a lot more than just testing, and the Exoskeleton because when you’re looking at testing and QA, it’s getting ever more, let’s say, bigger, and the complexity of the IT projects are getting more and more complex and hard to solve. And therefore, testing is getting more and more problematic, and you need to do a lot more, and you get to do quite a lot of things. And with an Exoskeleton, when you want to lift something, it’s easier to lift it. And therefore Exoskeletons are the right thing also here to really go into the whole thing and make it really easy, and there are a lot of things out there, mainly AI-based stuff. For example, at Tricentis you have LiveCompare, which is going in that direction.

We also have a product in the development area called iTest. I think both products are doing quite the same in principle. They really try to make the life of a tester, of a quality engineer, easier.

“When you change something on a car, for example, a headlight, you don’t need to test the exhaust system when you change a headlight. You probably test something like aerodynamics or electrics, but you don’t test the exhaust. You sometimes test the whole car, of course, but most of the time you only test the part that is really interesting. We do the same thing for SAP with LiveCompare, and for iTest, for example, for Java implementations.“

 

Roland: The next point is really that at the end of the day, you have a lot of issues with false positives and that’s because you test too much and you don’t know really what to test and if the systems are there.

So, first of all, what we did before, we already see that we are only testing the stuff that we want to really know that is changing something. And the second point is we check if all the systems are there. If we have all things set, we have what we call the DNA of a test case.

So, if a lot of variables we’re checking on a test case, and with that, we know if the test case makes even sense to be automated. Because that’s only like risk-based testing but a little bit more advanced. That’s mainly what we are seeing here in that area.

Emma: Brilliant! Yeah. I like that point about you’ve got this whole system, whether it’s a car, a complex IT landscape, and various applications, you wanna test what’s critical. And also, with the rise of more data that lends itself to more AI, how can we use that data intelligently to inform better with more innovation out there to exactly help liberate our testers to free their time to work on other business-critical areas. Thank you. That’s an excellent little roundup there.

Amin, what innovations in testing have you seen this year so far?

 

I think talking about this year, what I’ve seen really this year is it’s more like a mindset innovation.

“I think a lot of enterprises and companies are more aware that data pipelines and also AI or machine learning applications need to be tested the same way as other software applications need to be tested. That’s the most interesting thing for me because you see enterprises forming central teams, testing teams to serve different teams in the organization with their data projects, and try to bring in a testing strategy or a methodology, which really helps them to treat these projects as professional projects as they do with other software applications.“

 

Emma: When you say mindsets, that’s interesting. I did just look it up and this phrase, emotion AI, like, emotion-powered AI solutions, that’s something that’s obviously just getting more and more intelligent here with interpreting the data and incorporating that into the pipeline. It’s cool that both of you are recognizing that.

I spoke with Adam Arakelian at Dell on the podcast recently who’s incorporating AIOps with his teams with things like chatbots; automating services in that respect. So, you’ve got those kinds of customer-facing services, then you have the AI tools that look at which things to test. So, it’s really kind of across various touchpoints that we’re seeing that.

Amin: Maybe just to make it more precise as what I mean is, I mean, there is, of course, a lot of AI getting into the testing, right? You try to recognize stuff better with AI, but even within these enterprises, you have a lot of machine learning applications for whatever project or for whatever reason you need to have it, and that needs to be tested as well. That is the crucial point here.

Emma: Got you. So, it touches on all the applications, not just those that test specifically.

If you could both share a specific example, maybe where you’ve seen AI testing, an AI-driven application that needs to be tested, or where a client that has met, or even maybe surpassed their goals within fairly recent months?

 

Amin: Sure. I mean, machine learning within testing, I see more and more, and also what Roland mentioned in trying to figure out what tests are relevant and what should be automated first. I think where the biggest transformation happens right now in testing is actually that automated testing is not really new, right?

“You have automated testing for many years and you have even legacy technology within test automation which needs to be updated to newer technologies of test automation. I think this is a really crucial point here because even with Tricentis, as you might be aware that Tricentis classic modules, their legacy engines will soon not be supported anymore. And customers who automated a lot of test cases, and we have one customer with thousands of test cases, they need to think how to modernize their test automation stack.“

 

Amin: We were looking into this and together, we estimated around 500 days just to modernize their technology stack for test automation, to make everything run again in the new stack. And here we’ve found some innovative approaches to actually automize that migration.

So, together with a client, we built a Tosca Module Migrator, which actually helps them to do that in around 20 to 50 days, compared to the 500 days that we estimated. The first thought we had was, ‘Okay, let’s do that somewhere with a mass of people where maybe labor costs are cheaper, like investing 500 something days somewhere cheaper.’ That’s the first thing that crosses your mind, right?

But then thinking about that, actually that’s something probably you want to look into for automation and here we definitely together with the client, we were really surprised by the result. And the nice thing about it is that you actually can reuse it for everyone.

I think many clients go through this migration from classic to TBox modules, and we’re actually also partnering now with Tricentis to do it with many different clients.

Emma: Awesome! Staggering results to go from 500 to 50 days. And especially working with so many legacy systems.

Roland, which of your clients have smashed their testing goals, and how did they go about doing so?

 

Roland: When I was thinking of how to answer the question, I thought about one of our customers in the SAP area, as we’re focusing a lot on that part.

As Amin said before, it’s always interesting to work in a part, where testing in the way we are doing it now for over 10 years, is a little bit new, actually. So, SAP was doing testing in a very different way and did not go like we’re used to in the DevOps world in the way they went forward. And actually, that was or is a large leading manufacturing company; we don’t reveal names of our clients.

We just finished it as an SAP project, and they talked to another customer, and the customer said, ‘Oh, was the project cheaper now because you did testing?’ And actually, they said, ‘No, it was even a little bit more expensive.’

I was a little bit cringe-worthy recalling it, but actually, they went further and said, ‘Yes. But in total, this was the first SAP project we made on time and on budget. And when we look at the whole budget, and also the maintenance we’re now facing, we are a lot cheaper than we were before.’ Because it is like these airports that start off, which costs like a billion euros, and then you’re at 10 or 50 billion euros—in Germany you see that, we just saw it in Berlin—and it’s the same with a lot of SAP projects and IT projects in general, that you have an idea of how much it will cost. Especially when we’re doing testing, we’re not only doing the automation at the end, we’re also reviewing the requirements in the beginning. And with this review of the requirements, we’re already doing a lot there, and therefore the testers or the developers know exactly what they need to develop.

“We’re cleaning up a lot of bad communication between requirements and development because we need to ask these questions. We are asking the question: what is this thing really doing? And this is really clearing up a lot of things. And then, of course, we do the automation and that is something we can do through the whole process with Tricentis Tosca, and therefore, it makes a lot of sense to go through the whole thing, and to really shift left.“

 

Roland: But we told people for years now and you also told people for years now, but when you go to new areas, they don’t know that right now.

So, we really need to go back a little bit. And of course, there are companies have done that already for some time, but the majority don’t.

Emma: Yes, exactly. When we live in the world of automation, it’s a bubble where actually a lot of people are still manually testing with manual spreadsheets, for example, we have a lot of mid to late adopters with our software.

That’s a really good point about return on investment when you’re looking at this triad of speed, quality, and cost. It’s going to cost you more, but exactly, you’re going to do deploy much quicker and you’re going to catch the bugs earlier to save time in the long run.

Roland: Actually, I had that with another customer too. This guy was a project manager at the time and now he is a CIO.

His project went well. With Tricentis Tosca, we’re always working with large projects of our customers. It’s really also, for the customer and the people and the customer, a chance to evolve in their companies, because if these projects fail, they normally have a big issue in their companies too. That’s something we are there together with the software that we guarantee them that software is done right, and the project is a great success.

Emma: Brilliant! What you’re doing there really, it’s beyond the system. It’s a culture change when you’re planning a DevOps landscape.

So that gentleman there obviously became kind of an agent of change and was seen to succeed in that regard. That’s an awesome story.

The two of you are working often with regulated industries. How have you helped combat any kind of regulation that you? Have those kinds presented interesting challenges for you along the way?

 

Amin: These regulations are painful, actually. You have regulations in banking, and you have much stronger regulations in pharma. And in the beginning, the first years, when I went into pharma, it was really painful for me, the way they have to work because of these regulations.

And then being an agent of change there is actually even harder. You really need strong personalities which are able to challenge the people responsible for the regulation there, because not every rule really is up to date. Some things you could do differently, but people protect these rules.

“I think it needs brave people, and people with a lot of knowledge to actually improve speed in regulated industries. What you really want to have is reliability, just faster. You need to get faster with the same reliability, and you need to uphold all the regulations.“

 

Emma: As you said, a lot of resilience and thick skin is needed. You’ve got to talk to a lot of business owners or like a lot of archaic processes that are not even up to date. So, when you’re calling these things into question, it’s by no means an easy task.

Roland, what have you seen with your clients with regards to regulated industries?

 

Roland: I would like to give a little bit of contrast to that.

“For me, when I’m looking at it from a company point of view and not from a more technical angle, for the customer and for us, working together is really beneficial because if there are a lot of regulations, they need to have proof that they are meeting these regulations. And with this proof, we can give them something to work with, and give them an easier time in the long run.“

 

Roland: I fully agree with Amin. It is hard to do because regulations don’t give you much freedom and with these tight corsets, it’s hard to really implement. But as I say sometimes to my people, ‘If it would be easier, why would they need us?’

Amin: I want to give one example of where I had difficulties. It was a pharma company and they wanted to implement test automation in a proper way. So, we helped them but they had one protocol in place, which says you need to sign each test execution by hand for each test case. So, that test case is automated, that test case has been reviewed, it has been approved already, but not just that is good enough. After each execution you need it to be printed, or to take the PDF, review it, and sign it.

Now compare it to what we do. Maybe we want to run 1000s of test cases at night. So, you have somebody in the morning, going through 1000s of PDF documents. This is a regulation, I think it should be questioned if that’s the way they want to do things; is it really needed in today’s world?

You discuss these things quite harshly with people because as I said, there are people who protect policy and there are other people who try to change it, because it’s super inefficient.

Roland: You really should give him some medication for his arm afterward, because he has to sign 1000 documents.

Emma: It’s ironic, you’re trying to help eradicate manual testing but then in the end, it’s so manual to have to sign that it’s like some kind of hybrid solution in the end.

Roland, in 10 words or less, what would your best advice be for anyone undergoing digital transformation?

 

Roland: I want to quote the founder of Tricentis, Wolfgang Platz.

“Wolfgang Platz always said ‘Do the right things and do the things right.’ That’s a little bit forgotten and still so valid. It’s the easiest way to go forward.“

 

Emma: When Wolfgang was on the podcast, his answer to this was be very customer-centric. I guess that overlaps; you do things right for the customer and then you get it right.

Amin, what’s your best advice be for anyone undergoing digital transformation in less than 10 words?

 

Amin: Choose the right projects/people and create compelling pilots. I think that’s important.

Emma: Awesome! That covers the end-to-end process.

If you could change just one thing about the application development world, what would it be?

 

Amin: I think, when many, many projects start, stakeholders don’t really care about the methodology regarding how to do the project properly, and they don’t care about testing. They just try to get started, let’s say. And then when they fail, and they realize, actually, that the way they worked was not very efficient, then they implement improvements, for example, more test driven or better collaboration.

“I really think we have a lot of knowledge and experience to be able to start projects with better methodologies. I think it would make the application world much more efficient. I would like to see more test-driven projects earlier, not after failing.“

 

Emma: Yeah. So, very much the shift left approach and set that method earlier, and don’t just start it for the sake of it, really set out your requirements and set out your scope.

Amin: We hear that all the time for years. This is not new. But when you look then into the teams, it’s always the same. They start somehow and then afterward, they improve.

Roland, if you could change just one thing about the application development world, what would it be?

 

Roland: Actually, it’s kind of the same thing. Really understanding the value of quality and putting it in the right space and at the right time.

“I think quality is like insurance; if you’re not paying insurance from the first day on and something happens—like with fire insurance for your house, and if house starts burning—then the mourning is great. Everybody is like, ‘Why didn’t I do it?’. But if it’s a complex IT project, you have a fire there all the time. At the end of the day, you will need fire insurance. And if you don’t have it from the beginning, you will have an issue.“

 

So, it’s really something that you should have from the beginning. We can already help with requirements and specifications, because when you do test-driven, you’re already seeing, I need to know what to test at the end of the day. If I don’t know what to test, then you’ve made a mistake, or you didn’t do the requirements right. And if you don’t do the requirements right, you will not be able to develop it right, because there will be misunderstandings between the developer and the requirements, and at the end of the day, we will test something which is probably not right, or where there are some misunderstandings.

At the end of the day, without a test-driven approach, you will really have a lot more issues with your project. Fire will start flaming, and if you don’t do things when the fire starts flaming, you will have the house burning. And then the fire brigade will come, but if fire brigade is coming and they use water, the main damage was already done. You try to fix it and you pour water on it and the whole project was mayhem, and then the mourning is really bad and big, and everybody’s saying something, like, ‘Oh, why didn’t I do it?’ And then you already have a lot of cost issues.

If we do testing right now, the cost has already occurred, and we don’t have to spend anymore. It’s getting worse and worse. The seventh principle of highly effective people is sharpening the saw. If you’re sawing and you have a dull saw, then it’s not going forward. Sharpen it, and then you go through the wood; it’s no issue then.

Emma: Brilliant! I like this analogy with fire. Of course, you can expect challenges along the way. But don’t let it get to the fire state where the fire drills are going off and the fire brigade coming. You might have sparks along the way, but not at crisis point right before software delivery.

Outro

 

Awesome to hear from Roland and Amin who are doing fantastic work and helping organizations automate their software delivery with excellence.

Check out the latest podcast episodes for more insights from thought leaders like Roland and Amin.