Mobile Testing Challenges for the Software Testers in 2016

1. Native vs Web-view

This has been a continuous problem that will most likely be around for a long time; the willingness to get an API ready and complete and not resorting to having to use web views and other clunky alternatives.

Testing a hybrid app in the sense that some parts are native and some parts are webviews is a particular pain in the butt. When using these two side-by-side you can pretty much always notice that native is faster so a webview will always look slower and buggy. There’s almost always a problem with the API and a webview talking to each other.

Solution: If you’re going to build an app, make sure you have all the APIs you need ready and raring to go before dev starts or early enough that something can be done about it.
If not go for all webviews and keep the app looking consistent in one form or another. At least this way it won’t be noticeably different as you traverse the app.

2. Mobile Test Automation

Mobile test automation isn’t in a great place – the market is dominated by either big player pushing sub-standard, expensive tools to ‘automate all the things’ or smaller open-source tools that are at the mercy of the mobile OS vendors.

Too many people still have an ‘automate all the things’ test strategy for mobile, not realising that doing this is even more fool-hardy than on desktop web. Mobiles are complicated and automating a lot via the app UI is not the best strategy at all.

Solution: Focus on understanding your application and the web services it most likely uses. Automate those first. Apply a small, light-weight automated UI test set using whatever automation tool suits you best. Be aware that the automation tool you use may stop working because an OS vendor cut’s access to APIs so have a plan B.

3. Fragmentation

There are soooo many Android devices out there that you can only test a small fraction of them. Add to that the different flavours of OS’s (Samsung adds something, other manufacturers do so too) and you have many potential risks.

Solution: I’d like it if only stock Android was used but hey…I can keep on dreaming I’m afraid. As far as I know, there’s no simple solution. You just have to engage with your customer and talk about which devices / OS’s must be tested (based on facts like most popular devices in your country etc).

4. Unexpected pop-ups

It’s hard to write a repeatable automation test script when at any given time, an ad or other alert-style window appears and obscures the screen below. This has been a problem since the creation of the GUI and is still a problem in 2016. (Ads are mostly the problem now.)

Solution: Create a routine that is always running in a background thread and scanning the screen for a list of “usual suspect” pop-up windows. And if found, perform the actions necessary to remove it — usually it’s sending an “Escape” key event. You also have to make the main script flexible enough to know to wait if it gets “stuck” by a pop-up.

5. In The Wild Testing

One of the biggest challenges software testers need to handle in 2016 is manual “In the wild testing”. The problem that I see, is that many software testers, test mobile applications in the same way as they would test web or desktop applications, always on the same place with the same Internet connection. But mobile apps are not the same like web or desktop applications. They are used in a total different environment with different Internet connections. If a mobile app is tested only with a fast and stable Internet connection lots of problems will not be covered during the testing and development phase.

Testing the app in the wild may find problems with:

1. The light situation because of sun or rain.
   
2. With the sensors because they are interfered by other elements such as buildings, cars or other obstacles.
   
3. With the Internet connection. Due to the movement, uses have not always the same Internet connection and this has an impact to the mobile app under test. For example, the network switch from LTE to Edge may influence the UI or the information that will be processed between the backend and the mobile app.

The listed points are just some of the problems that will not be found in a lab situation.

Solution: The solution for this problem is pretty easy. Software testers must test outside the office. Depending on the use case of the app, the environment may change. For example if you are testing a business app, the app is likely used when people are commuting to or from work by train or car. Or if you are testing a sports app, that is tracking your workouts and activities, then you must test during this situations, too.

It is key for every software tester to test in the environment where the customers will use the app. I recommend to every software tester, to pack some devices in a backpack and to leave the office to test the app in the wild.

When testing in the wild it is important that the app under test is using a crash reporting tool like HockeyApp or Crashlytics to record any kind of problems that may happen during the test scenarios. Besides that I recommend to have just a pen and a piece of paper with you to make notes when discovering a problem.

Different kind of Exceptions occuring In Selenium WebDriver.

While automation it's quite common that we all come across different kind of Exceptions occurring In Selenium WebDriver.

 Lets see few Exceptions and what’s the reason for those !!!!  I hope this post will help you in memorizing such exceptions which you have been facing.

NoSuchElement : An element could not be located on the page using the given search parameters.


NoSuchFrame : A request to switch to a frame could not be satisfied because the frame could not be found.

StaleElementReference : An element command failed because the referenced element is no longer attached to the DOM.

Firefox Not Connected : Firefox browser upgraded toop new version.

ElementIsNotSelectable : An attempt was made to select an element that cannot be selected.

UnknownCommand : The requested resource could not be found, or a request was received using an HTTP method that is not supported by the mapped resource.

ElementNotVisible : An element command could not be completed because the element is not visible on the page.

InvalidElementState : An element command could not be completed because the element is in an invalid state (e.g. attempting to click a disabled element).

UnknownError : An unknown server-side error occurred while processing the command.

JavaScriptError : An error occurred while executing JavaScript code.

XPathLookupError : An error occurred while searching for an element by XPath.

Timeout : An operation did not complete before its timeout expired.

NoSuchWindow : A request to switch to a different window could not be satisfied because the window could not be found.

