? QA Design Gurus: Telerik Test Studio
Showing posts with label Telerik Test Studio. Show all posts
Showing posts with label Telerik Test Studio. Show all posts

Aug 11, 2016

Building a Robust Test Automation Scripts Using Telerik Test Studio/Test Framework- Best Practice



In today’s web world, where elements/controls in the web application changing on daily basis, it is very hard to change corresponding automation scripts to make it run on changed web application. Hence, developing robust automation scripts should always be the first priority. One key step towards robustness in Telerik Test Studio automation script is, be cautious while using any method or property in the scripts. Just think, in which class method/property defined? and are we using same class object to call that method/properly? I hope, answer for those questions gives better idea on what you are doing and what you need to do.

I would always suggest not to use narrowed wrapper class until it really require. Let’s take few common scenarios.


Scenario1:  Verifying inner text of an element. 
 Assume, Element in the DOM:
<span id="dash_heading"> Dashboard page of eval user </span> 
One way to get the inner text is (Script_1):
HtmlSpan Dash_Heading = ActiveBrowser.Find.ById<HtmlSpan>("dash_heading");
string Text = Dash_Heading.InnerText;
Another way is (Script_2):
HtmlContainerControl Dash_Heading1 = ActiveBrowser.Find.ById<HtmlContainerControl>("dash_heading");
string Text1 = Dash_Heading1.InnerText;
Both are the correct and gives inner text of “dash_heading” element. Here Script_1 fails if developer changes element type from span to div but not Script_2. Reason behind is “HtmlContainerControl” is base class for both “HtmlDiv” and “HtmlSpan” classes and property “InnerText” is defined in “HtmlContainerControl” not in “HtmlDiv” or “HtmlSpan” classes. So if your requirement is to get innerText go with Script_2 not with Script_1 to make your script robust.
Scenario2: Verifying whether button is disabled or not?
Assume, Element in the DOM:
<button id="btn">Submit </ button > 
One way to verify is (Script_3):
HtmlButton Button_Ele = ActiveBrowser.Find.ById<HtmlButton>("btn");
Assert.isTrue(Button_Ele. IsEnabled);
Another way is (Script_4):
HtmlControl Button_Ele = ActiveBrowser.Find.ById<HtmlControl>("btn");
Assert.IsTrue(Button_Ele.IsEnabled);
Above both (Script_3&4) are the correct to assert whether button is disabled or not. Here in Script_3 we are using derived wrapper class to get the IsEnabled property value where as in Script_4 we are using base wrapper class in which IsEnabled property defined. Hence, Script_3 fails if developer changes element type from “HtmlButton” to any of “HtmlInputButton” or “HtmlInputSubmit” but not Script_4.So if your requirement is to check whether button enabled or disabled, I suggest to go with Script_4 not with Script_3.

Scenario3: Click on Element/Control.
Assume, Element in the DOM:
<button id="ele1">OK</ button > 
One way to click on the element is (Script_5):
HtmlButton OK_Ele = ActiveBrowser.Find.ById<HtmlButton>("ele1");
OK_Ele.Click();
Another way is (Script_6):
HtmlControl OK_Ele = ActiveBrowser.Find.ById<HtmlControl>("ele1");
OK_Ele.Click();
Both scripts click on ele1 element but script_6 will pass even though element type changes from button to div/submit/Image etc.in future but not Script_5. The reason is, Click() is the method defined in HtmlControl class and this class is base class for entire HTML wrapper classes. It will be good to use Script_6 instead of script_5 to make your code robust.
Click Here to read more about HTML Control Element Wrappers Suite.
 

May 12, 2016

Load Testing using Telerik Test Studio

How many concurrent users can the web site handle?

What response time your users will experience?
How frequently users will see errors and need to reconnect?

To address these concerns, Load testing on an application is performed.

The Load Testing in Telerik Test studio is a standalone feature, which enables the QA Engineer to assess how the web application meets the business needs for availability and User satisfaction.
This article provides brief information on how to setup the requirements for the Load Testing in the Telerik Test Studio.

Prerequisites to use Test Studio as a Load testing tool:


·         The Execution Server must be running before Test Studio connects it for monitoring.

How to run the Execution Server?

  • Click  on  …\Start Menu\Programs\Telerik\Test Studio Runtime 2016.1\Start Execution Server
  •  In the Windows task bar, right click on the Test Studio icon and click on Show

Show

  •  The Test Studio Runner dialog appears. The address for the Scheduling Server that the Execution Server is connected to appears under Scheduling Connection. 


    Now, the Setup is ready for using the Test Studio as a Load Testing Tool

   Designing your Load Test: 

    There are 5 steps to create and completely define a Load Test
1.       Open any existing Test Studio Project
2.        Click on Record -> Load Test.
3.       Click on the Capture User Profile button
                             

