Web Services and Mobile Apps Testing
11 January 201905 July 2017 | Software Testing
Mobile applications are constantly evolving and adapting as a result of the increased demands of the users for connectivity features and web services. Multi-platform products or services used for activities such as communication, shopping, finding vital health information or answering an entertainment quiz require web services that synchronize the mobile application with the desktop and save data or progress information.
As web services are more and more a necessity in the mobile world, a special spotlight is placed on their testing, as this could make the difference in user experience, security and performance.
After working with web services for a while I realized many questions may arise in the process of implementing and testing them. Of these, I will try to answer the following in this article:
- What are web services in mobile applications?
- What are the advantages and disadvantages of web services?
- What do you need to test web services?
- How can web services be tested?
What are web services in mobile applications?
Web services are the part of the server (API) that handles data for the mobile apps. They are services that act as intermediaries between the mobile application and the databases. Usually, web services fetch data, arrange it in an agreed format and send it at the request of the mobile application. They can also write the data in the database when it is received from the mobile app.
You might wonder at this point why the mobile application can’t communicate directly with the database. The answer is that it can, but by using web services, the security and the performance of the mobile application is increased. It is much faster and secure to get the data, filter it and sort it to your liking on a server or cloud and then send it to the app than to do all this on a mobile phone with much lower Space, Ram, CPU and power (battery). With web services, the communication is done on the HTTP(s) protocol and the data is exchanged in the agreed markup language (XML, JSON).
What are the advantages and disadvantages of web services?
Yes, web services can come with disadvantages as well. But let’s see some of the advantages first:
- fewer updates – you can update the data from the web services;
- less decision making in your app, as some of the filtering, sorting and validating can be done on the server side;
- better security, as the user has no access to the security measures;
- a more dynamic application with the option to disable or enable features from the web services;
- “lighter” mobile app, as some of the code is server side;
- synchronization with Desktop and Web;
And now the disadvantages:
- more potential failure points;
- the need of a good documentation system, based on which to develop and test the application;
- more testing resources;
- the need of tools for testing.
What do you need to test web services?
As a tester, you should focus your efforts on some of the parts of the web services, such as:
- the data that is sent to the API (PUT and POST methods),
- the behavior of the application – the app should make the correct requests within the correct format,
- the headers and authorizations – the web services are not sending unwanted headers and
- the response of the application to the received data (GET method).
Two of the most overlooked aspects of web services testing are the assumptions that the data received through the web services is always correct and that the server will always respond fast and on time. I will provide more details about this challenge in the following section.
For web services testing, the first thing you need is a good documentation of the web service calls that the application should make and on how the API would respond to the requests.
Secondly, you need an HTTP proxy debugging software that can intercept and edit the requests the app makes or the response the API gives. For this, you can use Fiddler, Charles or Burp Suite. You can also look at penetration testing tools used for Man in the Middle attacks, as similarities can be found in the testing process.
How can web services be tested?
We have reached the most interesting part of this article – how should you test the web services and what should you focus on?
Let’s start with running all the devices HTTP(s) traffic through your HTTP(s) proxy debugger tool so that you can make all the necessary checks and edits.
For this, you might need to install some certificates to be able to intercept the calls and edit them. The device might warn you that someone might be checking out your network traffic – this is because similar to the Man in the Middle penetration testing process. If you see that all calls are rejected due to SSL, it means you forgot to install the certificate or the certificate is invalid.
If the HTTP(s) response and requests look like gibberish (“!P&«`ÝÅÔb¬½wø%ù”), it means you are not decrypting your HTTP(s) traffic, so you need to enable decryption. As you see, there might be some hassle with setting the HTTP(s) proxy debugger up and the more security features there are, the harder it is to test.
If after all this you see the requests and the responses, then let the fun begin. Now, the documents should come out, as you will need to know what the Request URL should look like, what the required Authentication key is and what headers are needed – these are all checked when the request is made.
The reason for this is that you can get one response if the correct header is present and a completely different response if the header is missing or has a typo in it, situation that leads to crashes, a freeze or a badly displayed data and a bad user experience.
Let’s say that the request is made correctly – now it’s the API’s time to respond to your request. It can respond in different ways, with a body or without one. If the request was a “Get” method, it should respond with a body formatted in the agreed markup language (XML, JSON). We will circle back to the received response a little later. When it responds without a body, you need to check if the agreed response codes list is handled within the app. Check that the app handles correctly the most common response codes:
Your agreed response code list can be much shorter, but you should check the codes as the app could crash if other response codes are sent. Imagine if at the start of the application, a request for data is made and the API responds with 500 internal server error and the app crashes – that just rendered the whole app unusable until the response code changes.
Let’s say that the API sent a response body in XML. In this case, you should test if the app behaves correctly when one of the keys returns Null, or the key is missing and if the app is expecting XML but receives a JSON. Let’s not forget that the data returned by the API is written by people, and people are prone to making mistakes.
It is also good to check if the app handles long strings correctly, as people don’t count the number of characters they enter and validation is not always done via the API. Let’s say your app has a screen where you need to display a long text, such as a description of an item or the lyrics of a song. And maybe someone added Shakespeare’s poems as the desired text instead of the actual text. How will the app handle it? Will it crash, will it display the whole text, will it truncate the text? You should also check to see what happens if the API does not respond – does the app hang waiting for the response, does it time out, does it crash when it tries to time out?
It is easy to overlook this, as in the test environment the API responds in time but in production you don’t have any guaranty that the user’s internet connection will not fail after the request is made or that you suddenly have so many clients that the server limps from time to time.
Most of the times, the developers handle these issues, but from time to time or after a refactoring, some fail-safes are removed or deemed unnecessary. And when these issues happen in production, it isn’t the best feeling knowing you could have checked them in 10 minutes or less but you didn’t.
Another overlooked aspect you should also test is caching. There are some libraries that cache the data and automatically present it if they receive the header from the API. For example, “Cache-control: max-age=31536000” will cache the response for 1 year, which might not be such a good idea if you need to change it sooner.
These are just some tips and important aspects I have noticed and gathered over the years while doing web services testing. It is always better to test for common human mistakes than to make a data update and receive complaints that the app is not working.