Mobile Application Developmnet and Testing Workshop - 19th Sep 2015 Colombo Sri Lanka

What is Duplicate Content and How to Test Duplicate Content Effectively

 On the web, clients and servers perform every interaction by passing HTTP Messages between them. To download a resource from a server, a client initiates a client/server transaction by sending the server an HTTP Request Message. The header of an HTTP Request Message contains details associated with the request. In response, the server packages the requested and sends it to the client as HTTP Response Message. This round-trip exchange constitutes one Request/Response transaction. The entire conversation usually last several minutes, and is referred to as a Session.

 What is Duplicate Content?

In simple duplicate content is requesting and receiving same set of data form your back-end systems as resonance message. Each time a client requests content from a server, the server returns it as an HTTP Response Message.

Imagine saving Response as they arrive from the server. By the end of the session, you would end up with a collection of Response Entities. If you checked this collection for duplicates, that is, for Entities that contain the exact same content you would probably find some, perhaps many.
Since every content request results in a Full Response from the server, eliminating the Full Responses that result in duplicate content also eliminates the associated overhead for the Full Response, which includes:

• The time it takes for the Request Message to reach the server, for the server to fill the request, and for the Response Message to return to the client.
• The wireless bandwidth consumption.
• The Battery drain from using radio resources.

Eliminating duplicate content provides benefits to an individual user, such as:

• Improved application responsiveness.
• Longer lasting battery charge.
• Reduced impact on the user's data plan.

It also provides benefits to all users by improving throughput due to the cumulative effects of the reduction in bandwidth usage, and the reduction in processing overhead on the web server.

What is the solution for Duplicate Content?

This problem can be solved by incorporating a caching strategy into your client application design. The cache is a process operates as a middle-man standing in between the client and server processes. The cache serves locally-stored copies of Response, so you can refer to it as a Response Cache.

There are several ways to implement caching. There are libraries available for this, and some operating systems have functions for it, but the most direct approach is to incorporate Response Entity Cache functionality into your client software code. Caching is important to your application for the following reasons:

• Cached files are available immediately, with no download latency. This makes your application appear faster.
• Battery life. Every data connection drains the device's battery. If battery draining appears too excessive, the application may be uninstalled by the user.
• Data caps. Users have monthly data caps, and resending files over and over can result in additional costs to your customers if they exceed their monthly data allowance and incur overage charges.
• Citizenship: Wireless networks have limited capacity. If you clog the network with extra data, it hurts the responsiveness of all applications (as well as phone calls).

 How to test Duplicate Content?

Testing for Duplicate Content is simple and does not require much technical expertise. There are several tools available and they can help you to find Duplicate Content and its implications. I will     show you how to test Duplicate Content using AT&T ARO.

Following test scenario I used to find how effectively my AUT is using caching strategy. So I check for my AUT is programed to cache or retain frequently used downloadable content such as Images, Audio, and XML. An application should not download more than 3 duplicate items as displayed in the Caching: Duplicate Content test in the ARO Data Analyzer help you to find following

• Caching is present but is not being utilized correctly.
• ETags in HTTP headers not being utilized correctly.
• Cache headers not established. See Cache Control Test ID 1.2.
• HTTP expiration model not being utilized. See Content Expiration Test ID 1.3.

 Test Steps: This test can be tested as part of an Active User ARO test

1.  From the ARO Data Collector, open task killer and kill all tasks.
2.  Hide Collector and Launch the app under test.
3.  Utilize the app under test for 20 minutes. Navigate through the application at a pace that would emulate a real user. Cover all the states that are applicable to the app including:
• Moving back and forth between multiple screens within the application
• GPS State
• Bluetooth State
• Screen Rotation
• Intentionally navigate back through the application to a screen that has been visited previously in the trace.
4.  Stop trace in the ARO Data Collector
5.  Transfer the trace to the ARO Data Analyzer

  Pass / failure Threshold:

Pass	Not the most efficient result possible, but unlikely to cause significant user dissatisfaction	Definitely inefficient, likely to cause effect that will be noticed by the user in terms of network delay, battery usage or data consumption	Extremely inefficient, likely to have unacceptable user impact in terms of network delay, battery usage or data consumption
ARO Green icon	The lesser of5% of total content or 0.5 MB of data	The lesser of 5% - 20% of total content or between 0.5 MB – 2.0 MB of data	More than 20% of total content or more than 2.0 MB of data

Minimizing Mobile Application Energy Consumption with Cloud Offloading Concept.

