Tosca Interview Questions

An automated testing strategy is the most reliable way to determine whether an application is usable and reliable. Today, Selenium and Tosca are the most popular automation testing tools.  

Selenium vs Tosca -

As shown below, the Tosca Testsuite consists of four main components: 

• Tosca Commander: It is one of the essential parts of this tool for developing, managing, and analyzing test cases. It administers the test cases in the workspace.
• Tosca Executor: Commander is the middleware between the Test Repository and Tosca Executor, which forwards test cases from the Test Repository to the Test Executor. Next, the Tosca test executor executes test cases that have been developed on SUT (System Under Test).
• Tosca XScan (Tosca Wizard): It scans input fields on the screen and saves them as modules for Tosca Commander. Technical information is included in these modules in order to identify and direct screen elements.
• Test Repository/Common Repository: This is where complete workspaces are stored like test objects, test cases, etc. In order for several/user testers to work at the same time, the test repository is necessary.

The following are some advantages of using the Tosca test suite:

• All-in-one tool with multiple features like support for model-based and risk-based testing approaches, automate both UI (User Interface) and non-UI applications, etc.
• Testers can enjoy a script-free experience when testing various applications. There is no need to write scripts and since scripting is not required, people obviously use it more often and more effectively.
• Able to cater to both small-scale and large-scale applications using Agile test methodology.
• Provides support for most common technologies such as SAP (System Applications and Products), Oracle, Java, SOA (Service Oriented Architecture), HTML (Hypertext Markup Language), and so on.
• Available at a reasonable cost, and provide a user-friendly GUI (Graphical user interface)
• As a result of its risk-based and model-based approach to test automation, Tosca simplifies end-to-end regression testing and reduces the time required for it.
• Copy-paste functionality for test cases and modules and the possibility to reuse assets.

The following types of errors can occur during Tosca execution:  

• Verification-Failure: A failure that occurs when expectations and actual results do not match for the verification step.
• User Abort: This occurs when the tester stops the execution.
• Dialog-Failure: Apparently this is the result of some unhandled exceptions or steps. This error occurs when the application attempts to steer either a control that does not exist or is not in operation. Crashing or jamming applications (i.e., not responding) fall under this category too.

An ExecutionList is used to store completed test cases and run them all at once. The following ways can be followed in Tosca for executing ExecutionList:  

• Choose the Run option from Tosca Commander's context menu or press the F6 key under the Execution section.
• Simply right-click on each selected test case and select "Run".
• Use Ctrl + left mouse button to select multiple ExecutionLists and run.

During the creation or enhancement of a TestCase, ScratchBook executes a trial run to check its correctness or to validate if it is still incomplete. Also, you can run only individual TestSteps to perform partial test executions. In light of the fact that the compilation and execution results of TestCases will not be saved, the ScratchBook should only be viewed as a temporary aid when executing TestCase parts while building TestCases. In a ScratchBook, we have the following options for running test cases:  

• Run test cases as soon as they are created
• Organize/arrange TestCases in the desired order, and then execute them.

When building an application, the API layer (Application Programming Interface) is usually built first. The skills needed to build and maintain API tests make API testing a major challenge for organizations. As a result, testing becomes slow and inefficient, hindering the delivery of agile software. 

This technical obstacle is broken down by Tricentis Tosca, which simplifies API testing using a codeless, model-based approach. The Tosca API Scan provides a simple, no-code solution that supports the easy creation, management, and execution of automated API tests. One can easily test the performance and error handling of your API with its rapid end-to-end tests. To put it simply, it lets you design and automate API test cases. 

The TOSCA API testing process is as follows:

• API Services: Determine the API details and functionality for automation.
• API Scan: After scanning the API for a specific system, the API scan feature allows you to create Tosca modules.
• Create Test Case: Create test cases and perform cleanup with parameterization.
• Run: Execute tests and share reports with stack holders.

TDS (Test Data Service) is used in Tosca to manage test data in distributed environments. It enables us to store dynamic test data in a shared location, making it easy for test cases to read/update. Data stored in a shared location can be shared across multiple test cases since it is stored in a shared location. Additionally, it can be updated without opening Tosca, since it's considered a separate component. It enables you to manage your test data in distributed environments. 

String operations can be used in Tosca to verify or modify strings through regular expressions. For instance, it can include counting specific characters and words in a statement, replacing a word with another, or checking the format of a number. To perform String operations, you should download and import the AidPack module into your project. 

Example: 

