VanQ – Vancouver’s Local Software Quality Assurance Community Reaches 700+ Members and Counting

VanQ Software Quality Assurance group was formed over 10 years ago with a small community of local software developers and testers. This month we are celebrating a milestone as VanQ has now hit over 700 members.

Ed Dahl co-founded VanQ with the mission to build a strong local Software Quality Assurance community. Over the years the organizers have changed, but the mission has remained intact. Optimus Information took on carrying through this mission over two years ago and it has been a great way to connect with local and new software developers and testers. Our monthly Meetups bring out anywhere between 50 – 80 members with equal parts new and familiar faces. VanQ has proven to be a great way for new QA professionals to connect with seasoned professionals and become involved in this thriving community.

Over the years we have seen a number of great leaders, from a range of backgrounds and industries, share their ideas and experiences. We have also had a variety of sponsors join us in bringing the community together such as Hootsuite, Boeing – Aeroinfo Canada, Vision Critical, SOASTA and Mobify to name a few.

We have been able to capture a number of the Meetup presentations on video. Here are a few of our most recent Meetups. You can find the full archive at http://www.vanq.org.

Overview of the International Software Testing Qualifications Board (ISTQB)

For this Meetup, Gary Mogyorodi from the Canadian Software Testing Board in Toronto came out to speak with our members about the ISTQB, benefits of the ISTQB, Syllabi and Extension, the ISTQB footprint, the Canadian Software Testing Board, and the ISTQB Partner Program. Watch the complete presentation here:

Essential Skills for Test Automation & Load Testing

This past May, Alex Siminiuc, Freelance Tester with uTest.com, shared with us his thoughts on the skills needed for test automation and load testing. Alex has been a Software Tester since 2006 and actively blog’s here: test-able.blogspot.ca. Watch his complete presentation here:

Vision Critical’s QA Strategy: Prevention Rather Than Cure

Stuart Ashman, Vision Critical’s QA Director gave VanQ a presentation on how they attempt to ensure they ‘build it right’ as well as ‘build the right thing’. He goes through their process of using white box approaches, automation, risk analysis and strong critical and test thinking. Watch the full presentation here:

After taking the month of July off to enjoy some of the summer weather, we are gearing up for the next Meetup on Thursday, August 13, 2015. For this one we are excited to partner with Electronic Arts Games, TestDroid and the Vancouver Unity Games Meetup group for an exciting talk on ‘Driving Quality Through Test Automation of Mobile Apps and Games’. We will be hosting this Meetup at The Pint Public house. Join VanQ today and we hope to see you at the next Meetup: http://www.meetup.com/VanQ-Vancouver-Testing-and-Quality-Assurance-Group/

We are always looking for topic suggestions, speakers, sponsors and venue hosts. If you would like to get involved with VanQ get in touch with us.

How Facebook Field Tested Their iOS 7 Redesign

Facebook has always been known to be inventive and try new things even if it sometimes means that user experience is inconsistent or less polished than they expect. When Facebook developed the flexible Gatekeeper testing system, they were able to run thousands of variations of Facebook simultaneously and run tests collecting data about usage and performance. This data would be used to inform Facebook testers what improvements were ready to roll out.

FacebookRedesignsForIOS7 How Facebook Field Tested Their iOS 7 Redesign

Making the recent move away from the HTML5 platform and rebuilding the apps entirely on native infrastructure, the new apps are twice as fast as a result. Facebook’s app store ratings increased, and twice as many news feeds were read.

Facebook has no qualms about trying new ideas on their users and has never been afraid to see whether or not they are received well on a live environment. The “Gatekeeper” system was built to let their software testers simultaneously test thousands of variations of Facebook on the web with subsets of users, and collect data about usage and performance to inform what to roll out to everyone. Facebook software testers could test apps, upgrades, and patches, then roll back to a previous version without anyone barely noticing.

