Explore topic-wise InterviewSolutions in .

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.

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 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

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]]. 

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.

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 -

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.

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. 

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.

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.

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.

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.

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.

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.

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.