QA Archives - Aleksandar Krstic

Coded UI – Finding Controls – Best Practices

In one of the previous posts I mentioned the ability to use parent-child relations in order to find controls, and in this article I’ll share my experience and what I find as best practice for finding controls.

Always look for ID or Friendly Name. Everythig else try to avoid, especially Tag Instance.
In case that element doesn’t have one of these two, find parent that have.
If both elements – child and parent doesn’t have any of these two, find parent that does

Why is finding ID or Friendly Name important? Simply, ID should be always unique, and Friendly Name is usually unique at least on current page.

Example:

<div id=”ihaveid”>
	<div> <!-- child1 – first child of div with id -->
		<div> <!-- child2 – first child of child1 -->
			<span>This is what I want to find</span> <!-- child3 – first child of child2 -->
		</div>
	</div>
</div>

So, logic here is to find child inside of child until you get where you want to be.

public HtmlDiv FindDivById(UITestControl parent, string id)
        {
            var parentdiv= new HtmlDiv(parent);
            parentdiv.SearchProperties.Add(HtmlDiv.PropertyNames.Id, id);
            return parentdiv;
        }
		
var parent = FindListById(browser, "ihaveid");
var child1 = parent.GetChildren()[0];  // 0 is 1st child, 1 is 2nd child, ….
var child2 = child1.GetChildren()[0]; 
var child3 = child3.GetChildren()[0];
Mouse.Click(child3);    // this is in case that you want to click on it, but logic is same for any other operation

As you see, logic is very simple. Find nearest parent element that have unique control(s) and search for child elements inside of it.

In my example elements used are div and span, but really you can use it in every combination with lists, paragraphs, …

Security Testing – SQL Injection

For many testers Security Testing is grey area.

One of common ways to test security of your web application is SQL Injection.

In this post I’ll cover basic testing with one of popular free tools – SQLMap – www.sqlmap.org

This tool support wide range of database systems – MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, HSQLDB and Informix database management systems.

How to use it?

Following steps are for MS SQL Server, but logic is same for all other types.

Download and install Python – https://www.python.org/downloads/
*Use 2.7.12 version, because version 3 is not supported
Download and extract sqlmap – http://sqlmap.org/
Go to your browser, run application that you want to test
Click F12 in your browser and go to Network tab, so you can track http requests

pen1

Navigate to field which you want to use for injection – e.g. First Name input field in some form, fill all required data and click Next/Submit button
In Network tab find request that was sent and collect data for your request
It’s something like this

pen2

You will usually need to handle json requests, so in this example we will use that type of request. Create json request based on data you found in Network and save it as .txt file.

pen3

Run CMD as Administrator
Type following command
C:\Python27\python.exe C:\PATH-TO-EXTRACED-SQLMAP-FILES\sqlmap.py -r C:\PATH-TO-TXT-FILE-WITH-SAVED-POST\penetration.txt -p PARAMETER-YOU-WANT-TO-TEST –dbms=”Microsoft SQL Server”

*First path is location where Python is installed
*Second path is location where sqlmap is extracted
*Third path is location where you saved your post as txt
-p is parameter that you want to use for injection. If you look image from above, we can use CardHolderName
–dbms is type of db Management System, you can leave it blank, tool will try process for every supported dbms.
Beside this, there are a lot of options that can be used – https://github.com/sqlmapproject/sqlmap/wiki/Usage
After execution of this command you will get a few Yes/No or Continue/Quit prompts, and of course select Yes or Continues (by typing Y or C in command line)
At the end you will get report is it your application vulnerable to SQL Injections or not.

Coded UI – Hand Coding vs. Recording

There are a lot of articles, blog posts and discussions on the web about Coded UI best practices.
Is recording better? Or is it better to write your own code? Or a combination of both? These are just some of the common questions which we can run into, especially from newcomers to Coded UI.

Main question you should ask yourself is – What is my goal?