Although Facebook on the Android has a beta tester club, which launched in June 2013 that lets beta testers sign up and catch bugs, iOS still refuses to provide beta capabilities. Facebook decided to build out a new mobile app testing framework and started using it in March when they built the new and improved app, updated, and released it.

When you install the new Facebook for iOS, the app contains different versions of the user interface. You are one user in a group of a few thousand that is using one of those versions of one of the interfaces in the app. Facebook can then run multiple tests on multiple versions at once, rolling out multiple updates to see which variations benefit the user experience and Facebook.

Everyone has something they can learn from the Facebook testing team.

Checkout this unofficial video demonstrating the iOS7 Facebook App:

[youtube height=”300″ width=”600″]http://www.youtube.com/watch?v=gnXggjgWC3U[/youtube]

Are You Overlooking These Areas When Testing Your Mobile App?

Some people think testing mobile apps is easier than testing web applications or desktop applications because most mobile apps tend to be less complex. However, just because something is less complex doesn’t mean we testers can relax and assume that it is bug-free. Here are some common areas for bugs to hide that mobile app testers usually overlook.

Have you missed any of the following?

1. Keyboard buttons, such as “Done”, “Next”, “Search”

Sometimes, your app provides an on-screen button and a keyboard button to perform the same action, for example, “Done”, “Next”, and “Search”. Don’t just test the on-screen buttons and forget about the keyboard buttons! Some users may tend to use the on-screen buttons whereas some tend to use the keyboard buttons.

Make sure your app works with both on-screen and keyboard buttons.

2. Mobile app gestures

Every mobile OS platform has gesture and multi-touch support so that users can perform tasks more efficiently. And these features keep evolving. Sometimes, your developers associate app-specific tasks with different gestures, but sometimes, your app inherits the standard gestures without you knowing. For example, swipe to remove a row in a table.

Even if a gesture is not associated with a task, you may still want to try it out.

3. “Back” or “Cancel” button

Make sure there is a “Back” or “Cancel” button and it is enabled in any workflows.

Your users may want to visit the previous screen or exit from the current workflow.

4. Switch phone orientation during screen loading

It is common for apps to crash when you rotate the phone orientation while the app is loading. This is caused by apps that don’t handle the objects or data population properly when instantiating or destroying a view, resulting in a crash.

Make sure the app has been coded properly and isn’t subject to this all-too-common crash.

5. App update and re-installation

When you test a new release, do you have app update and re-installation tested as well? Usually we are too busy with testing the new features and regression testing so we forget or skip testing app update and re-installation.

This is especially important if your app stores data in its local database.

You may think it is unlikely to find any critical bugs in these areas, but as a tester, you should never hold an assumption and overlook any seemingly-alright parts. If you did not test any of the areas mentioned above, test them and you may find some surprising bugs.

If you have anything to add to the list, feel free to leave a comment and share with us.

The post Are You Overlooking These Areas When Testing Your Mobile App? appeared first on OptimusMobility.

Are You Overlooking These Areas When Testing Your Mobile App?

Some people think testing mobile apps is easier than testing web applications or desktop applications because most mobile apps tend to be less complex. However, just because something is less complex doesn’t mean we testers can relax and assume that it is bug-free. Here are some common areas for bugs to hide that mobile app testers usually overlook.

Have you missed any of the following?

1. Keyboard buttons, such as “Done”, “Next”, “Search”

Sometimes, your app provides an on-screen button and a keyboard button to perform the same action, for example, “Done”, “Next”, and “Search”. Don’t just test the on-screen buttons and forget about the keyboard buttons! Some users may tend to use the on-screen buttons whereas some tend to use the keyboard buttons.

Make sure your app works with both on-screen and keyboard buttons.

2. Mobile app gestures

Every mobile OS platform has gesture and multi-touch support so that users can perform tasks more efficiently. And these features keep evolving. Sometimes, your developers associate app-specific tasks with different gestures, but sometimes, your app inherits the standard gestures without you knowing. For example, swipe to remove a row in a table.

