? QA Design Gurus: QA Challenges
Showing posts with label QA Challenges. Show all posts
Showing posts with label QA Challenges. 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.
 

Mar 30, 2016

Be a QA


Quality Assurance (QA) ensures the quality of the product and focus on giving confidence for the release. As a person, it is good to have a few qualities which will help us to excel in our job.
Let me give my version of QA.

QA means Questions & Answers:
Questioning is very important in our life. If we want to buy a product, we ask a lot of questions and will know about the product completely and then take the decision. And, if you are a seller, providing proper answers are also equally important to sell the product.
In the same way, QA has to ask questions whenever there is a feature discussion or in any meetings. And, as a QA provide various kinds of answers when a customer asks questions.

The best way to achieve this is to be active in Community/Forum where we get to know various kinds of questions as well as answers.
Bottom Line: Ask as many questions as possible, provide as many answers as possible

QA means Quick & Automate:
In this busy life, we have to take decisions quickly to resolve issues. For example, if we have a problem in our family, we have to work on it as soon as possible before it gets bigger.

In the same way, if we found any issue in the product or process then raise it immediately without any delay. And, learning the things quickly will give us ample time to look into other activities. If you pay attention in whatever you do, then quick learning will automatically happen.

Software testing has a huge scope and it contains a lot of testing types. It is not easy to say ‘We are ready for Production’ without doing enormous work. We have to take care of each and every testing type and ensure that everything is working fine.
How can we test all testing types within a given period of time to certify a build?
The only way to achieve this is using a weapon called ‘Automation’.
Automation helps us to do our existing tasks quickly and it allows us to explore new things.

Let me give an example to illustrate the same.
We want to travel from a source to destination.
We decide to take a vehicle based on the distance that is there in between. For example, if we want to travel to the USA, we catch the flight. If we want to travel within India, we have a few more options along with flight.
So, we use a vehicle to reach our destinations quickly.

In the same way, if we use a vehicle called automation in our software testing then we can reach our destinations called deadlines successfully without any issues. And, we can save a lot of time and effort if we do automation. As a QA person, we have to take a decision on which tool we need to use based on our testing category.
Bottom Line: Be quick in every action and try to automate everything that is coming in your way
So, what are you waiting for?
Be a QA person in both personal and professional life!!!

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.