The Tosca Difference

When I first joined Tricentis, Tosca had the reputation for being an excellent test automation solution, but I honestly assumed that under the covers, it was pretty much the same as all the other test automation tools I had seen over the years. I was wrong. Tosca is truly unique…but I have found it can be a challenge to articulate this well. The following is my humble attempt to shed light on what sets it apart.

Tosca has a number of unique differentiators: integrated test data management, intelligent test case design (which minimizes the number of tests you need to run), API and CLI interfaces that make integrating into your CI/CD pipeline a breeze and a single UI that supports building end-to-end tests across 160 different technology stacks. But the feature I want to focus on here is “no-code, model-based” test creation.

Model Based testing, at least the variation core to Tosca, separates the objects that make up an application from the data used to exercise the application. In computer science speak, this feels similar to the seismic difference between linear programming and object oriented programming. Many other test automation solutions would allow you to implement this sort of “separation of concerns”, but what makes Tosca different is that it inherently forces you into this model and the best practices that come with it.

The benefit of this approach at not trivial. Here are some of the key benefits of separating data and logic in a coding project:

• Modularity?– It enables different modules/units to focus on specific concerns like data handling or business logic. This modularization makes code more organized.
• Loose coupling?– Dependencies between data and logic code are minimized. This allows easier change and maintenance of one without impacting the other.
• Maintainability?– Data and logic changes can be isolated. For example, changing data structures doesn’t require logic code changes. This makes maintenance easier over time.
• Flexibility?– Data and logic can be extended or replaced independently as needs change. Adding new features may not require rewriting other unrelated code.
• Reusability?– Logic and data components can be reused across applications. For example, shared libraries for data access separate from custom application logic.
• Testing?– Data and logic sections can be tested independently. Specific logic paths or data scenarios can be isolated for testing.
• Readability?– Separation of code into well-defined areas of responsibility improves understandability.
• Collaboration?– Teams can independently work on logic or data components that get integrated together.
• Scalability?– Application logic can work with different data sources. Logic doesn’t have to change as data volumes scale.

These are the Holy Grail of test automation. For years, they have been the elusive goal and promise of many test automation solutions and they appear to achieve reality in Tosca.

Results

If you review any Tricentis marketing material, you will see some pretty incredible claims:

• 80% faster test creation compared to scripting thanks to model-based design
• 70% maintenance cost reduction from automated test generation and centralized changes
• 300-500% improved test coverage enabled by auto-generation from models
• 80% reduction in test data overhead by reusing assets
• 90% improvement in test stability from automatically updating tests
• 30-50% accelerated time to market by increasing test automation productivity
• Over 50% lower total cost of ownership over 5 years compared to scripted automation

Though extraordinary, these claims are documented in success story after success story. Tosca’s model-based approach is significantly different.

No Code

The other part of the “no-code, model based” approach is the “no code” part. Most test automation solutions, while potentially showing a high-level “keyword” interface, are in fact code generators behind the scenes. To do anything complicated means opening up the editor and writing code. Often, complex code.

For those attempting to use solutions like Selenium (see below), there is no GUI option. It is code from the very start. This requires a very specific skillset and can be intimidating to those without a coding background.

In one often referenced slide, 100 manual testers were introduce to Tosca and Selenium. In 3 months, 15% of the testers were able to effectively utilize Selenium. As a testament to the benefits of the no-code approach, in 3?weeks, 85% of the same group were productive with Tosca.

Tosca not only allows your team to be more productive, it allows you to hire (or repurpose) an entirely different hiring profile. Let the people who know how to program develop your applications instead of building tests.

Inherent Modularity

At a recent conference, a Tosca user on a panel was asked “Why do you like Tosca”. They noted that with prior solutions, test automation engineers tended to script end-to-end business processes in a large, monolithic script. This meant that whenever something changed, the entire script would need to be examined and updated. This means maintenance becomes a nightmare. Yes, it could have been better architected. But the never were. There was never time.

But with Tosca, the tests were intrinsically built in a modular manner. There was no other choice. It wasn’t a technique utilized by a senior developer. It wasn’t adopted through best practices training. Modularity (and therefore, reusability) are there in Tosca whether you like it or not.

Conclusion

I hope this helps explain the benefits and value of Tosca’s no-code, model based approach. If the future, expect to see additional discussions of:

• The Evolution of Test Automation – Macro recorders to models
• Selenium pitfalls?– problems inherent in the system

If you have comments, feedback or would like to dispute my case, please feel free to do so in the comments below.