For instance, we are searching for the character " - ", which should be replaced by the following character " / ". If the operation Global is selected, then "/ " is included wherever " - " occurs. In the following example, the " - ” character in 8-May-2012 is replaced by the " / ”.

In the Settings dialog, the modified string should be stored as BufferStringOperation. In the following figure, modified string i.e., 8/May/2012 is stored in setting dialog buffer.

Tosca's easy-to-use features make it popular with testers in the automotive, metal and mining, financial, and education industries. Tosca has the following important features: 

• Script-less test automation is possible using the drag and drop feature of modules, which simplifies software development.
• Execution is fast and Continuous Testing is available to support DevOps.
• Supports module-based test development where a model of the application under test (AUT) is created instead of scripts. A model can be used to represent the intended behavior of an AUT, as well as the testing strategy and the test environment.
• Supports risk-based testing to suggest the best test cases and calculate the risk contributions of each test case.
• Using it, business users can record their daily activities and then convert them into automated test cases, thereby eliminating the need for manual tests.
• Maintenance effort is minimal.
• Improve test stability and efficiency with a codeless approach to API testing.
• Test faster and more effectively by running multiple tests simultaneously across distributed infrastructures and virtual machines.
• Possible to automate both UI (User Interface) and non-UI applications like XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), mainframe, etc.

As part of the TestCase-Design process, TestSheets are used as the main framework. The purpose of TestSheets is to organize/manage test data to follow a logical testing process. A test sheet should cover each requirement of the application. Below are the steps for creating a TestSheet: 

• Step 1: To begin with, right-click on the folder where you'd like to create a TestSheet.
• Step 2: From the mini toolbar, select Create TestSheet.
• Step 3: Specify the name of your TestSheet.

TestCases may sometimes need access to the name of a TestCase / Instance, such as when storing data in TestDataService, and this can be acquired with {XL[Instance.Name]} or {XL[Instance]}. You must work with a TestCase template and a TestSheet to gain access to the name of a TestCase / Instance. When you want to mention the name of the TestCase in the TestCase template, use XL-reference [XL[Instance.Name]] or [XL[Instance]]. 

The Tosca Webservice Engine 3.0 utilizes web protocols like HTTP (Hypertext Transfer Protocol) to manage/control web services. It is also possible to manage/control web services using REST (Representational State Transfer) and SOAP (Simple Object Access Protocol). The Tosca Webservice Engine 3.0 is installed automatically during the standard installation of Tosca. In the System Requirements, you can find an overview of the prerequisites for using Tosca Webservice Engine 3.0. The following Standard subset XModules must be imported in order to be able to work with Webservice Engine 3.0:

• TBox XEngines->Parameter Data
• TBox XEngines->API

API Scan by Tosca provides developers with a no-code solution that will make it easy to create, manage, and execute automated API tests. Test cases can be created for API testing and scenarios can be created for Tosca Orchestrated Service Virtualization with API Scan. In simple words, automating and designing API test cases are possible via API Scan. You can accomplish the following tasks with API Scan:

• Develop test cases and modules.
• Sync with the API Connection Manager
• Ensure seamless integration of API and Tosca Orchestrated Service Virtualization (OSV).

The TC-Shell is the command-line controller of Tosca Commander, providing access to most of Tosca Commander's functionality. It has two different modes of execution: interactive and scripted.  

• In interactive mode, the user is offered assistance and options and can access all of the functions of Tosca Commander's GUI (Graphical User Interface).
• In script mode, Shell runs commands from a script data file, so we must write a series of commands on a script data file and then run them. Users cannot intervene in this process. This mode is used for automating processes, for example, for working with an extensive portfolio of tests without supervision.

As its name implies, Test Data Management involves managing test data necessary for the execution of TestCases. In addition to viewing all records within your test data repository, it allows you to modify and/or delete selected ones. During Tricentis Tosca Server setup, it is automatically installed as part of the Test Data Service component. It combines Test Data Service (TDS) and test data management to allow teams to design, locate, manage, and provide test data, even in complex and hard-to-manage scenarios. 

To configure your tests, you can set configuration values through test configuration parameters. The test configuration parameters give you the ability to set parameters for Tosca objects. You can simplify the maintenance of your tests and reduce repetitive tasks by setting specific values to test configuration parameters. For example:  

• Versions of test objects, such as release numbers.
• Various test environment identifiers, for instance Windows 7.
• Connection identifiers, such as URLs and parameters.
• Identifiers of business process chains.

Test configuration parameters can be created for the following Tricentis Tosca objects:

