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!!
Great work Priyanka … you have explained the over view of website testing in a very easy and functional manner in your blog.
ReplyDeleteThank you Sal.
DeleteNicely written and explained...Good work!
ReplyDeleteThank you.
DeleteAfter learning and implementing TOSCA for a premium Media & Entertainment client, following are my findings:
ReplyDeletePros:-
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.