Symptoms that your mobile automation is going to fail

Smartphone users are increasing every day and mobile world is growing so rapidly. People now share and access mobile apps more frequently than web apps.

Now talking about their creation, release cycles are so quick that you have to do a lot of work in testing product and that too should be quick. What choice we left ? Automation!. But are we really utilizing that in good manner or we are just making simple things too complex by introducing automation.

Based on my experience their are few symptoms which indicates that you are going towards failure in mobile automation. Agenda for sharing this info is to make you enable in judging whether you are going on right track or not.

So be aware of following 10 symptoms which might lead you to failure if you will not find alternative for them-

  1. Deploying the build (APK/IPA) is a manual process– If you are still doing it manually, stop it. Mobile automation should be as smooth as automating a web app and accessing it through a browser. To speed up the process this part of automation should be automated. There are several tools e.g. Jenkins, Team City. You can refer to my blog Continuous integration with Jenkins in 5 minutes for Continuous integration setup.
  2. No Process where test can execute 24/7 – In the agile world, release cycles are too quick and a tester hardly get some time to perform Regression, functional testing for each feature. You should have a process where your automation test can be triggered anytime and can give you quick validation results. You can achive it by setting up your own mobile devices cloud, or you can use existing paid services like Saucelabs, Testdroid cloud etc.
  3. Scrolling the device screen is co-ordinate based – If this is the case it is very hard to stable your test. As an automation developer, our primarily goal is to make sure that a test can successfully executed on any device of any size. So make sure all actions are object based rather than co-ordinate based. your script might not work for a device with different size.
  4. Wasting more time in stabilizing test rather than building them – It happens when we start creating script, we don’t really realize the factors like – locator strategies, target devices, screen sizes, complex actions involved. As a result, after certain point we waste our time in making current script stable and cant really look forward for new creation. So advice is before starting a project do a little bit of POC(proof of concept), identify the complex situations and take care of them from the starting itself.
  5. You can’t remember the last time when your tests ran successfully – I have seen such situations that when people have small numbers of cases, they have a control to easily identify the false failures and modify the script accordingly. then slowly false failures keeps growing up as the number of cases increases. I would say don’t let you get into that situations. Take each false failure seriously and try to handle all exceptions, so that you can have confidence in your scripts when it comes to releasing the app.
  6. Using indexes at too many places to identify the elements on screen – If you had worked on selenium, you might related when we create xpath based on location in html DOM, It is similar to that. Avoid using indexes in your locators. Mobile app web views, text box’s positions might change in future and you will again end up with modification of scripts.
  7. Using Image recognition or OCR extensively for identification – I have seen many times, people uses OCR or image based technique for identification of elements on screen. Chances of changing the UI design in mobile app are very high. Sometimes not the design but the images might get changes with minor pixel size changes and you need to replace all images for image based identification.
  8. Working for several months but have only dozen cases – A manual tester always try to create test-cases where he can achieve coverage in minimum cases, which result in few complex cases. When we take them for automation, we don’t really divide in to many smaller meaning full cases and start creating complex work flows. I suggest to break cases in smaller one, so that by using parallel execution you can minimize the execution time and get the more effective visibility in terms of coverage. So its good to have many small test scripts rather than few complex scripts.
  9. Running the same script on different size devices, never works on first try – Primary part of testing a mobile app is to test it across multiple devices and screen sizes. If this is not happening in single attempt, means you are not really taking care of all possible devices and screen sizes. You end up modifying your script as soon as you run the script on some new devices. So its advisable to be aware of device scope and functionality future in advance. Be in touch with business analyst is very important
  10. You are not controlling the targeted devices and versions – This is one of the most important aspects in terms of infrastructure for mobile script execution. As an automation engineer, you should be responsible for handling devices and their versions, installing apps in those devices. If someone else is doing it then you should be in sync with that team.

If you are facing anyone of above mentioned problem, start implementing best alternative. Lets not hamper your app quality and focus on being efficient in testing. Hope these point will help you.

If anyone has gone through some other complex situation in mobile automation, feel free to add your symptom in comment 🙂

 

Advertisements

Proof-read your Selenium WebElements

Selenium is a suite of software for automating browsers. It provides an API in different programming languages for automating browsers, by mimicking human actions with browser.  Locators are the part of browser automation testing. Locator tells Selenium which html element of a web page, Selenium has to perform action. These are the following locator strategies included in Selenium.

Locator Strategies-

  • ClassName
  • Css Selectors
  • ID
  • Link Text
  • Partial Link Text
  • Tag Name
  • Xpath