Even if a gesture is not associated with a task, you may still want to try it out.

3. “Back” or “Cancel” button

Make sure there is a “Back” or “Cancel” button and it is enabled in any workflows.

Your users may want to visit the previous screen or exit from the current workflow.

4. Switch phone orientation during screen loading

It is common for apps to crash when you rotate the phone orientation while the app is loading. This is caused by apps that don’t handle the objects or data population properly when instantiating or destroying a view, resulting in a crash.

Make sure the app has been coded properly and isn’t subject to this all-too-common crash.

5. App update and re-installation

When you test a new release, do you have app update and re-installation tested as well? Usually we are too busy with testing the new features and regression testing so we forget or skip testing app update and re-installation.

This is especially important if your app stores data in its local database.

You may think it is unlikely to find any critical bugs in these areas, but as a tester, you should never hold an assumption and overlook any seemingly-alright parts. If you did not test any of the areas mentioned above, test them and you may find some surprising bugs.

If you have anything to add to the list, feel free to leave a comment and share with us.

Tools to Enrich Your Calabash Test Framework

I have tried out a couple test automation tools for mobile apps, but I still like Calabash the most. However, no matter how strong a tool is, it has limitations and it may not support everything you want, and Calabash is no exception.

I just finished a test automation project for iOS apps. Let me share with you what extra tools I used to enrich the Calabash test framework.

Use fruitstrap to install the app on the test device

Calabash does not support app installation on the device, so before you run your Calabash tests, you have to make sure that your app has been installed on the device. You could always deploy your build using XCode, but it would be ideal if you can skip this manual step for your automation project.

A tool I used is fruitstrap; it allows you to install an iOS app via USB. You can check out the source code from the fruitstrap GitHub page. There is a blog post that provides more instructions on building and using fruitstrap.

Record console log during test run with idevicesyslog

When you test the debug build of your mobile app, sometimes, you want to monitor the console log in order to see what is going on underneath the UI, especially when there are crashes or the test scenarios fail.

Currently, Calabash does not support reading the device console, so you could use idevicesyslog from the libimobiledevice library. One way to implement this in your framework is, in the Before hook, fork a thread to read the console using idevicesyslog and print it in a file. Then, in the After hook, terminate the thread.

Here is the libimobiledevice page. And there is a GitHub page for libimobiledevice on Mac OS which contains the compiled libraries.

Format Cucumber results

Cucumber supports multiple report formats. Without specifying a formatter, your results will be printed on screen. If you have a lot of test scenarios in your test suite, it is going to be painful to scroll through your terminal to spot the results.

The Cucumber Reports page details the available formats. If you choose HTML as the report format, the screenshots taken by the screenshot_embed method are embedded in the report. If you integrate Calabash with Jenkins, you have to generate a JSON report.

Uninstall the app from the device using ideviceinstaller

After execution of a test suite is complete, the next step is to clean up the environment (sometimes, we may want to do a clean-up between tests).

To uninstall your app from your device, you can use ideviceinstaller from the libimobiledevice library. In fact, you can use ideviceinstaller to install, archive and list apps in a device.

The post Tools to Enrich Your Calabash Test Framework appeared first on OptimusMobility.

Tools to Enrich Your Calabash Test Framework

I have tried out a couple test automation tools for mobile apps, but I still like Calabash the most. However, no matter how strong a tool is, it has limitations and it may not support everything you want, and Calabash is no exception.

I just finished a test automation project for iOS apps. Let me share with you what extra tools I used to enrich the Calabash test framework.

Use fruitstrap to install the app on the test device

Calabash does not support app installation on the device, so before you run your Calabash tests, you have to make sure that your app has been installed on the device. You could always deploy your build using XCode, but it would be ideal if you can skip this manual step for your automation project.

