Learn how you can benefit from testing your mobile app with real devices in the cloud, and how to ensure compatibility across devices, while avoiding visual and functional regressions.
Workshop: An Introduction to API Automation with Javascript
Testdroid: Release Perfect Apps with Mobile Visual Testing in the Cloud
1.
2. Public Device Cloud
on-demand devices
(multitenant)
Hosted by Bitbar
Mobile app testing
on literally any real
Android and iOS
devices
Private / Reserved
Device Cloud
Hosted by Bitbar in
the US and/or Europe
Devices chosen by
and reserved only for
the Customer
On-Premise
Device Cloud
Automated mobile app
testing devices hosted
by the customer,
usually 30-500 devices
Testdroid – 3 Deployment Options
Testdroid Cloud Testdroid Enterprise Testdroid PrivateCloud
3.
4. The Value of ‘Cloud Testing’
• Devices / Hardware
- No need to handle shipping, logistics, handling of new
devices and other new HW used in the infrastructure monthly
• Infrastructure
- Ready-to-Go infrastructure means no need for investments,
significantly speeds things up & saves time and money
• Support
- SW devs, SW devs in test (SDET), QA engineers – all need
different type of support when using the infrastructure
• Operations
- Updating infrastructure, devices, networks, additional SW
• Tools Integration
- Support for multiple test tools gives the users/developers
freedom of choice. No vendor, tech, tools lock-ins!
10. Why Real Devices Are Must-to-Have
• Emulators cannot help you to test...
• User Experience
• Usability
• Hardware
• Software
• Infrastructure
0 % = the percentage of your app users
that use emulator to run your app!
11. Top 5 Pain Points
Fragmentation
Diversity of mobile platforms creates unique challenges for mobile
app, game and web devs.
Low Quality Apps Lose Money
Users uninstall and abandon apps/services if the apps do not work.
Manual Testing on Real Devices
Expensive, slow and error-prone process
Device Acquisition
Acquiring devices for devand testing can be expensive and
practically impossible
Inefficiencies
Distributed Teams, duplications of HW resources, app diversity,
fragmented tool support.
13. Manual vs. Automation
Smaller coverage, More
money burnt & time
wasted, Error-prone
Manual Automation
Large
coverage,
quickly
completed,
Less money &
time wasted,
Exact results.
14. Test Automation Frameworks
Robotium uiautomator Espresso Appium Calabash
Android Yes Yes Yes Yes Yes
iOS No No No Yes Yes
Mobile web Yes
(Android)
Limited to x.y
clicks
No Yes
(Android &
iOS)
Yes
(Android)
Scripting
Language
Java Java Java Almost any Ruby
Test creation
tools
Testdroid
Recorder
UI Automator
viewer
Hierarchy
Viewer
Appium.app CLI
Supported
API levels
All 16 => 8, 10, 15- All All
Community Contributors Google Google Active Pretty quiet
22. Client Side Execution
Add Testdroid Desired
Caps to test script
{
“testdroid_username”: “user@domain.com”,
“testdroid_password”: “p4s$w0rd”,
“testdroid_project”: “My First Project”,
“testdroid_testrun”: “Test 1”,
“testdroid_device”: “iPad Mini 7.0.4 A1432”,
“testdroid_app”: “http://domain.com/app_v1.ipa”
.
.
“app”: “com.bitbar.testdroid.BitbarIOSSample”
}
Get a
Device Name
Go to
cloud.testdroid.com
23. Client Side Execution
driver = webdriver.Remote("http://appium.testdroid.com/wd/hub", desired_caps);
Point the Webdriver to
http://appium.testdroid.com/wd/hub
Add Testdroid Desired
Caps to test script
Get a
Device Name
Go to
cloud.testdroid.com
24. Client Side Execution
Run the Test ScriptGet Results from
Testdroid Cloud
Point the Webdriver to
http://appium.testdroid.com/wd/hub
Add Testdroid Desired
Caps to test script
Get a
Device Name
Go to
cloud.testdroid.com
25. Client Side Execution
Pull the Results from
the Result URL
driver = webdriver.Remote("http://appium.testdroid.com/wd/hub", desired_caps);
Run the Test ScriptGet Results from
Testdroid Cloud
Point the Webdriver to
http://appium.testdroid.com/wd/hub
Add Testdroid Desired
Caps to test script
Get a
Device Name
Go to
cloud.testdroid.com