• Project root element
• ExecutionList
• Component folder
• ExecutionEntry folder
• Configuration's folder
• ExecutionEntry
• TestCase folder
• Scratchbook
• TestCase
• TestCase-Design folder
• ExecutionList folder

In Tosca, templates are structured/conventional formats that can be reused to create concrete TestCases. It is possible to convert test cases that have very similar steps into templates so that they can be used for a variety of data combinations. Data from test datasheets are used in the template. When you instantiate a template, you convert a single test case template into several test cases using the test data that you supply as input to the template.

Tricentis Tosca's integration with Application Lifecycle Management (ALM) tools enables development and QA (Quality Assurance) teams to better collaborate and meet customer expectations. This integration serves as a means of managing test executions and defect management. In general, ALM is a test management tool used to manage the testing process, including test development, executing them, and tracking defects. ALM allows developers to monitor quality parameters and test results at any time, and the QA (Quality Assurance) team will have real-time insight into all development phases. 

The above shows Tosca integration with ALM tool. Thus, Tricentis Tosca will sync all requirements from the ALM tools, and all defects reported by the QA team will appear in the ALM tool.

In Tosca, we are not able to trigger multiple browsers at once, but we can perform cross-browser execution. In order to automate TestCases with applications that have to run on different browsers, buffers can be used. The test configuration parameter can be changed at runtime using buffers, and the browser to be used can be specified using the TBox Set Buffer. The following steps need to be followed in order to perform cross-browser execution:   

• Design a Test Configuration Parameter “Browser”.
• Using the buffer, change the value of the Test Configuration Parameter to [B[Browser]].
• Specify which browser should be used using the TBOX Set Buffer. Users have the option of selecting Internet Explorer, Firefox, Chrome, etc.
• Executions will be triggered by individual browsers.

In Tosca, objects can be identified in four different ways as listed below: 

• Identify by properties: By default, Tosca XScan identifies objects by their properties. All technical information and the properties of an object can be found in the Identify by Properties window.
• Identify by Anchor: The technical properties of objects can be used in Tricentis Tosca to identify other objects.
• Identify by image: Tosca can identify objects by capturing a screenshot of the object.
• Identify by index: In this case, the object is identified by its index. If an object selected does not have a unique ID, you can specify an index to be used to identify the object at test execution.

The Tosca Query Language (TQL) is a powerful way to search within your project. The tool gives you the ability to perform search queries on your project through objects, object relations, and object properties to find/search anything you need. Simply type your query into a language the computer understands and the system will do the rest. It gives you the ability to take control of a project at any time. In its most basic form, this is similar to SQL, which enables us to search based on conditions. 

Example: Suppose the diagram below represents our current situation, in which we want to search for all TestCases with the name Data Source Excel in the TestCases folder.

Solution:

=>SUBPARTS:TestCase[Name=="Data Source Excel"]

TC PDF Compare is the standard module offered by Tosca for comparing PDF files. This TC PDF Compare feature from Tosca Exchange Portal allows the comparison of two PDF files. After the test is executed, any differences found appear in the ExecutionLog. 

In Tosca Rescan, the module that has already been scanned is scanned again. Assume you have already scanned the page, but there have been a few changes and two new fields have been added which you need to include in your test case. For the two fields to appear in your scanned modules and your test case, you need to rescan your module. 

Tosca's synchronization functionality allows automated test cases to be executed in accordance with the application speed using processes and events. Synchronization is when the automation tool speed synchronizes with the application speed. You can achieve sync in Tosca using ActionMode WaitOn. Synchronization settings can be modified via the settings - "Go to settings->TBox->synchronization". 

As its name implies, recovery scenarios are used to recover from the failure of a testcase/teststep. During test execution, if for some reason your test case fails (this could be any reason), the Recovery scenario ensures that the next test case after that failed test case will proceed normally. This will ensure that the following test case runs correctly, without any impact from the previous test case. There are two conditions in which recovery is possible i.e., dialog failure and verification failure. When a recovery scenario fails, Tosca then tries the next higher level recovery scenario, and if all recovery scenarios fail, it reports the test case as failed.   

With Tosca CI (Continuous Integration), test cases can be executed directly from the build server without the user having to perform/run them themselves (manually). Examples of CI tools include Jenkins, Bamboo, etc. It is used to minimize testing time and effort for Continuous Integration & Delivery. The following ways can be used to implement Tosca CI:  

• Use a remote service to run the test execution, i.e., on a separate workspace.
• Use Tosca Continuous Integration along with Tosca Distributed Execution. Your tests will be executed by several Distribution Agents, thereby speeding up the process.

There are two ways to fetch test data from Excel as follows:  