Selecting the correct and good locators, increases the robustness of your automation script. Good locators are –

  • Unique
  • Descriptive
  • Unlikely to change

Always prefer to access the elements using IDs and Classes, and if you have to specifically traverse an element in the web page, Go for CSS Selector and Xpath. Sometimes it happens that we create our own Xpath and CSS selectors, and as a human it does not always happen that we have create a correct CSS selector or Xpath.

Verifying the Locators

So how about verifying your locators before putting them in to your script. I have found a Firefox Add-on i.e. “FireFinder” using which it is possible and quite easy. I assume that you already have Firebug installed in your Firefox browser. Following are the instructions to install and use this add-on-

  • Open your installed Firefox browser and search for “FireFinder” add-on, as soon as you will reach to the FIreFinder add-on screen you see something like below:FireFinder_Installationpage
  • After installation, Firefox will ask for restarting the browser. After restarting the browser you can see that there is a FireFinder option in your FireBug toolbar.FireFinder_Toolbar
  • Now your browser is ready to use the Add-on. I will create a CSS Selector manually for Gmail Email Id field and verify the CSS Selector.
  • After inspecting the Gmail Email id field, I found that id for the Email field is “Email”. So I will create a CSS selector i.e. “input[id=’Email’]”. Now verify this selector by entering it in FIreFinderFireFinder_Highlighting

So this is how we can validate our customized CSS Selector and Xpath, even before executing our automation scripts. This will reduce the time spent in creating the locators and give confidence to our automation scripts.

I hope this has helped you in understanding the locators in Selenium. Your comments and feedback is most welcome. 🙂

Xpath : a path to your WebElement locators

Many times I hear from people that my Selenium script is not executing properly for different browsers. So we keeps on complaining that selenium is not really identifying our web elements on different browsers. But if we look at it deeply, it’s not selenium; it’s the locator engine of your browser which is not able to understand your WebElement’s locator.

So lets talk about the browser’s locator engine, Every browser has different mechanism to process your locator i.e Xpaths, Css Selectors, Ids etc. So when we try to execute our same script on different browser, it might not identify the same element it was  identifying on previous browser. So we need to create locator which has basic requirement to be robust for almost all browsers-

  • Relative xpath over absolute xpath.
  • Avoid using xpath or css selector if element itself has some unique attribute i.e. id, name, linkText, title.
  • Verify your xpath before executing script (Saves a lot of time).
  • Prefer using Css Selector over xpath if you creating your script for headless browsers like PhantomJs.
  • Create your customized locator if needed.

Lets understand the syntax of an xpath-

When you have a unique attribute for your targeted locator

//tagname[@attributename='attribute value']  e.g. //input[@id='username']
when you don't aware of specific tag name
//*[@attributename=’attribute value’] 

When you have no unique attribute but a parent of that element has some unique attribute

//parentTagName[@parentattributename=’attribute value’]/targetedElementTagName
e.g. //table[@id=’userTable’]/div
use double slash "//" if you are targeting to a grand child

Some  Xpath methods-

  1. Contains() – When you want to select an element which contains some part of its attribute, for e.g. you wan to select an element which contains text “user” in its id-
    //*[contains(@id,’user’)]
  2. starts-with() – When you want to select an element whose attribute’s value starts with some text. For e.g. you wan to select an element whose ids starts with text “user”-
    //*[starts-with(@id,’user’)]

Handling text attribute – Sometimes we use Xpath methods with text attribute and it does not work. we need to understand that text is not an element’s attribute, its a function. So if you are applying above conditions for text then it would look like as below-

//*[contains(text(),’user’)]
//*[starts-with(text(),’user’)]

Handling parent-child nodes

  1. accessing immediate parent – //tagname[@attribute=’attributevalue’]/parent::parenttag

e.g. //div[@id=’someid’]/parent::span – (here we are accessing parent span of some div child)

2. accessing grand parent – //tagname[@attribute=’attributevalue’]//ancestor::grandparenttag.

if there are multiple grandparent with same tag you can give index like below- //tagname[@attribute=’attributevalue’]//ancestor::grandparenttag[1]

3. accessing nth-sibling (following and preceding) – Suppose we have a div element and its six child of tag span. We have id of first span but want to access 5th span based on first-

//span[@id=’first_span_id’]/following-sibling::span[5]

for preceding sibling – Suppose we have a div element and its six child of tag span. We have id of 6th span but want to access 1st span based on 6th

//span[@id=’sixth_span_id’]/preceding::span[5]

So this was just little information about xpaths, creating customized xpath etc. I will be posting another blog with detailed information about creating  Css Selectors. Feel free to post comments in case of any concerns.

Happy Coding 🙂