Wednesday, October 23, 2013

TOSCA - Website Automation



One of the best tools that I found for Website Automation is TOSCA from Tricentis. I have been using this tool since past one year but for web services and for Manual test cases. I recently got a chance to automate website for one of the projects that I was working with.

The beauty of TOSCA is it requires 0% coding which is a bless for tester with no coding knowledge but interested in Automation. I was working in Automation testing for the past 6 years and this is the only tool that I came across which requires no coding knowledge.

Also most of the record and playback tools that I tried so far records the application pages pixel based. The difference that I found in TOSCA is it scans all the elements in the page and creates a module that can be used in test cases.

The two options for creating a module in TOSCA for HTML engine are:

Scan all: Scans all the elements in the page and displays
Scan Region: Scans elements for the selected region

A module is created by scanning the elements in TOSCA. Using the created module we create Test cases. For every execution of these test cases we create an execution list. Along with Modules, Test cases and Execution lists we have another section where we can manage our Requirements. Another key feature that I found in TOSCA is mapping of test cases and Execution lists with the requirements. Test cases are mapped to the Requirements to get a traceability matrix and Execution lists are mapped with the Requirement sets to the execution coverage.


TOSCA also comes with few common modules which can be directly used in our test cases.

Process Operations:

For website automation the first step in every test case would be “Open URL”. Under process operations in Common module we have “Start Program” & “Start URL” which can be used in test cases. The value for the start url would be the URL of website under test.

Buffers : 

As Open URL will be the common step for every test case, instead of passing Website url value in each test case we can create a buffer with the buffer value set to the URL and call the buffer in all the test cases. It is not only the URL but any common values that we come across in multiple test cases can be declared under buffers. We can create a single buffer or a multi buffer. For creating Buffers we can use either Set buffer or Multi buffer modules under common modules.

Basic Windows Operations:

Another common test step that we use while automating the website is “Close Window”. In Windows OS this can be done using the keyboard commands ALT + F4 for Window close or CTRL+F4 for closing a Tab in a window. In TOSCA we have basic windows operations support. One of the common module under basic windows operations is “TC Window Operation”. The inputs for this module would be Caption & Keys. Support of Wild characters is added advantage in TOSCA.

Eg: Caption: *Windows Internet Explorer*
Keys:  ^{F4} ( for CTRL + F4)
            %{F4} (for ALT + F4)

Timing modules:

In automation of a website we might need to declare a wait time in few instances. In this case, we have a common module TC Wait. The input for this is the wait time in msecs.

Reporting is also very easy in TOSCA. We can generate a Test Case Report and also a Test Execution Report (Summary /Detailed views) just with few clicks. It saves lot of time too..

I really enjoyed automating website with TOSCA... Hope you enjoy to...

Happy Testing!!







5 comments:

  1. Great work Priyanka … you have explained the over view of website testing in a very easy and functional manner in your blog.

    ReplyDelete
  2. Nicely written and explained...Good work!

    ReplyDelete
  3. After learning and implementing TOSCA for a premium Media & Entertainment client, following are my findings:
    Pros:-
     Easy to learn due to drag-and-drop functionality availability for creating automated tests and use of plain English (no coding/scripting)
     Good visual representation, easy to understand and comfortable to implement simple to medium business scenarios
     Linear/orthogonal Q(Test Case Design) for facilitating multiple test data combinations is new and if used correctly can provide good results
     Frequency / Damage classes used in weighting requirements is new and helps in computing the real requirement coverage
    Cons:-
     Frequent need of customization(which has extra cost associated) to implement complex scenarios in application
     Less control on test scripts since control level scripting not feasible
     Lack of basic conditional (If, Else) & Looping( For, while) statements poses limitations on robustness of our tests
     Limited support and documentation available, which creates heavy dependency on Tricentis support.

    ReplyDelete