Understanding TOSCA's Testing Methodology!!

Hie!!!

Welcome again.

All written below is based solely on my own observations and your expert advise is always welcomed. Please feel free to contact me at sharma.kapil46@gmail.com or you can leave comments at any time for any suggestions, modifications and rectifications that you think are required in any of the published posts as it can prove fruitful to all the visitors who visit this portal. 

This is the post where I would just be talking about Tosca from the perspective of project scenarios where it is actually used to do something productive and reduce testing efforts.

Tosca 8.4 SP1 is now available and the below written would be in context to this version of Tosca only.

In ideal scenarios, as per Tricentis, Tosca can be used as complete Test Management Tool, which is 100% true, but what we follow in projects does not comply with this statement.

When it comes to real-time scenarios, there are some restrictions not because of the tool but because of the development and testing culture that we follow.

Note: Here in this post, I would be using some technical terms, which you might not be aware of, if you are new to Tosca. If this is the case with you, then you can first of all switch to the section of Understanding Tosca as a Tool! for better understanding of terms.

So, lets start talking Tosca again.

The below diagram is an effort to show what Tosca is capable of providing features for overall project development.

What the above diagram means (When projects are developed from scratch):

• Developers independently track their development phases by using tools like Rally.
• Depending on the development phases and requirements from client, Testing Teams create requirements and Test Cases using Tosca.
• In order to provide synchronization between Development and Testing teams, Tricentis has integrated Tosca with Tasktop (Sync).
• This integration provides run-time reflection of changes made either by developer or tester in their respective frameworks (Rally/Tosca)
• For example, if under requirements section of Rally, Developer creates new requirement, then it will automatically be getting reflected under requirement section of Tosca after taking "Update"
• Contrary to that if the tester if setting the result of Test Cases in Execution List as Pass/Fail/No Result, then the same status would be getting reflected in Rally to the developers in their requirement tracking screen.
• This type of integration helps to keep developers and testers on same page even if they are not in direct contact with each other (when development and testing are with different companies).

Also, keep in mind that Tricentis strictly recommends the use of TCD (Test Case Design) for creating manual test cases out of requirements, so that proper tracking and mapping of test cases, test case results and requirements can be done.

To understand this more clearly, I am providing another diagram which depicts how in ideal scenarios project development is supposed to be done.

Explanation: If client is selecting Rally as tool for developers to monitor their project development and Tosca for complete Test Management, then initially Requirements are gathered from client in the form of BRDs (Business Requirement Documents). Based on BRDs, developers create requirements and the same is followed by Testers. In order to sync Rally with Tosca you need to configure Tasktop (Sync).

Once the configuration is done, you are good to see the amazing synchronization between both the tools (this becomes very critical when Development and Testing tasks are allocated to different companies). Any changes made in Rally pertaining to requirements would be reflected in Tosca in real-time basis and vice-versa.

Note: By now, you might be very curious in knowing that how Tasktop (Sync) can be used and I really appreciate your curiosity, but I will discuss about all this in later posts or you can directly jump to the section of Tasktop (Sync) from Tosca Tasktop (Sync) Integration.

By reading all the above, you might have formulating a picture in your mind that it is really easy to keep developers and testers on same page, but the real-time scenario is different. Most of the times project requirements are not clear to developers during initial phases of project development and moreover concrete test planning is also not done, so the concept of using Tasktop (Sync) becomes out of scope.

I am describing the approach which our team is following while using Tosca for Testing.

• Requirements were designed roughly based on the BRDs shared by the client.
• In order to cover the requirements, test cases were designed by using manual approach (not by TCD).
• Initially, all the test cases were executed using manual execution and coverage was mapped.
• Later on, with regression cycles, automation was introduced and percentage was defined for automation and manual execution and coverage was mapped.
• Since everything was done manually, whenever there are new requirements given by client, we have to manually create requirements and test cases, which seems quite a overhead now. Also, it has become difficult to organize all project related structures.
• There is no synchronization between developers and testers apart from when the issues are raised.

Right Approach: What the right approach would have been -> Use of Tasktop (Sync) and TCD, use of well-defined Automation Scope.

Tosca's Defining and Operational World: Tricentis has created Tosca in such a wonderful way that you can keep your Test Screen Information (like IDs and class of elements), Test Data, and Test Step Sequence separately so that it is easily manageable.

The applications which are tested are most of the times nothing but a series of screens and flows which can be controlled by capturing the screen information -> providing data required for those screens -> arranging the screens in a series of test steps -> finally executing them through automation.

Tosca saves the screen information in the form of "Modules" and Test Step Sequences in the form of "Test Cases." For test data, there are a number of approaches which people follow like saving and calling data from Buffers, directly inserting data in Test Step Values, and fetching data from excels.

Per Tricentis, the screens and input field elements, of any test automation candidate application are scanned through Tosca and are saved in Tosca Commander via XML interface as Modules and they define the Defining World of that application.

When the Modules are arranged in some meaningful order/sequence and required values are provided as input so as to describe a flow of steps, then these become Test Cases and Tricentis has named it as Operational World.

The Operation World is then transferred to the Execution World from Tosca Commander via XML interface in order to execute the Test Cases.

In floating license installation types, all Modules, Test Cases, Execution Lists are stored centrally and can be used by anyone having rights to access the server. This provides complete visibility of the work done by all the teams at a single platform. Checkouts are required in order to make changes to any entity and to make it visible to all Checkin process is followed.

So, all this was about testing methodology from Tosca's perspective. Let us now move on to next post where I am going to discuss about Tosca as a tool, its layout, how it is used etc.