A tool I used is fruitstrap; it allows you to install an iOS app via USB. You can check out the source code from the fruitstrap GitHub page. There is a blog post that provides more instructions on building and using fruitstrap.

Record console log during test run with idevicesyslog

When you test the debug build of your mobile app, sometimes, you want to monitor the console log in order to see what is going on underneath the UI, especially when there are crashes or the test scenarios fail.

Currently, Calabash does not support reading the device console, so you could use idevicesyslog from the libimobiledevice library. One way to implement this in your framework is, in the Before hook, fork a thread to read the console using idevicesyslog and print it in a file. Then, in the After hook, terminate the thread.

Here is the libimobiledevice page. And there is a GitHub page for libimobiledevice on Mac OS which contains the compiled libraries.

Format Cucumber results

Cucumber supports multiple report formats. Without specifying a formatter, your results will be printed on screen. If you have a lot of test scenarios in your test suite, it is going to be painful to scroll through your terminal to spot the results.

The Cucumber Reports page details the available formats. If you choose HTML as the report format, the screenshots taken by the screenshot_embed method are embedded in the report. If you integrate Calabash with Jenkins, you have to generate a JSON report.

Uninstall the app from the device using ideviceinstaller

After execution of a test suite is complete, the next step is to clean up the environment (sometimes, we may want to do a clean-up between tests).

To uninstall your app from your device, you can use ideviceinstaller from the libimobiledevice library. In fact, you can use ideviceinstaller to install, archive and list apps in a device.

Mobile Application Testing in the Cloud

Automated testing is like any good board game – easy to get started, difficult to master! On the mobile side, automated testing is a booming industry with countless products and platforms being launched to help serve this painful niche. We’ve talked about mobile application testing several times on our blog – today I’m going to give an overview of automated mobile testing in the cloud!

What is ‘cloud based’ mobile application testing?

By cloud based mobile app testing, we are referring to the growing number of services that enable you to spin up a physical device, anywhere in the world, install your application on it, and test how it responds under local network conditions. This is an amazing technology that empowers mobile developers to actually see how their application runs on devices around the world.

I emphasize the importance of using a physical device because testing in a simulator isn’t adequate to ensure the application is production ready.

Using tools such as Perfecto Mobile, with the simple setup of an account you gain access to devices around the world. Here is a list of just a few of the real devices you can spin up on Perfecto:

available-devices-300x166 Mobile Application Testing in the Cloud

A Quick Demo

We’re in the process of launching a mobile app and website called IR Social. It’s a social media aggregation tool for investor relations. As we’re launching an HTML5 based version that’s designed to work on all modern smartphones, we need to test in on a variety of devices, mobile operating systems, and screen sizes.

Although we have a device library of 50+ devices, there will always be gaps and it’s not worth while to keep a stock of each combination of device+OS laying around. So, when we need to test on a rare device+OS combination, we go to Perfecto and get access to virtually any device+OS combination we need.

Below I’ve launched a real iPhone and a real Nexus so I can do a side-by-side comparison of the mobile website.

cross-platform-testing-1024x796 Mobile Application Testing in the Cloud

In this case I’m testing out the mobile web version of our web-app. Once I’ve launched the browsers I can do a side-by-side comparison of UI, functionality, and performance. In the above case I can see that the UI is rendered differently and that default fonts are causing issues.

Why are Real Devices Better than Simulators?

When testing a mobile application, there is no comparison between testing in a simulator and testing on a real-device. Simulators give an unrealistic impression of the application as they don’t face the same types of issues that real devices do. For example, on a simulator you can replicate network issues, but it fails to impose the sames types of limitations that may come from local networks.

When we’re working on an application that is going to be launched worldwide, we want to test it on worldwide networks. If we expect an influx in usage in Japan, we’re going to test the application on the leading telco’s networks because the differences in protocols can affect how content is synchronized with your application.

