Tablet Apps Testing - Capitalizing on Mobile QA Challenges - PowerPoint PPT Presentation

slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Tablet Apps Testing - Capitalizing on Mobile QA Challenges PowerPoint Presentation
Download Presentation
Tablet Apps Testing - Capitalizing on Mobile QA Challenges

play fullscreen
1 / 18
Tablet Apps Testing - Capitalizing on Mobile QA Challenges
Download Presentation
Download Presentation

Tablet Apps Testing - Capitalizing on Mobile QA Challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Tablet Apps Testing - Capitalizing on Mobile QA Challenges Kiran Marri – Delivery Manager Janaki Sirisha Satthiraju – Technical Test Lead Sundaresasubramanian Gomathi Vallabhan – Senior Project Manager Infosys Limited (NASDAQ: INFY)
  2. Abstract We are moving away from the business of ears to the business of eyes and the trend is relatively clear: Cell Phones, PDA’s, Smartphones and now? - The 'Tablets'. In order to reap the benefits of innovation, many companies have started creating and releasing thousands of Tablet applications into the market. Books were mankind’s' best pals - then came computers, laptops, smartphones and then tablets - more than just a friend but playing the role of a philosopher, guide, entertainer, banker, co-gossiper, fellow-gamer depending on the applications and websites you've subscribed to
  3. Advent of tablets in industry today Retail Online shipping Point of sale data Inventory data access Merchandise tracking Financial Mobile banking Enterprise solutions Mobile payments Secure transactions Manufacturing Floor Operations Real time data Real Time control Health Care Point of sale solutions Wellness management Integrated disease- -Management solutions Enterprise Mobility Bring your own device Mobile device management Energy & Utilities Work Management Outage Management Field Management Remote Meter Reading Sales & Distribution Mobile access to sales Mobile inventory Online Customer data Point of sales
  4. Tablets are here to stay… Industry analyst firm “Yankee Group” has predicted that tablet sales is expected to reach 250 million units worldwide by 2015. Given below is a quick graph to show Apple iPadsales over the years1 Majority of workforce today is planning to go to tablet form of devices in next 3 years for accessing content & information, 24x7 connectivity, and improve productivity on the go…
  5. Popular tablets in the market…
  6. Why this Paper? This paper addresses the practical challenges faced by Mobile QA teams during Tablet Apps testing, proven solutions, learning’s and Best practices to launch ‘top quality’ apps. Going beyond this concept, readers can benefit from understanding various real time scenarios supported by appropriate examples/case studies out of which, couple is outlined below: Apps developed for Smartphones but used on Tablets, and vice-versa Usability issues on apps designed for Tablets vs. Smartphones
  7. Smartphones Vs Tablets
  8. Tablet Ecosystem & Types of testing
  9. Tablet QA Challenges
  10. Case Study 1 : News-paper effect Figure: Web page developed for Tablet (Left) Vs page developed for smartphone (Right) Screen design has been optimized for large screen (iPAD) Vs small screen (Blackberry) Written and image content has appropriately been condensed according to screen area Title has been left justified in the smaller screen to accommodate the photo
  11. Case Study 2 : Orientation Tablets are designed for dual orientation ie., both horizontal and vertical (Portrait/Landscape). Given below are some of the validation points while checking dual orientation: If the application is by default designed for landscape mode of display, irrespective of the orientation of the tablet while opening, the application should always open in the landscape mode. This leads user to adjust the orientation automatically. Virtual keyboard appearing in the screen should also orient itself to portrait or landscape mode based on tablet’s orientation. Keyboard should adjust its size to occupy portrait or landscape orientation and occupy the entire width of the tablet. All tabs and menus appearing on the application screen should occupy the width of the tablet regardless of orientation. Stretched or truncated menu will give rise to bad user experience.
  12. Case Study 3 : Split-View & Pop-over Split view and popover are features introduced in the tablet to minimize the number of screens traversed, thus keeping the response time minimal. Some of the typical validation points to cover these features are: Ensure that in case of split screen, the list appears on the left hand side and the information about a particular item in the list appears on the right hand side. If the user traverses from one item to another, ensure that the information also transitions accordingly . In case of a pop-over, ensure that the pop-over changes according to selection of menu keys on the top of the screen. If the pop-over involves character inputs, then the virtual keyboard should appear automatically on selecting a text input field and should disappear in a non-input field. Split View Pop-over 
  13. Case Study 4 : Enterprise Mobility & Bring your own devices In order to regularize the cost of infrastructure and encourage employees to use their personal devices for Enterprise application access, Bring Your Own Device policy has been implemented in most of the organizations. Most of the employees use “Tablet” (read: iPAD) as part of BYOD. Validation of IT policy enforcement on these devices and ensure their correct functionality. For example, employees cannot access P2P file sharing applications while connecting to enterprise network through their devices. Validation of remote wipe – If the device is lost (or) compromised, IT team effects a remote-wipe feature to wipe out data in the target device. Performance monitoring and response time verification for enterprise applications while connected through BYOD. Since the request goes through multiple hops (may be through virtual desktop interface or to a web server), the performance shouldn’t be too slow to hamper the operational activities while performed through own devices. Data synchronization check & reconciliation of data between Desktop and tablet.
  14. Summary of practical usability challenges in a tablet Traversing several screens for task completion User expects data but encounters blank screen Total time spent on a flow is unusually high Bad Response time due to incorrect UI design Application requires lot of gestures/user inputs Improper usage of personal information Lack of error message or incorrect message Clarity of display - font, picture size/orientation Inconsistent application behavior Accuracy issues – not fitting screen, errors etc., Lack of clean/graceful exit during exigencies Application ‘forgets’ local configuration settings Transaction/action cannot be reversed/recalled Lack of appropriate help messages Short cut to home not provided in each screen Application reacts badly to interrupts Complex app leading to low user confidence Navigation steps very difficult to memorize User finds it difficult to adjust to change of device Text/image combination not rendered properly 14
  15. Conclusion – Lessons learned & best practices from tablet testing A clear test strategy should be in place for testing the tablet applications across various operating systems (Galaxy Tab Vs iPAD Vs Playbook), browsers (Safari, IE, Mozilla) etc., Web apps are expected to perform the same across platforms but the subtle variations specific to operating system concept should be captured as part of test strategy – for example Android Version 3.2 and above has a feature to set the download limit for a particular application screen. Measurement of response time – Tablet users expect the response time to be equal to or less than that of the response time while accessing a laptop or desktop application. The expected response time is roughly in the range of 2 seconds 1 Delineating Application performance from Network performance is very critical. Tablet application should be subjected to variable network conditions (delay, jitter, packet loss, data loss, bandwidth constraint etc.,) and ensure that the application performs a graceful exit at the worst case scenario while performing a transaction. Also, the application response when the network switches from 3G to Wi-Fi or vice versa should be tested.
  16. Conclusion – continued… Each operating system will have its own set of UI guidelines and best practices to be followed for developing the application. This should be used as an input while framing user experience test scenarios. Automation tool should be selected based on the client’s requirement and pain points. Few tools in the market would require the device to be rooted (in case of Apple iPAD) and few other tools would require access to the source code for performing image based automation. Legality aspects should be duly verified before proceeding with automation.
  17. Q&A 17
  18. References Engaging the Tablet User: What They Expect From Web Sites – A Tablet user survey by Compuware Apple & Android developer forum Infosys Project Experience. 18