About Tricentis Tosca: Architecture, Components and Extension
August 13, 2018
About Tricentis Tosca: Architecture, Components and Extensions
Welcome to this post!- “About Tricentis Tosca: Architecture, Components and Extension”- This post discusses some facts about the product, its architecture and components that are useful in planning the test, laying down the strategy and execution. Plus, evaluating the results and do appropriate plan changes.Usually these are assumed to be known before moving to deeper concepts of Tosca components. So Go ahead and enjoy reading…
We will start with very basic questions on the product and later deep dive into the architecture and its components on both client and server side.
What is Tricentis Tosa
Tricentis Tosca is a testing software developed by Tricentis, which is Headquartered in Vienna, Austria.This tool allows users to create automated and functional test cases around the system under test (SUT).
So, you would say “What’s new in that, there are tons of commercial and open source tool which do the same?” Well! believe me, this one is different in many ways:
- It follows model-based automation, (if you don’t understand it’s importance, no worries I will discuss later)
- It reduces your coding to minimum, (this allows you to focus more on scalable and flexible test framework)
- It has various clear and crisp sections so that it can supports you well enough in proper Test Management like check-in/check-out, distribution of modules, testcases etc,
- It can be integrated to a number of tools which are used in CI/CD activities like Jenkins, etc.
- It allows you to recognize and do action on previously unidentified controls using your own written custom control’s modules.
- It supports a lot of applications; doesn’t matter windows, web apps, CRM apps, etc. It allows also BI testing solutions, Analytics solutions with their additional extensions,
and so on…
This is something in short to give you a good brief about the product and its capabilities in terms of application interaction and test management.
Now let’s go through the major components that available as part of Tosca:
- Tosca Commander
- Tosca Executor
- Tosca XScan (Tosca Wizard)
- Test Repository
Okay I’ll discuss in order of appearance:
First of all, you always create a project in Tosca Commander. This project gets saved as a workspace similar to IDE’s like Eclipse or VSTS etc. This workspace contains all information regarding your settings, test objects information, etc. The workspace has two options for saving your progress and retrieval of same.
First is that you don’t save workspace in common repository, instead you save workspace inside a local folder and keep on using same.
Second, you select a common repository from options of database, and select that as your preferred common repository. For example, suppose you have selected MS SQL and create project post selection. Later all your workspace progress gets saved on that database. Now next time when you open the same project in the Commander you will see that it will show all updates that have happened or gives you flexibility of looking at revision history for a test object.
So, whatever you do with test objects, all gets stored in your repository. And just a word on comparison, both (local and common repository) have their own pros and cons.
Let’s move on to our main IDE-Tosca Commander. If you worked in VSTS or Eclipse you know very well what exactly IDE is, similarly in Tosca there is Tosca Commander. This enables users to create the following:
- Modules,
- TestSheet,
- TestCases,
- Requirements,
- ExecutionLists,
- Bugs,
- Analysisreports
- Exploratory testing tasks, etc…
The list grows depending on the Add-in’s which have been incorporated with IDE. Just imagine or try visualizing here as you are installing some plugin or addon in your Eclipse, VSTS or say a Browser. The point to be noted here is each Add-in requires license. Some of them are part of standard installation and some of them requires you to purchase. That shouldn’t be shocking, its commercial tool right!
So, for each new Add-in (say) you want to go with BI then you need to purchase that. Get all the files required to install on server side and Voila!!!. If you are new to all this you can always rely on their support team. Believe me they are pretty fast in attending their customer requests and providing solutions.
Well I can keep on discussing about commander, let’s stop here and focus on other parts. We will discuss each part of commander in other sections.
Let’s move on to Tosca XScan – this scans the SUT, their input fields (using their technical information to identify later) and saves the information as modules in Tosca Commander.
And finally comes your Test Executor – as the names suggests it executes the test cases being forwarded by the Commander.
Fig: Shows concept of Tosca
So now just wrap-up what we have discussed in an informative manner or should say like an automation tester:
- Initially, we get requirements (functional requirements, technical requirements, usability, etc.). We can mark requirements in Commander in respective section.
- Based on requirements, the TestCase-design phase starts by creating the TestSheet indicating all the scenarios and their respective possible data combinations. This can be done in TestCase-Design section in commander.
- Based on TestCase-Design, you create intended modules to cover up the complete scenarios discussed. These can be done in Modules section of commander.
- Then, we move on to the creation of actual test cases from modules. Once done we can create multiple combinations of single test case based on different applicable data combinations. This can be done in TestCase section.
- Finally, we create execution lists for our intended test cases in the ExecutionLists section, which serves to run the tests and evaluate the test results.
- These test results are then projected back onto Requirements in order to show the coverage from test point of view.
Now let’s start focusing on some of the components or features exists in Tosca Architecture:
Fig: Tosca Architecture
Okay, the above image says a lot if you see, right! There is a lot going on. There are two sides of it — Server Side and Client Side. At Client Side: This shows connections between Tosca Commander(TC) and Tosca Executor(TE), TC and Tosca Wizard(TW), TC and Repository, TC and License Server, and lastly Settings which is common. Through Commander you create a complete set of concrete Test Cases with the help of different Add-in’s and modules. Plus, you create the modules with the help of Tosca Wizard, which then gets saved in commander. And later you use them for creation of test cases. Your complete workspace is saved in repository i.e. all your test objects, etc.
When its time to execute, TC passes them to TE for execution and report back the results. Since TE know which engine needs to be interacted with TestObject, a separate layer we can say acts between these i.e. TE and Test Object. This layer helps in identifying objects and performing actions on same. The “Settings” which you have set up is important as it exists globally, as well as locally, so always take care of it.
And the License Manager exists for each user. Similarly, at Server Side we have repository, License Server, extensions management, API, Exploratory etc. Usually we don’t need to know a lot about whats happening at server side, as being an automation tester, some knowledge is fair enough, unless you want to take an administrator role on server side.
If you see the table below, it will give you an idea about various components and features which are available or support on client, server, databases and Cloud.
For example, the License Server feature can be deployed at customer’s server and will be used to validate the user’s licenses used globally in the organization using License Manager. This License Manager can interact with Cloud for retrieving user license or fetch local one and validate same depending on situation.
Features/Components | Client |
Server |
Database |
Cloud |
License Server | Yes | Yes |
Secondly, till now you must have guessed the main core components, which are also shown below:
Features/Components | Client |
Server |
Database |
Cloud |
Tosca Commander | Yes | Yes | Yes | |
Tosca Server | Yes | Yes |
We have already discussed in brief about commander let’s discuss Tosca Server. Tosca Server manages all operations in connection administration, Monitoring, Exploratory tasks, REST API’s, and also various extensions which you have purchased. On the Tricentis Tosca Server website, you can navigate to the following web features:
- Tosca Administration Console
- Tosca Analytics
- Tosca Event Monitor
- Exploratory Testing Server
- Tosca License Administration …. and so on.
Of course, you can manage the user permission, create modify tasks, set up licenses etc. The list goes on.
Similarly, we have extensions which are part of Server side as shown below:
Features/Components | Client |
Server |
Database |
Cloud |
Tosca Analytics | Yes | Yes | Yes | |
Tosca BI | Yes | Yes | ||
Tosca Connect | Yes | Yes | ||
Tosca Continuous Integration Tosca Distributed Execution |
Yes | Yes | ||
And list goes on…. |
Once these extensions are installed and set up at server side, you can start working with them using Tosca Commander. You can build modules, test cases etc in the same way as you do for web apps, desktop apps, etc.
Now we enter inside the Tosca Commander, below discussed components or features are part of Tosca Commander:
Features/Components | Client |
Server |
Database |
Cloud |
Requirements Management | Yes | Yes | ||
Test Case Design | ||||
Tosca Test Planning | ||||
Reporting | ||||
Tosca Test Data Management | Yes | |||
And list goes on…. |
Depending on your license you can see some or all of them in your Commander
If you would like to keep track of further articles on Tosca, I recommend you to SUBSCRIBE by Email and have new Tosca articles sent directly to your inbox.
Great ..very informative.