Tools like Perfecto become invaluable for this need and we’re excited to see this company rapidly grow their feature set. With deep integrations with HP’s QTP and now Microsofts TFS, Perfecto is becoming a defacto testing tool for enterprise level mobile app development.

The post Mobile Application Testing in the Cloud appeared first on OptimusMobility.

Mobile Application Testing in the Cloud

Automated testing is like any good board game – easy to get started, difficult to master! On the mobile side, automated testing is a booming industry with countless products and platforms being launched to help serve this painful niche. We’ve talked about mobile application testing several times on our blog – today I’m going to give an overview of automated mobile testing in the cloud!

What is ‘cloud based’ mobile application testing?

By cloud based mobile app testing, we are referring to the growing number of services that enable you to spin up a physical device, anywhere in the world, install your application on it, and test how it responds under local network conditions. This is an amazing technology that empowers mobile developers to actually see how their application runs on devices around the world.

I emphasize the importance of using a physical device because testing in a simulator isn’t adequate to ensure the application is production ready.

Using tools such as Perfecto Mobile, with the simple setup of an account you gain access to devices around the world. Here is a list of just a few of the real devices you can spin up on Perfecto:

 

A Quick Demo

We’re in the process of launching a mobile app and website called IR Social. It’s a social media aggregation tool for investor relations. As we’re launching an HTML5 based version that’s designed to work on all modern smartphones, we need to test in on a variety of devices, mobile operating systems, and screen sizes.

Although we have a device library of 50+ devices, there will always be gaps and it’s not worth while to keep a stock of each combination of device+OS laying around. So, when we need to test on a rare device+OS combination, we go to Perfecto and get access to virtually any device+OS combination we need.

Below I’ve launched a real iPhone and a real Nexus so I can do a side-by-side comparison of the mobile website.

 

In this case I’m testing out the mobile web version of our web-app. Once I’ve launched the browsers I can do a side-by-side comparison of UI, functionality, and performance. In the above case I can see that the UI is rendered differently and that default fonts are causing issues.

Why are Real Devices Better than Simulators?

When testing a mobile application, there is no comparison between testing in a simulator and testing on a real-device. Simulators give an unrealistic impression of the application as they don’t face the same types of issues that real devices do. For example, on a simulator you can replicate network issues, but it fails to impose the sames types of limitations that may come from local networks.

When we’re working on an application that is going to be launched worldwide, we want to test it on worldwide networks. If we expect an influx in usage in Japan, we’re going to test the application on the leading telco’s networks because the differences in protocols can affect how content is synchronized with your application.

Tools like Perfecto become invaluable for this need and we’re excited to see this company rapidly grow their feature set. With deep integrations with HP’s QTP and now Microsofts TFS, Perfecto is becoming a defacto testing tool for enterprise level mobile app development.

Selenium Android Driver Setup

The Selenium Android Driver lets you automate testing of web apps viewed through Android browsers using Selenium. It aims to provide a friendly API that’s easy to explore and understand, which will help make your tests easier to read and maintain. It’s not tied to any particular test framework, so it can be used equally well with JUnit, TestNG or from a plain old “main” method.

Android Driver allows you to run automated end-to-end tests that ensure your site works correctly when viewed from the Android browser. Android WebDriver supports all core WebDriver APIs and it supports mobile-specific and HTML5 APIs.

Android WebDriver models many user interactions such as finger taps, flicks, finger swipe and long presses.

Setup

  1. Download selenium jars and android-server.apk
  1. Download selenium jars and android-server.apk file from Google Code.

selenium-downloads Selenium Android Driver Setup

  • Create a new Project.
  1. Open Eclipse IDE and go to File -> New -> Java Project.
  2. Name the project as AndroidTest.
  3. Click Finish to create the project.

create-java-project Selenium Android Driver Setup

  • Create source folder for storing test scripts.
  1. Right click src folder under the project and select New -> Folder. Name the folder as com and click finish.
  2. Create a folder called core under the com folder.
  3. Similarly, create a folder called test under the core folder.