• In order to test a TestCase scenario on multiple datasets, Tosca provides a TemplateInstance feature. We can create as many test cases as necessary from a data set by using it. We can then import the data from Excel and embed it into the Test Case steps.
• For different TestCases and to import data from external sources, the Excel Engine module can be used.

Tosca BI (Business Intelligence) modules can be used to create a TestCase template manually. In order to create and utilize your own TestCase templates, perform the following steps:  

• Step 1: Build a TestCase that meets your needs.
• Step 2: Right-click on the TestCase and choose "Convert to Template" from the context menu to convert it to a Template.
• Step 3: Drag and drop the appropriate TestSheet onto your TestCase Template.

When you instantiate a template, you convert a single testcase template into several test cases using the test data that you supply as input to the template. You must follow the steps below to instantiate TestCases in Excel: 

• The TestCase that is needed to be instantiated must be viewed as a template.
• Parameters (values to be transferred from a template) must be linked to template attributes by specified syntax.
• To create a TemplateInstance, right-click on the TestCase template and select Create TemplateInstance from the context menu.
• You must specify the Excel file with the corresponding spreadsheet in the subsequent dialog box.
• Click the OK button to confirm your inputs.
• Once you click Yes in the subsequent dialog, the instantiation process will begin.

In this way, Tosca creates a TestCase in the TemplateInstance for every TestCase defined in the template. The structure of the TestCase is the same as that of the corresponding TestCase in the template. 

In order to integrate Tosca Connect with HP ALM, follow these steps: 

• Download and install ALM Rest API.
• Install Tasktop on a test system using a license key.
• Synchronize testcases from Tosca to HP ALM's Test Plan Module.
• Sync Tosca execution lists with HP ALM's test lab modules.
• Sync Tosca execution entry and latest test results with HP ALM's Test Lab/Test Run modules.

Tosca allows us to verify a file's existence in any directory by using the TBox File Existence. It includes the following attributes:  

• Directory: Location of the file to be verified.
• File: Name of the file that needs to be verified.

Conclusion 

Tricentis Tosca is one of the best automation testing tools currently available on the market, which simplifies the work of software testers. Tosca automation tool automates software testing and makes it easier to find and fix bugs efficiently. Since then, it has developed into one of the biggest players in the automation field. So, securing a job as a Tosca specialist/expert is sure to guarantee you a successful career. Here is your chance if you are looking for Tosca Interview Questions and Answers for Freshers and Experienced.

Useful Resources:

• Automation Testing
• Manual Testing
• Automation Testing Tools
• Manual Testing Tools

Model-based testing and risk-based testing are two of the most commonly used technologies in Tricentis Tosca. 

• Model-based testing: Tricentis Tosca uses model-based testing instead of scripting for automation testing. This involves creating a model of the AUI (Application Under Test). A model (the lego blocks can be combined and reused across your tests)  can be used to represent the intended behaviour of an AUT, as well as the testing strategy and the test environment.   It is a simple and codeless approach that is easy for anyone to understand and use.  Whenever a change is made to an application (e.g., adding or removing a field), you need only update the module once. These changes will be synchronized across all of the impacted test cases, saving you time and effort. 
• Risk-based testing: In the blink of an eye, defect-filled product releases can disrupt your business processes and damage your brand and customer trust. The problem is, traditional test approaches don't measure business risk as much as they focus on checking the total number of test cases run. The problem can be solved with Toca's risk-based test optimization, which maximizes the risk coverage while minimizing effort. Using this approach, you can reduce the number of tests you don't need by 40%, while increasing your application's risk coverage by 90% or more. In addition, you are able to identify which business-critical functions were successful or failed, enabling you to make faster and better decisions throughout the release cycle. 
  As you can see in the below diagram, traditional testing approaches only cover 20% of risks and focus on the overall number of test cases run. In contrast, with risk-based testing, the goal is to maximize risk coverage and minimize testing and therefore risk coverage is 80%. 

The reusable TestStepBlock usually consists of TestSteps that can be reused in a number of TestCases, meaning you don't have to rewrite as much code. In Reusable TestStepBlocks, business parameters display an overview of crucial business information. Business parameters can be used to set or pass dynamic values in test step blocks. You can create it simply by right-clicking on Reusable TestStep Block and choosing business parameters from the context menu. Business parameters can also be manually defined within the module in the following ways:  

• XML elements and attributes in the Payload tab.
• JSON data in the Payload tab.
• Headers in the Headers list.
• Parameters in the Params tab.
• Transport information in requests.
• Response time and Status code and in responses.