Entrepreneur, Blogger, Author

On Sunday, May 21, 2017 by Nishant Verma in ,
I was approached by one of the acquisition editors of a reputed publishing house. When we discussed the idea I felt I have already written a book on similar lines then why a new book. And I started evaluating my existing book which is available on Gitbook. It’s the most widely downloaded and read Appium book. But I felt that there is a chance to re-work on the book and improvise what I have already done.
This book "Mobile Test automation with Appium" is an idea to help a larger mass learn test automation and basics of mobile testing and automation using Appium. It’s written in such a way that if you know Java, you can pick up mobile test automation and practice it. It’s highly practical in approach with a lot of coding examples to help you learn. This book is aimed at saving a lot of your time in finding the right material and provides you a step by step guidance to learn how to design a good test automation framework from scratch.
It's going to be out in a month's time and would be available for purchase. I will update you here with more details.
On Friday, February 17, 2017 by Nishant Verma in , ,

Network Calls profiling for Mobile

Steps to intercept network calls:
  1. Download and install free version of burp (Location here: https://portswigger.net/burp/download.html)
  2. Launch the JAR and navigate to Start up.
  3. From menu tab select ProxyOptions
    1. In proxy Listeners section, click on Add
    2. Enter Bind to port value as 8080
    3. Choose Specific address and select your machine IP address. Press OK
  4. Click on HTTP history tab. Click on text: "Filter : Hiding CSS, image and general binary content”
  5. In Filter by MIME type, Select CSS, Images.
  6. Click on Filter tab again to close the window.

Steps to modify emulator settings:
  1. Start the android emulator
  2. After starting an android emulator, go to Settings->WiFi then click and hold the active wifi connection and select modify network.
  3. Click on Show advanced options” and in proxy (by default it is set to none) click on the drop down menu and select manual and now you should see more options like Proxy hostname and proxy port.
In the host name put the IP address of the Host machine which is the IP address you entered in burp and port number was 8080 (port to which burp proxy is binded) and click on Save and now you will be able to intercept all the HTTP (unencrypted) traffic that is sent by the android applications.

Install Certificate on the device

1. change the proxy setting in the browser and set the host to localhost and port to 8080 and click on CA Certificate and it will download a CA certificate.

2. Rename the CA certificate to cacert.crt and push it to the emulator SDCARD using the following commands:

  1. adb connect
  1. adb push cacert.crt /mnt/sdcard/cacert.crt

3. Now in the emulator / device go to Settings->Security in the Credential storage select Install form SD Card” and then you can select the cacert.crt” file present in the sd card and give the name cacert and click on OK and it will ask you to set a lock screen click on ok and select a type of lock screen and confirm (don’t forget the lock screen pattern)

For iOS devices:

Set the iOS Device Proxy
  1. Tap Settings > General > Network > Wi-Fi.
  2. Tap the Settings for the Wi-Fi network.
  3. Tap the Manual option in the HTTP Proxy section.
  4. In the Server box, type the IP address or hostname of your Fiddler instance.
  5. In the Port box, type the port Fiddler is listening on (usually 8080).
On Saturday, September 03, 2016 by Nishant Verma in , ,

In a hectic and a joyful life of running a company, being full time on a project and then being a father is just a little too much.  Writing took a back seat because of all this. 
So I thought to cut down my sleeping time to get back to writing blogs, it's liberating I feel. Here I have basically tried to discuss what we generally look in for when we are hiring especially for a position in start up point.

Excerpt here: 

We are 14 right now and we are still looking for more. We have filtered around more than 400 resumes, close to 150 face to face interviews and then we selected bunch of folks who are working with us. I have been doing interviews since 2007, so when I reflect at the hiring process, I feel there is not much change with respect to how you give interview. Largely the process of giving interview remained the same. To a certain extent the reason could be that what we ask in interview hasn’t changed.

Full blog here:  lnkd.in/fnTi6GJ
On Saturday, May 14, 2016 by Nishant Verma in

Recently while working on one of the Appium automation framework, we noticed this error:

"org.openqa.selenium.WebDriverException:  UiAutomator died while responding to command, 
please check appium logs! (WARNING: The server did not provide any stacktrace information)

Let me explain the framework we have. The framework is using Cucumber + Appium + Gradle. So the
test are written in feature file in plain english and in turn talk to step implementation which calls the page
class for any action. We also have some utils written which basically captures the screenshot of the device
on the step of failure and captures the adb log of the device. But in this case of error there was no snapshot
 taken. Also we are running the tests in parallel and are not using Selenium grid, we have our own custom
solution to take care of it.

Couple of guess what we made:
  • We suspected the issue to be session related and we tried the override session flag while starting appium server, but this didn’t fix it.
  • We switched from Genymotion emulator to run the test on actual device and even that didn’t fix it.
  • We changed the ADB from Genymotion to explicit machine installed one and even that didn’t solve it.
Lastly while seeing the execution carefully on both the device and almost after 3-4 runs, we found that when the network toggle test used to run the other device lost the connection or became un-reachable. I could see the device awake and the cursor blinking on the text box but device was in a state of wait till the new command time out happens and then it used to throw the error "UiAutomator died”.

So the actual culprit is the network toggle test running in parallel which caused it. 

Build info: version: '2.48.2', revision: '41bccdd10cf2c0560f637404c2d96164b67d9d67', time: '2015-10-09 13:08:06'
System info: host: 'xxxx-Mac-mini.local', ip: 'x.x.x.x', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.11.2', java.version: '1.8.0_74'
Driver info: io.appium.java_client.android.AndroidDriver
Capabilities [{app=/private/var/lib/jenkins/workspace/AndroidConsumerApp/x-x/SmokeTestSuite/app/app-staging-release.apk, appPackage=com.x.x.x, networkConnectionEnabled=true, noSign=true, warnings={}, databaseEnabled=false, deviceName=x, launchTimeout=50000, platform=LINUX, appActivity=com.x.x.x.x, stopAppOnReset=false, desired={app=/private/var/lib/jenkins/workspace/AndroidConsumerApp/x/SmokeTestSuite/app/app-staging-release.apk, appPackage=com.x.app.staging, appActivity=com.x.app.Splash, stopAppOnReset=false, noSign=true, newCommandTimeout=30, platformVersion=null, platformName=Android, udid=x, deviceName=Android, launchTimeout=50000, autoAcceptAlerts=true}, newCommandTimeout=30, platformVersion=4.4.2, webStorageEnabled=false, locationContextEnabled=false, browserName=Android, takesScreenshot=true, javascriptEnabled=true, platformName=Android, udid=x, autoAcceptAlerts=true}]
Session ID: 4ce65c07-1f16-4f6c-aedd-7357e081c4a1
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:206)
at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:158)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:647)
at io.appium.java_client.DefaultGenericMobileDriver.execute(DefaultGenericMobileDriver.java:42)
at io.appium.java_client.AppiumDriver.execute(AppiumDriver.java:1)
at io.appium.java_client.android.AndroidDriver.execute(AndroidDriver.java:1)
at org.openqa.selenium.remote.RemoteWebElement.execute(RemoteWebElement.java:326)
at io.appium.java_client.DefaultGenericMobileElement.execute(DefaultGenericMobileElement.java:44)
at io.appium.java_client.MobileElement.execute(MobileElement.java:1)
at io.appium.java_client.android.AndroidElement.execute(AndroidElement.java:1)
at org.openqa.selenium.remote.RemoteWebElement.sendKeys(RemoteWebElement.java:121)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.openqa.selenium.support.pagefactory.internal.LocatingElementHandler.invoke(LocatingElementHandler.java:51)
at com.sun.proxy.$Proxy15.sendKeys(Unknown Source)
at pages.BasePage.sendKeys(BasePage.java:121)
at pages.HelpPage.enterHelpText(HelpPage.java:51)
at steps.HelpPageSteps.onHelpPageIAskForHelpText(HelpPageSteps.java:30)
at ✽.When On Help Page I ask for help My bank card is not working and I tried reaching customer care(X.feature:20)
On Wednesday, March 16, 2016 by Nishant Verma in , , ,
Smartphone and tablet adoption has pushed the growth of mobile application in last couple years. People are spending more and more time on these devices and it has slowly replaced any other device as primary means of communication. Compared to web, mobile space is very challenging when comes to testing. Gone are the days when you had enough time on hand to develop a feature and push to production after thorough testing.
Even though most of the mobile app has only couple of screens (may be 5 or 6 max if it’s transactional in nature) and very limited input mechanism (mostly dominated by keyboard input or selecting by scroll) then what makes it complex?
Most of the mobile app (especially enterprise mobile app) has the need of releasing faster and releasing frequently. This is primarily due to new feature being pushed or user feedback incorporation. It could also be due to UX improvement or changes. So when we are talking about mobile app testing we need to have a strategy which supports:
  • rapid feature push
  • continuous testing
  • device coverage
  • team collaboration