create-source-folder Selenium Android Driver Setup

  • Create Library folders for storing jars.
  1. Right click project folder and select New -> Folder. Name the folder as libs and click finish.
  2. Right click libs folder and select New – > Folder. Name the folder as libs and click finish.

create-library-folder Selenium Android Driver Setup

  • Copy the Selenium jar file into the project.
  1. Copy Selenium.jar and Selenium-srcs.jar in the AndroidTest -> libs folder.
  2. Copy other jars files in the folder AndroidTest -> libs -> libs folder.

copy-jar-files Selenium Android Driver Setup

  • Add the jar files to the build path.
  1. Right click the project folder and select build path -> configure build path.
  2. Click add jars.
  3. Navigate to the location of jars and select the jars.
  4. Click ok once you are done.

add-jar-files Selenium Android Driver Setup

  • Adding a test case to the project.
  1. Right click the com.core.test folder and select New – > Class.
  2. Name the class as TC1.
  3. Click Finish.

add-test-case Selenium Android Driver Setup

  • Write the Test Script.
  1. Import all the selenium libraries into the project.
  2. Write the test script like in the two samples below.
  3. Remove the errors and warnings.
package com.core.test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.android.AndroidDriver;
import org.testng.annotations.Test;

public class TC1  {

  @Test (groups="run")	
  public void testGoogle() throws Exception {
    WebDriver driver = new AndroidDriver();
    
    // Open Google.com
    driver.get("http://www.google.com");
    
    // Find element by its name
    WebElement element = driver.findElement(By.name("q"));
    
    // Enter something to search
    element.sendKeys("Optimus Information");
    
    // Now submit the form. WebDriver will find the form for us from the element
    element.submit();
    
    // Get the title of the page
    System.out.println("Page title is: " + driver.getTitle());
    
    // Sleep for 10 seconds
    Thread.sleep(10000);
    
    // Quit the driver
    driver.quit();
    
  }
}
public class TC2  {
	
	  private static WebDriver driver;
	  public char result2;

	@SuppressWarnings("deprecation")
	@Test (groups="run")	
	  public void testGmail() throws Exception {
	    driver = new AndroidDriver();
	    
	    driver.get("http://www.gmail.com");
    	Thread.sleep(1500);
    	
    	driver.findElement(By.name("Email")).click();
    	driver.findElement(By.name("Email")).sendKeys("myuser4312"); 
    	Thread.sleep(1000);
    	driver.findElement(By.name("Passwd")).click();
    	driver.findElement(By.name("Passwd")).sendKeys("newpass102");     
    	Thread.sleep(1000);
    	
    	//driver.findElement(By.xpath("//input[@name='signIn']")).click();
    	
    	//driver.findElement(By.className(""));
    	
    	driver.findElement(By.name("signIn")).click();
    	
    	Thread.sleep(30000);
    	
    	driver.findElement(By.cssSelector(".V.j.ge")).click();
    	
    	Thread.sleep(5000);
    	
    	String useremail =  driver.findElement(By.cssSelector(".V.Y.XD.Ji")).getText();
    	System.out.println("User Email is " +useremail);
    	
    	if ( useremail.equals("myuser4312@gmail.com") )
    	{
    	  System.out.println("TestCase2 Passed");
    	  result2='P';
    		
    	}
    	
    	Assert.assertEquals('P', result2);
    	
    	driver.quit();
    	
	    
	  }
	}

  • Configure Testing XML.
  1. Create testng.xml in the folder com.core.test.
  2. Make entries into the xml as shown below.
<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >
<suite name="Google Test Suite">

  <test name="TC1:To verify the google Home Page">
  	<groups>
      <run>
        <include name="run"/>
      </run>
    </groups>
    <classes>
       <class name="com.core.test.TC1" />
    </classes>
  </test>
  
  <test name="TC2:To verify that user is able to Login to Gmail">
  	<groups>
      <run>
        <include name="run1"/>
      </run>
    </groups>
    <classes>
       <class name="com.core.test.TC2" />
    </classes>
  </test>
  

