UNIT - V

Testing Android Applications-Best Practices in Testing Mobile Applications,

➢ Designing a Mobile Application Defect-Tracking System,
➢ Managing the Testing Environment,
➢ Leveraging Android SDK Tools for Android Application Testing,
Android Application Testing Essentials-
Unit Testing with Junit,
Introducing the PasswordMatcher Application,
Determining What Our Tests Should Prove,
Creating an Android Test Project,
Writing the Tests,
Running Your First Test Using the Android IDE,
Analyzing the Test Results
Publishing Your Android Application:
Choosing the Right Distribution Model-Protecting Your Intellectual Property,
Following the Policies of Google Play,
Packaging Your Application for Publication-Preparing Your Code for Packaging,
Packing and Signing Your Application,
Publishing to Google Play - Signing Up for Publishing to Google Play, Uploading Your Application
to Google Play, Publishing Your Application to Google Play.
Best Practices in Testing Mobile Applications
• Like all QA processes, mobile development projects benefit from a
well-designed defect tracking system, regularly scheduled builds,
and planned, systematic testing
• There are also plentiful opportunities for white-box and black-box
testing as well as opportunities for automation.
➢ 1. Designing a Mobile Application Defect-Tracking System
• You can customize most defect-tracking systems to work for the testing of mobile
applications.
• The defect-tracking system must encompass tracking of issues for specific device defects
and problems related to any centralized application servers
1.1 Logging Important Defect Information
• A good mobile defect-tracking system includes the following information about a typical
device defect:
• Application build version information, language, and so on
• Device configuration and state information, including device type, Android platform version,
and important specs
• Screen orientation, network state, sensor information
• Steps to reproduce the problem using specific details about exactly which input methods
were used (touch versus click)
• Device screenshots that can be taken using DDMS or the Hierarchy Viewer tool provided
with the Android SDK
1.2 Redefining the Term Defect for Mobile Applications
• Defects might occur on all devices or on only some devices.
• Defects might also occur in other parts of the application environment, such as on a remote
application server
• Some types of defects typical of mobile applications include the following:
• Crashing, unexpected terminations, forced closures, app not responding (ANR) events, and
various other terms used for unexpected behavior that result in the application no longer
running or responding.
• Features not functioning correctly (improper implementation)
• Using too much disk space on the device
• Inadequate input validation (typically, “button mashing”)
• State management problems (startup, shutdown, suspend, resume, power off )
• Responsiveness problems (slow startup, shutdown, suspend, resume)
➢ 2. Managing the Testing Environment
• Testing mobile applications poses a unique challenge to the QA team, especially in terms of
configuration management.
• The difficulty of such testing is often underestimated. Don’t make the mistake of thinking that
mobile applications are easier to test because they have fewer features than desktop
applications and are, therefore, simpler to validate.
• The difficulty of such testing is often underestimated. Don’t make the mistake of thinking that
mobile applications are easier to test because they have fewer features than desktop
applications and are, therefore, simpler to validate.
2.1 Managing Device Configurations
• Device fragmentation is one of the biggest challenges the mobile tester faces.
• Android devices come in various form factors with different screens, platform versions, and
underlying hardware.
• QA personnel must have a detailed understanding of the functionality of each target device,
including familiarity with what features are available and any device-specific idiosyncrasies
that exist

• Whenever possible, testers should test each device as it is used in the field, which might not
be the device’s default configuration or language. This means changing input modes, screen
orientations, and locale settings.

• It also means testing with battery power, not just plugging the device into a power source
while sitting at a desk.

• One hundred percent testing coverage is impossible, so QA must develop priorities

thoughtfully.
• Learning the Android Software Development Process,” developing a device database can
greatly reduce the confusion of mobile configuration management, help determine testing
priorities, and keep track of physical hardware available for testing .
• Using AVD configurations, the emulator is also an effective tool for extending coverage to
simulate devices and situations that would not be covered otherwise.

2.2 Determining Clean Starting State on a Device

• There is currently no good way to “image” a device so that you can return to the same starting
state again and again.
• The QA testing team needs to define what a “clean” device is for the purposes of test cases
• This can involve a specific uninstall process, some manual cleanup, or sometimes a factory
reset.
• While we’re on the topic of “clean” states, here is another issue to consider. You may have
heard that you can “root” most Android devices, allowing access to underlying device features
not openly accessible through the public Android SDK
2.3 Mimicking Real-World Activities
• It is nearly impossible (and certainly not cost-effective for most companies) to set up a
complete isolated environment for mobile application testing.
• It’s fairly common for networked applications to be tested against test (mock) application
servers and then go “live” on production servers with similar configurations.

2.4 Maximizing Testing Coverage

• All test teams strive for 100% testing coverage, but most also realize such a goal is not
reasonable or cost-effective.
• Testers must do their best to cover a wide range of scenarios, the depth and breadth of which
can be daunting—especially for those new to mobile.
2.4.1 Validating Builds and Designing Smoke Tests
2.5 Automating Testing
2.5.1 Testing on the Emulator versus the Device
2.5.2 Testing Before Devices Are Available Using the Emulator
2.5.3 Understanding the Dangers of Relying on the Emulator
2.6 Testing Strategies: Black- and White-Box Testing
2.6.1 Testing Mobile Application Servers and Services
2.6.2 Testing Application Visual Appeal and Usability
2.7 Leveraging Third-Party Standards for Android Testing

2.8 Handling Specialized Test Scenarios

2.8.1 Testing Application Integration Points

2.8.2 Testing Application Upgrades
2.8.3 Testing Device Upgrades
2.8.4 Testing Product Internationalization
2.9 Testing for Conformance
Installation Testing
Backup Testing
Performance Testing
Testing In-App Billing
Testing for the Unexpected
Testing to Increase Your Chances of Being a “Killer App”