4.       The test script is executed once the browser is selected.
5.       The next step is to configure the various parameters like Workload, no. of Virtual Users

   

         Once the configurations are ready, Click on the Run button. Click on “Run this test”.
         After the completion of the execution, the results are displayed on the “Analyze” menu


  

May 10, 2016

Eleven Web UI automation best practices for better results

A few best practices for Web UI automation:

1)Having better Setup and Cleanup code

                Make use of better and stable Setup and cleanup that executes before and after the test execution respectively. This helps to avoid most of the dependency issues and provide robustness to your tests. As a example making use of REST or SOAP services to as setup and cleanup code will ensure the stability of the tests.

2)Identifying an element with stable property

                With the adoption of agile methodology and Cloud based applications most of the Web UI changes frequently to attract customers. This results in failure of Automated tests. To overcome the issue, Identify the element in the UI with more stable property. Using Dynamic ids are tag index will result in instability of the tests.

3)Making use of Reusable components

                Consider making the reusable steps as Utilities or functions, which results in faster development and maintenance of tests. Making the fix failure in the function results everywhere it is being used. Initial days of Automating a UI may not have utilities or it is difficult to decide whether to make set of actions as utility or not. Moving to further development utilities grows in incrementally and adds value to the development. Reusable components should be thoroughly tested since it will be used by multiple tests.

4)Better usage of Wait Statement

                Identifying an element may fail since the finding logic may have executed before the entire UI is loaded. So Simply using Wait statement may not be wise idea. Better to wait for a particular element in the UI rather than standard Wait statement. This ensures that following steps will be executed only after the UI is loaded.

5)Improving the readability of Tests

   Readability can be improved in many ways, below are listed few:

·         Keep the tests simple and short.
·         Name the test case such that it will reflect the purpose.
·         Provide better and meaning full names for the Elements in Element Repository.
·         Identify Element in UI with minimum set of properties.
·         Provide better name to step.

6)Consider different ways of identifying an element

                Conventional way of identifying an element using Element property directly may not work or there may be multiple elements with same property in such cases, trying the alternate ways may lead to better results below are few:

·         XPath: This can be used to find the relative location of an element if the element is not unique.

·         JQuery : We can perform complex browser actions using JQuery where conventional methods may not work.

·         Parent–child: Sometimes child element may not be unique, considering parent tag and navigating to child may result in uniqueness and stability.

7)Maintain Element Repository Globally

Make sure that Elements in the element repository is unique and reuse where ever required this makes easy maintenance and fixing of the test. Fixing a single element will be reflected in all the places it has been used. Though this have negative impact such as duplicate entries of elements, searching an element this can be overcome by following some conventions for the Elements.

8)Make use of services in UI Automation where UI Automation is not mandatory

Can make use of services like REST or SOAP which can perform some action that is not mandatory to test using Automation tool. This makes tests shorter and increase reliability, since the services are more stable than UI.

9)Scenario based testing over functionality based testing

Develop the test based on the scenarios that will cover the multiple functionality of the elements. Unit tests will ensure that basic unit part of the code is working fine hence focusing more on the scenarios that covers multiple functionalities will result in wider coverage of tests.  

10)Generating Custom Report for better debugging

Make use of Report generated by the tools if found that is difficult to debug. Develop the Custom report such that it will ease the debugging time.

11) Keep tests to a reasonable length


As a fact that long tests takes more debugging time considering shorter ones. It is better to keep the tests short and simple.


Feb 8, 2016

TTS Tips: Explicitly adding element to element repository and understanding it's auto generated meta data



There are mainly two ways to add element to element repository:
1. By recording test step (See my post about this here)
2. By adding element explicitly to element repository

There are two ways to explicitly add element to element repository:
A. From the browser
B. From the recorder

A. From the browser:

To do this, first we have to select "Highlight Element" in the recorder. Once it is done, we should able to highlight the elements in the browser.

Do following steps to add element to element repository,
a. Go to required element and mouse over it then you should able to see list of options.
b. Select Add to Elements, then friendly name pop-up will be populated.
c. Enter friendly name and click on Add Element.


B. From the recorder:



Do following steps to add element to element repository,


a. Go to recorder and search for required element in the DOM.

b. Right click on the DOM and select "Add to Element Repository", then friendly name pop-up will be populated

c. Enter friendly name and click on Add Element.




We can use this added elements to crate record test step(regular test step). As recorded test step is created from element repository element, the element will not be deleted when we delete recorded test step. By adding element explicitly, if any coded step interacted with this element doesn't causes test case failure. These type of elements should explicitly delete by us from element repository. In the auto generated meta data file (.tstest), you can find these type of elements under "IndependentDescriptors".






We can do required updates here, they will reflect on element repository.


The advantage of first approach is, we no need to worry about element repository clean up where as in second approach, we have to spend some time on element repository clean up if required. Anyhow, in both cases, if we delete test case then the elements bounded with that case will be deleted automatically from element repository.