While creating we should be leveraging our learning from web automation and pick all the concepts which are proven and working. For a test strategy to support rapid feature push and continuous testing, we need to have smoke test and functional test in place. While smoke test will make sure build has not broken any critical scenario, functional test would make sure that all major flows and scenarios are working via thorough testing.
Every tool has their own strength and limitation. While appium let’s you write test which are device agnostic, it’s limited in testing only with in app. For example appium (till version 1.5.0) doesn’t support testing toast messages on android. However, if you have to test toast messages, Espresso would be the right choice of tool and hence for building comprehensive unit test. So smoke test should be running on a build which has passed unit test, thereby subjecting the app to device level test (comprising of business critical flows ) and service level test (business critical end points). This will make sure that your app’s core functionality is working and would build confidence.
Functional test at the same time should be very comprehensive and test all the flows of the application. Functional test should also be testing app behaviour by simulating network condition (turning data off, GPS off) etc. Majority of the mobile app needs data connection and t’s important to capture how they handle data/app flows when network is off or limiting. 
Also when it comes to mobile there are tools like appiumcalabash which let folks explore functional test automation but at the same time it’s important to promote team collaboration via the solution. Especially for mobile app I would strongly recommend users to try cucumber style test so that right from dev to product manager everyone should be able to read and comprehend the test report. Below is a snippet from Cucumber website on how the automated script would look like. 
The idea is down the line product manager should be comfortable in writing the user scenarios which should serve as an input for quality team. Also the tools are evolving in a way to promote team collaboration for example there is a jenkins plug-in which post the build results on to slack, which is really cool. I am sure they will improve it to share test results as well.
While we have talked about importance of Smoke Test and how we could have a functional test to promote team collaboration, it’s time to also touch upon the very critical aspect of releasing app on devices, which is device coverage. Android throws in a very interesting problem to it’s developer group which is device fragmentation. Let me quote some pictures than text to give you a rough idea of what problem I am talking about. Below is the API distribution posted by google recently.
If you see the above break up of OS version, you would notice that to cover 80% of user base you need to have your test running on API level 16 to 23, this itself is a big problem. Also you don’t know which device family are being used by this fragment of user base. There are lot of popular ones like Samsung, Sony, Xiaomi and there are many which are unknown. If we see the brand fragmentation it will further worsen our problem.
So how do we deal with this?  There are device cloud offered by Google, Amazon and SauceLabs but even then which devices to run test on and which all features? One pays for every minute of device and hence the need is not only of automated test but “performant” test which do not have any place for false positive and false negative.
Your test strategy has to answer all this questions satisfactorily. So basically it boils down to two things:
  • how much of testing to be performed ?
  • on what devices this testing has to be performed?
