Advantages of soapUI Pro

Most of the times while testing we come across the term 'Web Service' and we wonder what exactly is it? Web Service is a system designed to communicate between two machines, electronic of-course over the network. these are designed using different languages, methods etc of which the most common are REST, WSDL.

We as QAs are many times given a requirement to test the web services.Now the question comes up to our mind at first is that why do I need to test a web service? By testing a web service we validate the response coming and the time it takes to fetch the response.

The second question that comes up is how can we test a web service? The testing of web service can be done by various ways like Test pages / HTML Harness created by the developers, tools like Fiddler, soapUI, soapUI Pro, Test Maker etc.

What is soapUI Pro?

1.     Tool for functional testing of Web Services

2.     Easy to use Graphical Interface

3.     Easy Test Case creation and execution

4.     Provides complete test coverage

5.     Supports all standard protocols

6.     Load testing via LoadUI

7.     Automate Websites

8.     Licensed

    Why soapUI Pro?

1.     Provides Dynamic Data Generation 

2.     Data Source driven testing

3.     Coding Free Test Assertions

4.     Data collection 

5.     Assertion Test Step 

6.     Test Debugging 

7.     Advanced Reporting

8.     Support: Forum, email 

• Challenges and Experience in Mobile Testing domain

The mobile market has grown very rapidly in the past few years and the credit can be given to Apple for launching iPhone and then the app store successfully. People are now bending more towards the smart phones because it is making life simpler, now you can access your emails, bank accounts etc easily on phone and no more need to switch on your PC or laptop. However, with the increasing demand, the competition and the involved complexities are also increasing. With the increasing success of Android, many companies were forced to make Android based phone like Motorola, HTC etc which earlier had their own different operating systems. The Android sales for Q@ 2012 went over 50% (https://dottech.org/android/74191/android-tops-smartphone-sales-in-q2-2012-with-over-50-of-sales/). Over 300,000 mobile apps have been devel­oped in last three years and apps have been down­loaded 10.9 bil­lion times.

Mobilization is creating pressure on companies which are into this. With the wide range available in devices, operating systems, carrier providers; it is very difficult to maintain a quality which can sustain across the platforms. The mobile companies are now dwelling deep, analyzing their products, bringing new ventures to compete and most importantly meet the growing demand.

With this comes the need of assuring the good quality of the app, giving rise to the questions like ‘What is mobile Application testing?’, ‘Is the application tested well enough to be launched?’, ‘What are the most basic criteria that it should meet to be successful?’ Mobile application testing has become complex due to the variation available in the devices like wide range in screen resolution, hardware configuration, data speed, camera and image processing. Along with this the Operating systems (iOS, Android, Symbian etc) and the local service providers (GSM, CDMA etc) also add to the complexity. A Map with voice guiding application may work in US but may not work everywhere in India, same way sending SMS may work well in some parts of the world but not in other. All these factors then put an immense pressure on the mobile development and testing teams. It then becomes very difficult to nail down the support criteria.

The Big challenges faced by the Mobile Developers and testers:

       Mobile Devices:

Although I discussed this earlier but let me analyze this more from a developer / tester’s point of view. The major factors (as I said earlier) that affect an application are the screen resolution, the camera size, memory, sound, input modes. When the application designing starts these play a very important role for both developers and testers to decide what the base model should be against which the application is to be designed. This is a really very difficult question to answer as there are people using Galaxy Note, iPhone, tablets etc which if you see closely will have completely different set of configurations.

To solve this big question (as the application which we were working was a Cross platform application which should work on both Android and iOS), we had discussions with our client. The client then did a small survey at his end and in parallel we also ourself looked out for stats. Then the result that we narrowed down to wasn’t a specific model but a range which comprised the iPhone, ipad and LG / Galaxy phone models but no specific model (number).

         Operating Systems:

Currently in market we all know that Android and iOS are the most commonly used platforms while Symbian, Windows are not so popular although they too have their own application stores. For us the requirement was very specific to Android and iOS and hence we were focused on Android and iOS but then the question was what range of versions we should support.

                (http://wmpoweruser.com/wp-content/uploads/2012/07/Q2-2012-US-Smartphone-manufacturers-share.png?e83a2c)

We then checked the version history of Android and iOS, asked the client what version he had, checked for the latest version that we as a team could upgrade the phones that we had. Then finally for our first release of the application we decided to support android 2.3.3 and 2.3.6 while iOS 5.x. We also found that Android 4.x was out in market but wasn’t available for all handsets so we thought of not supporting that for the first release.

  

        Data carrier provider:

There are a lot of local data providers in market offering the best of their services in terms of data connectivity, bandwidth, and speed but still in any case the speed has to be fast. Whether it is a web or native application, both need speed and a good connectivity when the data download or upload is little huge but if the data is very low like in KBs then a low speed might work. The service varies with geography, it may be strong in urban are but very weak in core or the rural parts whether it’s AT&T or Airtel or some other network. Along with this the service may be very strong in US or Canada but less in Asia.

For our application the data download and upload both was little huge in MBs and while testing we needed a very strong wifi range to test. Infact sometimes when the range reduced, the application used to slow down or didn’t work at all. We had assurance from client that in places where they will use this, the data connectivity would be good. Still we tested for no data connectivity and GPRS with a 2G service. We made sure that there were no severe issues if the connectivity was slow or no connectivity.

        Posting the ‘native’ application on the Stores:

When an application specially ‘Native’ is developed and launched; the easiest way to distribute is the application store. You may ask people to download the app in their laptop or PC and then move it to the phone but that may not be very feasible when updates start flowing in. Then taking the application on a store is a big thing because there are some criteria, clauses stated down by Application stores based on which they put the application on the stores. I have even heard that they study the application, its purpose, what benefit will they get like how many people will download everyday etc , what development platform/ programing language is the application built on and then based on all this the decision is made.

For us we have made our application in Titanium (which has some of its own issues), it will be a closed application specific to a company. Hence we are still working out how to make this application go to the stores which is a risk for us. For now we will be distributing the ‘.apk/.ipa’ files to the people and then they will have to take from their PCs to the devices and then install.

    Integration with peripheral devices:

Sometimes there are requirement to have a peripheral device connect with the phone via Bluetooth like the common example is a music application should run well when a person uses Bluetooth headphones. Currently connecting a peripheral device for file transfer via Bluetooth is a common requirement.

We had to make our application take the barcode input from the scanners:

For this we had to enable a Bluetooth connection between the phone and this scanner. We could do this easily for Galaxy S II and iPhone but for a few models like Galaxy S we were not able to establish a Bluetooth connection as these devices did not at all show up in the available devices list. We tried installing an application to enable this connection but that too didn’t work.

These are some of the constrains that are very difficult to overcome specially when there is a very wide range of devices available. 

Usability of the application:

This is one the important challenges which we have to handle very well. UI / usability are the one which appeals a person to use the application. What the font size is, is it easy to tap on buttons, links, etc, is the color scheme used soothing for eyes. All these need to be looked very minutely.


When we had the first look of our app on Android – Galaxy S it was not acceptable because the background was black, the font too small and the images etc very dark. While on iPhone it just looked awesome with the white background. Now making it look good for Android was a challenge for us. To overcome this issue we decided to put same white color background (as of iPhone) for Android as well and it worked.


The other major usability issue we faced was that the app didn’t adjust well in landscape mode and lot of issues started showing up. We spend lot of time figuring out how to resolve this but with titanium it was little difficult so we had to remove the support for landscape mode.

Automation:

When everyday a tester has to run a same set of Suites or cases on an application again and again then the need for automation arises. For mobile application testing, this has been a big question for testers as even today there are not many good tools available in market that can be used across platforms and for native as well as web application. Android and iOS have their own tools, which come bundled with their SDKs like UI Automation and Monkey Runner but then creating and maintaining two different tools is not recommendable.

There are tools available in market like SeeTest (Plug In of QTP), Monkey Talk, etc but out of all these only a very few ones support both platform and that too for both native and web applications.

Four our project we did not need a UI Automation tool but we needed one for Web Service testing. We used SoapUI Pro 4.5 which suited well for our need and is a licensed tool.

Using emulator and simulator:

These are mostly used by developers for development because they provide the same look and feel, functionality as the actual device itself. This is very helpful in testing as well when the testing has to be done on different version of an OS; with emulators and simulator it is very easy to prepare by installing the required version SKDs and using them.

We had to test functionality where we had to track the GPS location of a person signed in the application and send the updated location every 10 minutes. This was very tricky for us as ideally we could not roam around every now and then to test. We tried that also but the locations transmitted very in 7th or 8th decimal place of the latitude or longitude. Hence the solution we used was that, for Android we prepared KML files with variations in the locations and then transmitted them to the application on Emulator via DDMS. While for iOS, the iPhone simulator had its own in built dummy location transmission functionality.

But these have a big drawback that sometimes crashing issues don’t show up. There were issues that continuously kept showing up on the actual device but never showed up on the emulator / simulator. Then the developers had to do a basic testing before release to QA to make sure that there were no crashing issues which they could not see while developing on the Emulator / Simulator.

 

The 'Helping Hands' in Testing Process - Documentations

In my 6.5 years of experience, what I noticed is that 'DOCUMENTATIONS' are the biggest helping hands for testers. The more you document and communicate, the more you grow as a tester and well of course verbal communications hardly involve the whole team and yes, they are lost over time. Believe me, we tend to be lazy thinking will document later and that later hardly comes, try avoiding this and even if you are busy find out some time may be 5 - 10 minutes to do the necessary documentations. Let me analyze the need of documentations - 'what? and why?' from the angle of the pillars of the QA process:

1. Requirement Analysis

When the requirement is published and freezed, read it very thoroughly and in parallel document the analysis point that are going to affect the testing. Also if you have any doubts about some features or functionalities, put them in the document or create a separate email and send across to the team or client. Always ask for replies over email as this will help for future reference. Having communication done over email helps a lot when in future we forget what was the answer; and more when the devs or the team contradicts then you can share the answers with the team to bring everyone on the track.

I mostly create FAQs page where I document the replies that I get from the client for my queries and that helps my team as well a lot.

2. Test Plan creation

It is practice which most of the projects follow that is to have the Test Plan documented and approved. But on the contrary many people feel this as an extra "not required" effort and rather try to discuss verbally and agree upon. This is wrong. Plans should always be documented and approved by the Manager. This helps a lot at release time when you are already under pressure and suddenly some things show up. At that ti you can refer to the plan and tell that this is what was decided and now if something more needs to be added then the testing tie will change or not everything will be tested and verified.

3. Test Case Creation

This is very very important documentation which all QAs should do. In my past experience I saw that the deadlines we so close that QAs were not given time to document their test cases also and when anything went wrong they were caught. This is bad. The Test cases should be documented well and reviewed by the TL / PM in case if something is missed. If the time is less at least try to document one line and share it with the team. I have even seen people who don't document just because they are confident enough about their mental capability that their mind is big enough to store. But we forget that tomorrow if we are asked to tell what we tested, it becomes difficult to convey.

Infact if possible it is eve better to have the Test Cases approved by the client, they are the best people to add if a part is missed out.

4. Test Data preparation

This may be required for everyone and is required mostly when the data preparation is a complex task and you are sort of trained on it.

I am seeing this, in my current project where I am the only person who knows the in and out of data preparation. In my absence my team should not be blocked so I have documented the test data preparation (which is preparing data in DB - quite complex) and I keep updating it frequently and sending it to my team.

5. Testing

While testing always add notes for test cases which are complex like how to executed and were there road blocks (not defects) from which you learn something out.

6. Test Report

A very important document which gives an outline of what all was tested or left out, defects verified or not verified with reasons. Now if the PM agrees on this then in future if you are questioned you can refer to the report.

All in all these are records of your work which the team accepted and agreed upon.

We need to have all these documented as 'always' tester is the first person to be questioned that why was this missed? Indeed this is a big question for which we don't have a reason because we didn't miss this intentionally. To avoid such questions I follow the above mentioned points very strictly and stay on a safer side because I have things noted with me and over communicated.

Try this out I am sure this will help to reduce these 'Whys'. :)

How to mock location on Android Emulator by using DDMS and KML file

Following are the steps:

1. Create a KML file like:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.x">
  <Placemark>
    <name>GE2ADT</name>
    <description>Attached to the ground. Intelligently places itself
       at the height of the underlying terrain.</description>
        <View><longitude>-88.03482</longitude><latitude>43.04186</latitude><range>750000</range><tilt>0</tilt><heading>0</heading></View><styleUrl>#red</styleUrl><Style><IconStyle><scale>0.3</scale></IconStyle><LineStyle><width>0.22</width></LineStyle></Style> <Point><coordinates>-88.03482,43.04186,0</coordinates></Point>
    </Placemark>
    <Placemark>
    <name>GE2ADT-1</name>
    <description>Attached to the ground. Intelligently places itself
       at the height of the underlying terrain.</description>
        <View><longitude>-88.03963</longitude><latitude>43.02743</latitude><range>750000</range><tilt>0</tilt><heading>0</heading></View><styleUrl>#red</styleUrl><Style><IconStyle><scale>0.3</scale></IconStyle><LineStyle><width>0.22</width></LineStyle></Style> <Point><coordinates>-88.03963,43.02743,0</coordinates></Point>
  </Placemark>
 </kml>

2. Launch the ddms from ...\tools.

3. In the ddms you can see in the left pane that there is no active device shown.

4. Launch you titanium Studio and select the project for which you want to test.

5. Click on run Configurations and in that select 'Google APIs for Android <version>' for 'Android APIs and click Run.

6. Wait for the emulator to start and then start Google Maps on it.

7. Now go to ddms and here now you can see the emulator processes in the left pane.

8. Now in the right pane go to tab 'Emulator Control'.

10. Scroll down and select tab KML.

11. Specify the location of the KML file.

12. In the table below you will the location coordinates uploaded form the KML file.

13. Scroll down little and click on the Play button.

14. Now go to Emulator where you should be able to see you location getting updated on the Google Maps.

Note: for a better idea add 5-6 location (Placemark) in the KML file.

The knowledge collection before starting off with testing

For beginners, who are completely new to Mobile Application testing, following are the items of which you should have / gather knowledge about, before you start off:

1. Latest trend in market for android, iOS etc.

2. Analyze business requirements.

3. Study in detail about OS features w.r.t business requirements.

4. Study about the history of the OS and the new trends going to come.

5. Explore a mobile phone - best suited for you need.

6. Prepare a Strategy.

7. Prepare a plan for various versions to be tested.

8. Do the required installation and play with it

Let's get into the details of these items one by one:

1. Latest trend in market for android, iOS etc:

In order to start with Mobile Application testing you need to have the 'complete' knowledge about the OS on which you are going to test your application and even know everything about the trends in market. This helps a lot when you actually start testing the application.

You can start reading about new versions available in market of Android, iOS etc, study about the features that are provided and if required document it at a place for your future reference. For this refer to the android site, Apple site and even a site called GSMarena etc, these have the latest news about the OS, phones etc.

If you have no idea about what android is or iOS is, read about them on Wikipedia, they share all the information like when it evolved, what is it etc.

Am important thing here that you can look for the update list of the OS version as to what all phone models can be updated.

2. Analyze business requirements:

 Once the Requirement is freezed start studying the requirement very thoroughly. In case of Agile, the Requirements keep on changing but that is fine still start reading. Read the requirement to a point where you can visualize the application in your mind and more importantly the ability to answer the question 'What is this application doing and why is it created for a mobile phone?'. Once you get the answer to this question, you have got a good idea about the project.

Here the Best practice is (if possible) ask questions to client about their business requirement like why this OS version? what is the OS commonly preferred by people at your place etc. This will help to get a better insight of the requirements. You can even come up with suggestions if you are confident enough.

Understand the various functionality, flows of the application and if required document it at a place so that you refer to it when you start writing Test Cases. You can also document the questions and answers from the client for your and the team's reference (believe me this helps a lot specially in the initial phases)

I personally always prefer to have as much documentation as possible. 

3. Study in detail about OS features w.r.t business requirements:

When you have got a good knowledge about the above two point then start relating the features with your business requirements. Study about the specifics of the OS in depth and list out the features that will affect the testing of the application. 

This will help you design your Test cases for 'Cross Platform testing'.

As an example for GPS testing, iOS3, on the dropped pin the current address shows up; such things are useful while testing. You can create a test case around this, that in iOS3 is the updated address showing up on the pin.

The next example  could be of Internet speed, here you can check the response of the application.

4. Study about the history of the OS and the new version going to come:

 Once you have the version on which whole testing is to be done freezed then you can start exploring the range of verions. This is needed as out in the world people may not be having the same OS as you test on, it may and it will vary. So look at the history of the OS version and the coming versions.

Discuss about this with you team lead or client and have a range set for which a smoke testing will be done to see whether the basic functionality work fine. 

The range can be something like few(2) version > current version < next version.

In ideal case testing for a range can;t be possible on the mobile device hence you can test this on Emulator where it is very easy to create the emulators of the specific android / iOS OS version.

Here, if you are testing on multiple OS like android, iOS then do the various version on one OS and on the other use only one OS for testing as it may not possible to test different versions on different OS; when in the initial phases.

5. Explore a mobile phone - best suited for you need:

This needs to be by those who have not used a phone with Android, iOS. This will help you learn about how the OS works, how to transfer files, access apps, upgrade apps, install - uninstall apps, using GPS, Google Maps etc on the phone.
In my case i wasn't very used to an iPhone so in the initial stage I used the phone that the company had, played with it. This made me comfortable with the phone so that when I start my testing I won't have to spend time in understanding iOS or iPhone. 
This is the step where you can tell the PM or TL if you need a smart phone for your testing and that if the phone provided by company is little out dated.
I saw a case where we had to order the latest iPhone 4S as we couldn't scan the bar codes with the set that we had, the camera wasn't so efficient. 
Here you can even upgrade the OS of the phone if it is outdated for the version on which you are going to perform all the testing. 

6. Prepare a Strategy:


Now is the time when you cna document the Test Plan as in the Strategy as you have the raw material ready with you.
In the Strategy mention briefly about the OS, versions that you are going to test on, get it reviewed by the Manager or TL and then you can send it to the client for their inputs.
Be clear about the phone model, the OS version while writing the Strategy because once freezed, these should not be changed, it may give a bad impression on the client.


7. Prepare a plan for various versions to be tested:

Now you can prepare the plan as to how will you test on the different versions and even you can now start creating the Test Scenarios for your testing and put them in different categories for the versions like some will be smoke tested, some will be regressed on a few versions. It would be a good practise to regress all the Test Scenarios on only 1 version at the start.
Also talk to the client about the version, phone model on which that person will test, it will help you while your testing.

8. Do the required installation and play with it:

For the application if there are applications that you need to install and learn, this is the point to do that like not lot of people use Google Earth is their day to day life and hence are not aware of how to use it so in your case if you have to use Google earth and you don't know much about it, start using it. 
It may be possible that you may need to install an '.apk' file for android and for that you will need a File Manager for your phone and you may not have one on your phone, install that and play with it as to how to install '.apk' files. In case of iPhone you may need to have and use iTunes of which mostly people are aware of but if you are not, insall it on your PC / laptop and start playing with it.