</suite>
  • Install Android Web Driver app on the Device.
  1. Copy android-server-2.21.0.apk to the phone.
  2. Install the app on the device.

install-web-driver-app Selenium Android Driver Setup

  • Connect the device and start the WebDriver application.
  1. Connect the device to your pc using USB (Debugging mode).
  2. Start the WebDriver application.

start-web-driver Selenium Android Driver Setup

  • Port Forwarding.
  1. Open the command prompt.
  2. Go to directory containing adb.exe.
  3. Enter the following command: adb forward tcp:8080 tcp:8080.

port-forwarding Selenium Android Driver Setup

  • Execute the Test.
  1. Right click testng.xml and select Run As -> TestNg Suite.

execute-test Selenium Android Driver Setup

  • Observe the Test Case running on Device.
  1. Test case is executed in the Web Driver’s in built browser.

observe-test Selenium Android Driver Setup

  • Analyze the results.
  1. Double click the test-output folder under the project.
  2. Open index.html and emailable-report.html to get the results of the tests

google-test-suite Selenium Android Driver Setup

execute-test Selenium Android Driver Setup

The post Selenium Android Driver Setup appeared first on OptimusMobility.

Selenium Android Driver Setup

The Selenium Android Driver lets you automate testing of web apps viewed through Android browsers using Selenium. It aims to provide a friendly API that’s easy to explore and understand, which will help make your tests easier to read and maintain. It’s not tied to any particular test framework, so it can be used equally well with JUnit, TestNG or from a plain old “main” method.

Android Driver allows you to run automated end-to-end tests that ensure your site works correctly when viewed from the Android browser. Android WebDriver supports all core WebDriver APIs and it supports mobile-specific and HTML5 APIs.

Android WebDriver models many user interactions such as finger taps, flicks, finger swipe and long presses.

Setup

  1. Download selenium jars and android-server.apk
  1. Download selenium jars and android-server.apk file from Google Code.