If your goal is to create simple automation which will be executed only from your machine and no need to be consistent in any way (something like “one-time” testing), then my answer is recording.

Why? Because in half an hour or less, you will have created your automated test cases.

If your goal is to create complex and reliable automation which will be executed from various VMs or local machines, various resolutions, screen sizes, etc. … then you should definitely write own code.

Why? Because in that way you will have complete control over your automation. You will decide which control(s) will be searched (my suggestion is to look for ID first, because it should always be unique). When you cannot find ID for any specific control (submit button or whatever), my suggestions is to use parent – child relationships. Of course, you first need to find a parent with ID or some unique control. Will spend more time on this in separate post, but please look to the following example for better understanding.

public void EnterValueFriendlyNamebyParentDiv(UITestControl parent, string id, string Fname, string value)
    {
// first we search for parent div that have ID
        var parentdiv = new HtmlDiv(parent);
        parentdiv.SearchProperties.Add(HtmlDiv.PropertyNames.Id, id);
// now searching for input field inside of that div with specific friendly name
        var enterv = new HtmlEdit(parentdiv);
        enterv.SearchProperties.Add(HtmlEdit.PropertyNames.FriendlyName, Fname);
// enter whatever is defined as value
        enterv.Text = value;
    }

One more powerful fact that supports hand-coding is C#. Every method/assertion/whatever-you-need that doesn’t exist as part of Coded UI, can be programmed with C#. Basically there is no way that you cannot find any control, or handle any error, or solve any problem, if you know C# basics, you can solve it. Otherwise consider Google as you best friend. C# has a big and open community and will offer you a lot of answers for possible problems.

Why is recording not reliable? When you use recording and Coded UI cannot find any unique controls, it will use points (X, Y coordinates). That is the worst possible way to find controls, because on different resolutions/screen sizes Coded UI will hit the wrong point on the screen. Only if you’re lucky, during execution it will find controls on your machine (machine on which test is recorded). Also, beside points, another bad way to find controls is Tag Instance, which Coded UI like to collect during recordings. Tag Instance is bad because it can be generic.

Combination of recording and hand coding.

Again, whether this is the best choice for you depends on what you want to achieve. One thing that I would like to point out is to be careful with editing of recorded actions. When you record some action and you want to edit something related to that action in UIMap (add search control, for example) you need to know that after your next recording all your editing will be lost, because Coded UI reverts everything to its originally generated state after every recording.

Conclusion

No, Recording is not useless, it has its own uses over hand-coding. It takes less time for creation, and doesn’t require any coding background. However, as I said, if you want reliable automation which will not break without reason in more than 50% of cases, you need to go deeper and learn some basic coding.

Coded UI – Use Unit Tests instead of Assertions

Coded UI offers Assertions to use as the main method for verification points and compares in our tests, which works fine, but it can be very slow, depending on amount of controls (html tags) that your application has.

Instead of classic assertions, my suggestion is to use “unit tests”.

What does this mean?

Basically instead of Assertion, just try to find the control as you are doing when you want to click on something or to enter anything.

Example:
You have a shopping cart and you want to verify if the price is correct.

Instead of

var tablecell = GetShoppingCartCellByRowColumn(browser, "DataTables_Table_0", 1, 3);
Assert.AreEqual("$29.99", tablecell.InnerText);
//GetShoppingCartCellByRowColumn is method that searches table by ID and then specific cell by row and column.

Use

var tablecell = GetShoppingCartCellByRowColumnAndInnerText(browser, "DataTables_Table_0", 1, 3, "$29.99");
if (tablecell.Exists){
    //Happy message
    }
else {
    //Sad message
    }

Conclusion

In this example we are looking for a specific cell with a given value, instead of finding the cell and then comparing values. If the tool doesn’t find it, it will throw a custom message.
This approach simulates Assertion, but works much faster, and gives you more power for confirmation/error messages handling.