Lots of people in mobile testing talks about monitoring mobile energy consumption and related defects. I am also a person who keen on reducing mobile energy consumption. However during my past experience, whenever we raise a defect on energy consumption people don’t take them serious. They always say this is a job of a mobile device and OS should manage energy not our app/AUT.

Recently I found a white paper from Young-Woo Kwon and Eli Tilevich who discussing a concept call Cloud Offloading witch actually focusing on reducing mobile application energy consumption and allow mobile application user to be mobile more time by reducing recharging frequency  I will point following key highlights of this paper in order to increase your interest and you may download the paper from  www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB0QFjAAahUKEwjzvKjG_ejGAhVQ1I4KHT1HCpY&url=http%3A%2F%2Fpeople.cs.vt.edu%2Ftilevich%2Fpapers%2Ficsm2013.pdf&ei=pYesVbPWEtCouwS9jqmwCQ&usg=AFQjCNG-0olac3mfTIju7kq1YFwSE963nA&sig2=LOzJAuqhaZ9DcJSq3hD91g&bvm=bv.98197061,d.c2E 

What is cloud offloading

“Cloud offloading, this optimization partitions mobile applications, so that their energy intensive functionality is executed in the cloud, without draining the battery”

Problem Definition

After discovering that the network conditions in place can significantly affect how much energy is spent to transfer the same data, we have created guidelines for mobile application designers to transmit data in a fashion that consumes the least amount of energy for a given mobile network. Because transferring the same data over WiFi, 3G, or 4G networks consumes different amounts of energy, an optimal offloading mechanism should be adaptive, transferring varying amounts of state depending on the network conditions in place.

Figure 1 shows an Cloud Offloading Energy Consumption Graph (CO-ECG), a novel program analysis data structure that we introduced to model how much energy will be consumed under different offloading scenarios.

In this particular CO-ECG, component A consumes approximately 100 joules during a typical execution, thus becoming a viable candidate to be offloaded to the cloud. Because component A calls components C and B, which in turn calls components D and E, its energy consumption is the sum of the energy consumed by all the successor components in the graph. We assume that the energy spent on executing the offloaded functionality in the cloud is free, as it does not exhaust any battery power of the mobile device. If component A is offloaded, then transmitting the necessary data to it across the network enabling it to execute remotely would consume between 30 and 150 joules depending on the type of the

network available to transmit the data. In other words, under some network conditions, offloaded execution will end up using more energy than executing component A on the mobile device. Because the type of network available is only known at runtime, the offloading decisions must be dynamic to be able to optimize the amount of consumed energy under all runtime conditions.

Approach Overview

Figure 2 shows the workflow of AMCO. The approach consists of two major parts—a program analysis-guided partitioning transformation and an adaptive runtime system. The AMCO programming model is straightforward: the programmer marks the components suspected of being energy hotspots. In AMCO, components can be defined at any level of program granularity, with the smallest being individual methods and the largest a collection of packages. To mark hotspot components, AMCO provides a special Java annotation @ OffloadingCandidate; this information can also be specified through an XML configuration file. Based on this input, an analysis engine first checks whether the specified component  can be offloaded as well as any of its subcomponents (i.e., successors in the call graph).

Mobile Application Testing Checklist

Introduction

Following are some of the checklists that I have been using for mobile application testing. These check lists might help you to understand your test coverage and it will help you to calculate the accuracy of your mobile application test.

Said checklists are specifically designed to test the characteristics of a mobile app. it tests only generic app characteristics and not the functionality of the app. Separate test approach and test script must be created in order to test the application functionality. The same goes for performance testing, usability testing, security testing and other testing activities.

The checklist is split into following five different fields:

1. Device specific characteristics. These are characteristics that are related to the device on which the app is installed.
2. Network specific checks
3. App checks. These are things to check that have to do with functionality that is frequently used in an app.
4. App User interface checks.
5. Store specific checks.

Device specific checks