Now certainly manual testing is not going to help you out seeing the OS fragmentation and device size fragmentation. If you have been relying on manual testing you were just lucky as you were siting on a time bomb which could explode any time.
You need to have a well thought of strategy to handle how much to test and what to test on. And majority of it goes down to how mature the test framework is to handle above mentioned things? Some of the asks from test framework would be:
  • able to run code on device or emulator
  • able to trigger test on locally connected device
  • support parallel test between devices
  • support easy integration with device providers in cloud
I have summarised a probable approach for app automation (in the pic below), which is just one piece of the mobile testing strategy. One certainly needs to look into their organisation need and demand to put in other components in the strategy which helps them release faster and release reliable product.
Please feel to reach out to me on nishant@testvagrant.com
On Sunday, February 07, 2016 by Nishant Verma in
Today I had been to hospital for some check up. After the initial analysis, I was sitting in a hospital and was waiting for my x-ray reports to come. While waiting there, I saw couple of people around and generally I take out my iPhone and get busy in some app. But today I suppressed my urge to take out phone reason being no data signal in basement. Yeah I didn’t wanted to hear music as well ! What I noticed in that hall for next 15 minutes was very different, realistic and special. 

People you see around and their expressions. There were people who were looked worried, some were with their kids and running behind them, in a bit lighter mood. Kids certainly add a new dimension to your life I felt. And quite a lot were busy in mobile, may be they had network :)

Another thing which I noticed was how ppl come dressed to hospital. Majority of the people came in casual clothing except few ladies who were dressed a little more for the occasion. I am no one to comment on that, however thing which really caught my interest was the dress of the hospital staff. Couple days back i was thinking if I should set a dress code for myself for work and was reading on Mark Zuckerberg style of same t-shirt to work. It’s quite interesting and I am going to give it a try!

I was also thinking on life, that it feels so easy when you have access to good medical support system, when you have resources to do pre-emptive medical check up . And how important it is for a person to have good access to medical system. And in a country like India where you have so much of population how does one create a good health infrastructure. It’s a tough job but certainly not impossible !

One thing I felt was you should spend some time doing nothing, experience nothingness. Just look around, observe people around and their life. It’s not necessary that you always talk to someone when you are jogging, or answering emails when in park. Observing around will make you aware of so many things and would be a welcome change. 
Web Analytics