selenium-downloads Selenium Android Driver Setup

  • Create a new Project.
    1. Open Eclipse IDE and go to File -> New -> Java Project.
    2. Name the project as AndroidTest.
    3. Click Finish to create the project.

    create-java-project Selenium Android Driver Setup

  • Create source folder for storing test scripts.
    1. Right click src folder under the project and select New -> Folder. Name the folder as com and click finish.
    2. Create a folder called core under the com folder.
    3. Similarly, create a folder called test under the core folder.

    create-source-folder Selenium Android Driver Setup

  • Create Library folders for storing jars.
    1. Right click project folder and select New -> Folder. Name the folder as libs and click finish.
    2. Right click libs folder and select New – > Folder. Name the folder as libs and click finish.

    install-web-driver-app Selenium Android Driver Setup

  • Copy the Selenium jar file into the project.
    1. Copy Selenium.jar and Selenium-srcs.jar in the AndroidTest -> libs folder.
    2. copy-jar-files Selenium Android Driver Setup

    3. Add the jar files to the build path.
    1. Right click the project folder and select build path -> configure build path.
    2. Click add jars.
    3. Navigate to the location of jars and select the jars.
    4. Click ok once you are done.

    add-jar-files Selenium Android Driver Setup

  • Adding a test case to the project.
    1. Right click the com.core.test folder and select New – > Class.
    2. Name the class as TC1.
    3. Click Finish.

    add-test-case Selenium Android Driver Setup

  • Write the Test Script.
    1. Import all the selenium libraries into the project.
    2. Write the test script like in the two samples below.
    3. Remove the errors and warnings.

    [code language=”java”]
    package com.core.test;
    import org.openqa.selenium.By;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.WebElement;
    import org.openqa.selenium.android.AndroidDriver;
    import org.testng.annotations.Test;

    public class TC1 {

    @Test (groups="run")
    public void testGoogle() throws Exception {
    WebDriver driver = new AndroidDriver();

    // Open Google.com
    driver.get("http://www.google.com&quot;);

    // Find element by its name
    WebElement element = driver.findElement(By.name("q"));

    // Enter something to search
    element.sendKeys("Optimus Information");

    // Now submit the form. WebDriver will find the form for us from the element
    element.submit();

    // Get the title of the page
    System.out.println("Page title is: " + driver.getTitle());

    // Sleep for 10 seconds
    Thread.sleep(10000);

    // Quit the driver
    driver.quit();

    }
    }
    [/code]
    [code language=”java”]
    public class TC2 {

    private static WebDriver driver;
    public char result2;

    @SuppressWarnings("deprecation")
    @Test (groups="run")
    public void testGmail() throws Exception {
    driver = new AndroidDriver();

    driver.get("http://www.gmail.com&quot;);
    Thread.sleep(1500);

    driver.findElement(By.name("Email")).click();
    driver.findElement(By.name("Email")).sendKeys("myuser4312");
    Thread.sleep(1000);
    driver.findElement(By.name("Passwd")).click();
    driver.findElement(By.name("Passwd")).sendKeys("newpass102");
    Thread.sleep(1000);

    //driver.findElement(By.xpath("//input[@name=’signIn’]")).click();

    //driver.findElement(By.className(""));

    driver.findElement(By.name("signIn")).click();

    Thread.sleep(30000);

    driver.findElement(By.cssSelector(".V.j.ge")).click();

    Thread.sleep(5000);

    String useremail = driver.findElement(By.cssSelector(".V.Y.XD.Ji")).getText();
    System.out.println("User Email is " +useremail);

    if ( useremail.equals("myuser4312@gmail.com") )
    {
    System.out.println("TestCase2 Passed");
    result2=’P’;

    }

    Assert.assertEquals(‘P’, result2);

    driver.quit();

    }
    }

    [/code]

  • Configure Testing XML.
    1. Create testng.xml in the folder com.core.test.
    2. Make entries into the xml as shown below.

    [code language=”xml”]
    <!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd&quot; >
    <suite name="Google Test Suite">

    <test name="TC1:To verify the google Home Page">
    <groups>
    <run>
    <include name="run"/>
    </run>
    </groups>
    <classes>
    <class name="com.core.test.TC1" />
    </classes>
    </test>

    <test name="TC2:To verify that user is able to Login to Gmail">
    <groups>
    <run>
    <include name="run1"/>
    </run>
    </groups>
    <classes>
    <class name="com.core.test.TC2" />
    </classes>
    </test>

    </suite>
    [/code]

  • Install Android Web Driver app on the Device.
    1. Copy android-server-2.21.0.apk to the phone.
    2. Install the app on the device.

    install-web-driver-app Selenium Android Driver Setup

  • Connect the device and start the WebDriver application.
    1. Connect the device to your pc using USB (Debugging mode).
    2. Start the WebDriver application.

    start-web-driver Selenium Android Driver Setup

  • Port Forwarding.
    1. Open the command prompt.
    2. Go to directory containing adb.exe.
    3. Enter the following command: adb forward tcp:8080 tcp:8080.

    port-forwarding Selenium Android Driver Setup

  • Execute the Test.
    1. Right click testng.xml and select Run As -> TestNg Suite.

    execute-test Selenium Android Driver Setup

  • Observe the Test Case running on Device.
    1. Test case is executed in the Web Driver’s in built browser.

    observe-test Selenium Android Driver Setup

  • Analyze the results.
    1. Double click the test-output folder under the project.
    2. Open index.html and emailable-report.html to get the results of the tests

    google-test-suite Selenium Android Driver Setup
    testng-report Selenium Android Driver Setup