#	Description
1.1	Can the app be installed on the device?
1.2	Does the app behave as designed/desired if there is an incoming call?
1.3	Does the app behave as designed/desired if there is an incoming SMS?
1.4	Does the app behave as designed/desired if the charger is connected?
1.5	Does the app behave as designed/desired if the charger is disconnected?
1.6	Does the app behave as designed/desired if the device goes to sleeping mode
1.7	Does the app behave as designed/desired if the device resumes from sleeping mode
1.8	Does the app behave as designed/desired if the device resumes from lock screen?
1.9	Does the app behave as designed/desired if the device is tilted?
1.10	Does the app behave as designed/desired if the device is shaken?
1.11	Does the app behave as designed/desired if a local message is coming from another app (think of: calendar reminders, to-do task etc.).
1.12	Does the app behave as designed/desired if a push message is coming from another app (think of: twitter mentions, whatsapp message, wordfeud invitation, etc).
1.13	Does the app interact with the GPS sensor correctly (switch on/off, retrieve GPS data)?
1.14	Is the functionality of all the buttons or keys on the device defined for this app?
1.15	Verify that buttons or keys which have no defined function have no unexpected behaviour on the app when activating.
1.16	In case there’s a true “back” button available on the device does the “back” button take the user to the previous screen?
1.17	In case there’s a true “menu” button available on the device, does the menu button show the app’s menu?
1.18	In case there’s a true “home” button available on the device, does the home button get the user back to the home screen of the device?
1.19	In case there’s a true “search” button available on the device, does this get the user to some form of search within the app?
1.20	Does the app behave as designed/desired if the “Battery low” message is pushed
1.21	Does the app behave as designed/desired if the sound on the device is turned off?
1.22	Does the app behave as designed/desired if the device is in airplane mode?
1.23	Can the app be de-installed from the device?
1.24	Does the application function as expected after re-installation?
1.25	Can the app be found in the app store? (Check after go-live)
1.26	Can the app switch to different apps on the device through multitasking as designed/desired?
1.27	Are all touch screen positions (buttons) working when a screen protector is used.

  

Network specific Checks

#	Description
2.1         #	Does the app behave according to specification if connected to the internet through Wi-Fi?
2.2	Does the app behave according to specification if connected to the internet through 3G?
2.3	Does the app behave according to specification if connected to the internet through 2G?
2.4	Does the app behave according to specification of the app is out of network reach?
2.5	Does the app resume working when it gets back into network reach from outside reach of the network?
2.6	Update transactions are processed correctly after re-establishing connection.
2.7	Does the app still work correctly when tethering or otherwise connected to another device
2.8	What happens if the app switches between networks (Wi-Fi, 3G, 2G)
2.9	Does the app use standard network ports (Mail: 25, 143, 465, 993 or 995 HTTP: 80 or 443 SFTP: 22) to connect to remote services, as some providers block certain ports.

 App specific Checks

#	Description
3.1	Has the app been tested on different type of devices and different versions of OS?
3.2	Stability check: if the app has a list (for instance of pictures) in it, try scrolling through it at high speed.
3.3	Stability check: if the app has a list (for instance of pictures) in it, try scrolling to before the first picture or behind the last picture.
3.4	Is downloading of the app prevented in case it’s bigger than the OS allows downloading when connected to cellular networks.
3.5	Integration: does the app connect correctly to the different social networks (LinkedIn, twitter, facebook, etc).
3.6	The app does not interfere with other apps when in background/multitasking mode (using GPS, playing music, etc.).
3.7	Can the user print from the app (if applicable)
3.8	The search option in the app displays relevant results
3.9	Verify most common gestures used to control the app.
3.10	What happens if you select different options at the same time (undesired multitouch, for example – select two contacts from the phone book at the same time).
3.11	App name should be self explanatory
3.12	Does the app limit or clean the amount of cached data.
3.13	Reloading of data from remote service has been properly designed to prevent performance issues at server-side. (manual reloading of data can reduce the amount of server calls)
3.14	Does the app go to sleep mode when running in the background (prevent battery drain)

 User interface checks

#	Description
4.1	To keep controls as unobtrusive as possible for instance by fading them out if they are not used for a while.
4.1	Make it possible for users to go back to a previous screen for instance by adding a back or cancel button
4.2	The main function of the app should be apparent immediately. It should speak for itself.
4.3	Use at most one action on the screen that is highlighted as the most likely for the user. (Example: in iOS a blue button represents the default or most likely action).
4.4	Minimize user actions by using a picker or a table view where users can select a certain choice over a data entry field where users have to type a choice
4.5	In an app, the user should not be able to store files locally, outside the app sandbox.
4.6	In an app, the user should not be exposed to the permissions of a specific file
4.7	If there is a long list of data to scroll trough, provide a search option above the list.
4.8	If performance is slow, indicate a progress status icon (“Loading…”), preferably with specific message.
4.9	In case of ‘live’ filtering of data while the user enters his search query, verify the performance.
4.10	The appearance of buttons that perform standard actions are not altered in the app (for instance: refresh, organize, trash, Reply, back, etc.)
4.11	Do not use standard buttons for other functions then that they are normally used for
4.12	The app should respond to all changes in device orientation, as per the design
4.13	Tapable elements should be about 7x7 mm in size, using the pixel density of the target device you can calculate the amount of pixels (chapter documentation contains a link to different devices compared).
4.14	Do not redefine gestures in your app that have a standard meaning (example: swiping from top to bottom enables the notification center)
4.15	Requirement to login is delayed in the app as long as possible
4.16	If the app is stopped at an unexpected time, user data should be saved locally and available at start-up.
4.17	Users should be warned of the consequences of deleting a document
4.18	Keyboard adjusts to expected input (for instance numbers/letters when expected).
4.19	Are inactive buttons clearly distinguished from active buttons?

 Store specific Checks