InvalidCookieDomain : An illegal attempt was made to set a cookie under a different domain than the current page.

UnableToSetCookie : A request to set a cookie’s value could not be satisfied.

UnexpectedAlertOpen : A modal dialog was open, blocking this operation

NoAlertOpenError : An attempt was made to operate on a modal dialog when one was not open.

ScriptTimeout : A script did not complete before its timeout expired.

InvalidElementCoordinates : The coordinates provided to an interactions operation are invalid.

IMENotAvailable : IME was not available.

IMEEngineActivationFailed : An IME engine could not be started.

InvalidSelector : Argument was an invalid selector (e.g. XPath/CSS).

Hope this post helps you guys…! And Please Correct me if there is something to be added…! ;)

A Detailed Guide on different type of Selenium WebDriver Wait

In automation, waiting is having the automated task execution elapse a certain amount of time before continuing with the next step. Selenium WebDriver provides various commands for implementing wait. In this post, we have listed out all the Selenium WebDriver wait commands for your reference.

Conceptually, Selenium WebDriver wait commands can be divided in various different categories. These are implicit wait, explicit wait, timeout, expected conditions, fluent wait etc. We will go through each one of them with their usage in this post. Whenever possible, we have provided code snippets for clear understanding. Implicit Wait: Implicit wait tells Selenium instance to wait for specified amount of time before throwing an exception. The default setting is 0. Let’s see how implicit wait works. While execution, if WebDriver cannot find element to act upon immediately, it will wait for specified amount of time. During this time, no attempt is made to find an element. After completion of specified time, WebDriver will try to find an element once. Exception is displayed if element is not found after that. Once set, the implicit wait is set for the life of the WebDriver object instance. That means it will be available for the entire time the browser is open.

Implicit wait can be implemented by using below code.

driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);

  
Explicit Wait: As the name suggests, we explicitly instruct WebDriver for waiting by using explicit wait. By using custom coding, we tell Selenium WebDriver to wait for some expected condition. Why use explicit wait when implicit wait is in place and doing good already? Glad you asked. Well, you may encounter instances when some element takes more time to load. Setting implicit wait for such cases doesn’t make sense as browser will wait unnecessarily for the same time for every element, increasing the automation time. Explicit wait helps here by bypassing implicit wait altogether for some specific elements.

Now let’s see how explicit wait works. WebDriver provides WebDriverWait and ExpectedConditions classes to implement explicit wait. Below code shows using WebDriverWait and ExpectedConditions for explicit wait. In this code, WebDriver will wait for 10 seconds before throwing a TimeoutException. If element is found, it will be returned in 0-10 seconds.

1	WebElement someElement = (new WebDriverWait(driver, 10)).until(ExpectedConditions.presenceOfElementLocated(By.id("elemendId")));

WebDriverWait by default calls the ExpectedCondition every 500 milliseconds until it returns successfully. ExpectedConditions class has some predefined common conditions to wait for an element.

Fluent Wait:
Unlike implicit and explicit wait, fluent wait uses two parameters. Timeout value and polling frequency. Let’s say we have timeout value as 30 seconds and polling frequency as 2 seconds. WebDriver will check for element for every 2 seconds until timeout value (30 seconds). After timeout value is exceeded without any result, exception is thrown. Below is a sample code which shows implementation of fluent wait.

1 2 3 4 5 6 7

Wait wait = new FluentWait(driver).withTimeout(30, SECONDS).pollingEvery(2, SECONDS).ignoring(NoSuchElementException.class); WebElement testElement = wait.until(new Function() { public WebElement apply(WebDriver driver) { return driver.findElement(By.id("testId")); } });

Another advantage of using fluent wait is, we can ignore specific types of exceptions (Eg. NoSuchElementExceptions) while waiting. Due to all these provisions, fluent wait is helpful in AJAX applications as well as in scenarios when element load time fluctuates often. Strategic use of fluent wait significantly improves automation efforts.

Timeouts:
Apart from waits mentioned about, Selenium WebDriver provides timeouts. There are two timeouts supported: pageLoadTimeout and setScriptTimeout. Let’s go through each one of them.
pageLoadTimeout: It sets the amount of time to wait for a page load to complete before throwing an error. If the timeout is negative, page loads can be indefinite. Use below code to implement pageLoadTimeout.

1	driver.manage().timeouts().pageLoadTimeout(100, SECONDS);

setScriptTimeout: It sets the amount of time to wait for an asynchronous script to finish execution before throwing an error. If the timeout is negative, then the script will be allowed to run indefinitely. Use below code to implement setScriptTimeout.

1	driver.manage().timeouts().setScriptTimeout(100,SECONDS);

Sleeper:
Using sleeper in your Selenium tests is not a good practice and should be avoided. Reason for this is, it forces browser to wait for specified amount of time. It unnecessarily delays other automation steps. You can implement sleeper in your test with below code.

1	thread.sleep(5000);

Here time value is in milliseconds.

You should always consider context while using Selenium WebDriver wait in your automation activities. Proper usage of waits would make your test robust and efficient. With that we hope our coverage of different Selenium WebDriver wait above will be helpful to you. Let us know your views on this.