#	Description
5.1	The app can’t use any “non-public API’s”. This means that you can’t use some functions that the distributing platform uses for its own apps.  (This can generally be checked best by some sort of automated tool, like http://www.chimpstudios.com/appscanner/)
5.2	The app can’t reprogram controls of the device that are not intended for that use. (For instance: using the volume button as a shutter for the camera).
5.3	The app should not access information on the device outside the app without the user’s permission (for instance, copying the address book or getting information from other apps).
5.4	The app should not access or write files outside the “Bundle” and “Documents” directory. (because the app can’t read or write data outside the designated container area).
5.5	The app cannot download code to be installed without the users consent.
5.6	The app can only get new functionality by way of an upgrade through the app store.
5.7	After download, an app should remain working. An app cannot turn off after a few days.
5.8	An app can’t be a “trail”, “beta”, “demo” or “test” version.
5.9	Apple product names should be spelled correctly in the app. (For instance: IPhonez is wrong).
5.10	If the app uses the web, it is not done using third party (i.e. non-Apple) browsers.
5.11	You cannot mention other app platforms in your app (for instance: “Also available on android!”)
5.12	An app cannot use old interfaces, like for instance the iPod click wheel.
5.13	Multitasking functionality of the app can only be used for its intended purposes, i.e. VoIP, Audio playback, location, task completion, local notifications, etc. This means that generally an app can’t run in the background but has to be closed off if it’s not used any more.
5.14	The app must have some functionality. For instance, it can’t be just a title page leading to some text.  It can’t be just a song, movie or book as there are different platforms for that.
5.15	Functionality should be in sync with functionality described in store.
5.16	In general, the app has to be decent. So no explicit material in the sense of sex, violence, drugs, alcohol or tobacco. It cannot address a specific ethnic or religious group in a derogatory way.
5.17	The app has to be honest. This means that the description of the app has to be correct, and all functionality has to work as described. If an app gives diagnostic information, it has to be reliable. This also means that the genre and category in the description must be appropriate. The app icons should be consistent and appropriate.
5.18	An app can’t restrict the users of the app for instance by location or carrier.
5.19	An app cannot send spam or introduce viruses, or use other apple platforms like Game Center and Push Notifications to do so.
5.20	The app should aim at backing up a minimum of information on iCloud. The information in iCloud should be just the user generated information. Information that can be recreated or downloaded should not be backed up.
5.21	An app cannot use location services of the device without asking permission.
5.22	All url’s in the app code should be fully functional
5.23	The app can’t use the user’s location without permission.
5.24	The location services cannot be used to autonomously control of vehicles or for emergency services.
5.25	An app cannot use push notifications without user consent.
5.26	Push notifications have to be send using the Apple Push Notification (APN) API. This has to be done using an APN ID.
5.27	Push notification can’t send personal information.
5.28	The App may not distribute any private information of users (like Player ID) through the game center.
5.29	Ad banners must be hidden when there are no ads available.
5.30	The app must respect copyright of apple and other parties.
5.31	The in app purchase mechanism cannot be used to purchase goods and services used outside the app.
5.32	The in app purchase mechanism cannot be used to collect money for charities. This has to be done through SMS.
5.33	The in app purchase mechanism cannot be used to buy a raffle or lottery ticket directly from the app.
5.34	Apps that encourage the users to use the device in a way that may damage the device will be rejected
5.35	An app cannot require user’s personal information (for instance email address) in order for it to function.

Reference

Apple App store review guidelines:

https://developer.apple.com/appstore/resources/approval/guidelines.html

iOS Data storage guidelines

https://developer.apple.com/icloud/documentation/data-storage/

Apple Human interface guidelines:

https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html

http://www.mobileappstesting.com/tag/testing-checklist-for-mobile-application/