Quantcast
Channel: Bitbar: Enterprise Mobile DevOps and App Testing
Viewing all 187 articles
Browse latest View live

How to Record Videos of Remote Test Automation Runs

$
0
0

Video recording for mobile app testing is a neat feature that provides video as an output from the remote test sessions. When you start a test run on any number of devices and something goes wrong with any of those device runs, it’s a great feature to check what actually happened on that run – by looking at the video.

Video Recording on Any Number of Devices Simultaneously

One of the greatest benefits of mobile test automation is that its users are able to run their test scripts simultaneously on number of real mobile devices. This sort of parallelism brings the efficiency in testing and significantly improves the productivity, and gets things done earlier.

Video recording combined with simultaneous test runs on devices enables even not technical QA team members to check what goes wrong in a test run, without investigating logs or other useful data.

With this new enhancement in Bitbar Public Cloud (Testdroid Cloud) users can record videos of all their test sessions while they use any of supported test automation frameworks: Robotium, Calabash, Appium (both, Server and Client-Side), UIAutomator, Espresso and App Crawler on Android.

So, how to get started? Simply start a test run for your Android application with any set of devices, using any test automation framework, and all sessions will be recorded and maintained in the test run view. After all tests are finalized results will be available and even downloadable for local inspection. Please get in touch with your dedicated customer representative to enable this feature for you.

Video Recording Enabled in Private Cloud and On-Premise

This new improvement is available across all Bitbar Testing product deployment options. Recording a video is now possible if you have a private cloud set up for you – or you use Bitbar On-Premise product in your local environment. And naturally the same feature is available for all Bitbar Public Cloud users with Business account.

Want to know more about these features available with Private Cloud and On-Premise solutions? Get in touch with us and we’ll be happy to tell you more!


The First Mobile DevOps Meetup in London

$
0
0

We’re happy to announce that Bitbar will be sponsoring the first mobile devops meetup in London on the 26th of October 2016. The actual place will be announced later this week as well as the speakers. The event will be an awesome opportunity to catch up and meet with local mobile devops enthusiasts and network with this group of people.

We’ll start around 6:30pm with some snacks and drinks – and of course, networking.

So, who should attend this event? Naturally, if you are interested in mobile app development, devops tools and methods used in agile app development, testing, monitoring or any other aspect of development flow, this event is definitely for you.

screen-shot-2016-10-18-at-10-26-47-am

London Mobile DevOps Meetup

Time: the 26th of October 2016, 6:30pm – 8:30pm
Place: to be announced

Welcome to the first mobile devops meetup in London! The presentations for the event goes as follows:

Talk 1: What is Mobile DevOps and How Is It Different?

Speaker to be announced

This session provides an introduction to Mobile DevOps approach and practices, and compares this modern way of doing things with Agile methods and DevOps practices.

Talk 2: Deconstructing Mobile DevOps Adoption and Practices

Speaker to be announced

This session provides a presentation of different practices while exercising Mobile DevOps. What Mobile DevOps mean for code/build, testing, deployment and monitoring, plus how to use modern agile tools as part of the process.

SCHEDULE

6:30pm – Welcome words and networking among the group
7:00pm – Group announcement
7:05pm – Talk #1 – What is Mobile DevOps and How Is It Different?
7:40pm – Talk #2 – Deconstructing Mobile DevOps Adoption and Practices
8:15pm – Pizza, Beer and more networking!

SPONSOR

This event is sponsored by Bitbar Technologies.

If you are interested to join this meetup, sign up at Meetup.com. In addition, if you are interested to speak in the future events, please get in touch with me at ville-veikko dot helppi at bitbar dot com.

invite attendees to mobile devops meetup

See you in London!

Webinar Recap: Hassle-Free Continuous Integration with Real Device Testing

$
0
0

Thank you all for attending our latest webinar – Hassle-Free Continuous Integration with Real Device Testing. Despite the topic isn’t new to any of us there were plenty of great aspects and insights provided on how to tackle today’s challenges using CI with real device testing.

We’d also like to give special thanks to Nikita Avvakumov from Greenhouse for co-hosting the webinar with us and sharing many insightful opinions on how to avail the cloud-based continuous integration combined with physical Android and iOS devices for the success of mobile app testing.

This webinar will cover:

    • Why cloud-based continuous integration is perfect fit with mobile app testing on real devices
    • How the combination of CI and real device testing moves you to devops
    • What are needed to create a mobile devops process

We’ve prepared the webinar recording for you. If you missed it or want to watch it (again), you can access to the webinar below. Please share it with anyone else who might be interested in it as well.

Watch webinar recording

In addition, you can check out the slidedeck below and share it for internal use.

If you are interested to learn more about CI with real device testing, contact us at sales (at) bitbar (dot) com.

Android Espresso Tutorial for Mobile App Testing

$
0
0

Espresso has been one of the most used test automation framework for Android app testing. We’ve provided support for it with all our solutions since 2013 and it’s time to look how things have evolved and what’s new with Android Espresso testing.

What’s New with Android Espresso

Despite Android Espresso was originally targeted for developers who can build test scripts for their apps, Google recently introduced the Espresso Test Recorder that can be used to quickly and easily create tests for Android apps. People who don’t have background in programming or even building test scripts can use this tool and with the help of it generate automated user interface tests for their apps.

Test scripts generated by Espresso Test Recorder are executable in Android Studio using emulators and real Android devices that are either connected to local development environment or resided on cloud service. The cloud service with rich diversity of different Android devices from all regions, form factors, and different OS versions can be found from Bitbar Public Cloud (Testdroid Cloud).

As Android Espresso aims to improve the productivity and make developers work more efficient, it can also provide very effective improvements in mobile app quality. Tests are easy and quick to build, execution of test scripts is definitely the fastest compared to any other Android test automation framework, and the light-weight API takes care of keeping tests understandable, easy to maintain and tweak.

How to Get Started Quickly with Android Espresso

As said, we’ve provided support since the earliest versions of Android Espresso. Each and every version of Espresso has contributed something new to this framework and made test automation easier on variety of devices simultaneously. If you look for a quick tutorial how to get started with Android Espresso there are webinar, ebook, and several blogs available about it.

how to get started with android espresso

In addition to basic how-to material we’ve provided some tips and tricks of how to make Espresso yet more suitable for mobile app testing and how to use existing code examples for Espresso tests. The thing to remember that Espresso is just regular Java code and anyone mastering Java can quickly get up and running with Android Espresso.

In a nutshell, Android Espresso is not but a light-weight API with three components: viewMatchers, viewActions, and viewAssertations. These components are the building blocks of test scripts. The syntax is as follows:

onView(viewMatcher).perform(viewAction).check(viewAssertation);

The comprehensive cheat sheet for Android Espresso is available on Google Testing site. And here are few examples of Android Espresso use:

// Example of Espresso use: Sign In for Twitter App on Android
onView(withId(getInstrumentation().getTargetContext().getResources()
                .getIdentifier("com.twitter.android:id/sign_in", null, null)))
                .perform(click());

// Example of Espresso use: Input Text in Edit Field
onView(withId(getInstrumentation().getTargetContext().getResources()
                .getIdentifier("com.twitter.android:id/edit", null, null)))
		.perform((typeText("Testing with Espresso is awesome!")));

Now, from where all that speed comes from? Android Espresso has been said (and it’s a fact) to be the fastest mobile test automation framework. Basically, Android Espresso provides an automatic synchronization of tests methods and user interface elements shown on the screen. Let say test script wants to do an interaction on user interface (e.g. button click) but the visual element is not available/shown on the screen, the test script will wait until it is.

android espresso tutorial for app testing

How to Use Espresso Test Recorder

Android Espresso Test Recorder was introduced in Android Studio 2.2 (preview 3) and at the time of writing this blog it’s still in beta mode. However, it seems to work relatively well and generates user interface activities robustly and generates the Java code that is instantly executable. And this tool doesn’t require any installations or configurations to get started.

Just select Run and Record Espresso Test and you’ll be asked to select Deployment Target. Now, we always recommend using real Android devices for testing as it will give you all possible details of how app runs and performs on that device. Naturally, this test can be then deployed easily on other devices and the generated test script is not hardcoded with the hardware details of where test was originally created/generated and tested on.

espresso test running on real device

Once you have done your test, Android Studio will automatically generate the source code and include in your application’s project.

As an example, application has a basic login procedure with username (email) and password credential check. First, I type ‘testdroid’ on username field, give a password of ‘password’ and click ‘Sign in or register’. The application notifies that I didn’t give a proper email address first so I’ll do that and click again ‘Sign in or register’. After this, you simply click Complete Recording and the Java code will be generated for your app. Here is the example:

    public void loginActivityTest() {
        ViewInteraction appCompatAutoCompleteTextView = onView(
                withId(R.id.email));
        appCompatAutoCompleteTextView.perform(scrollTo(), click());

        ViewInteraction appCompatAutoCompleteTextView2 = onView(
                withId(R.id.email));
        appCompatAutoCompleteTextView2.perform(scrollTo(), replaceText("testdroid"), closeSoftKeyboard());

        ViewInteraction appCompatEditText = onView(
                withId(R.id.password));
        appCompatEditText.perform(scrollTo(), replaceText("password"), closeSoftKeyboard());

        ViewInteraction appCompatButton = onView(
                allOf(withId(R.id.email_sign_in_button), withText("Sign in or register"),
                        withParent(allOf(withId(R.id.email_login_form),
                                withParent(withId(R.id.login_form))))));
        appCompatButton.perform(scrollTo(), click());

        ViewInteraction appCompatAutoCompleteTextView3 = onView(
                allOf(withId(R.id.email), withText("testdroid")));
        appCompatAutoCompleteTextView3.perform(scrollTo(), click());

        ViewInteraction appCompatAutoCompleteTextView4 = onView(
                allOf(withId(R.id.email), withText("testdroid")));
        appCompatAutoCompleteTextView4.perform(scrollTo(), replaceText("testdroid@bitbar.com"), closeSoftKeyboard());

        ViewInteraction appCompatButton2 = onView(
                allOf(withId(R.id.email_sign_in_button), withText("Sign in or register"),
                        withParent(allOf(withId(R.id.email_login_form),
                                withParent(withId(R.id.login_form))))));
        appCompatButton2.perform(scrollTo(), click());

    }

Now, to get your application thoroughly tested across different device variants, we recommend using Bitbar Public Cloud to get as compelling test coverage as it is possible.

You basically need both APKs (application and the test) and user account in the service. Just log in and create an “Android” project for your test – and then follow the test run creation wizard.

You’ll be asked to locate application APK and test APK from your local harddisk and select the device group for a test run. After this, there are some advanced configurations available.

NOTE! For Android Espresso test runs you need to add a proper instrumentation runner for your test run:

android.support.test.runner.AndroidJUnitRunner

Add this in ‘Custom test runner’ section, and click Start.

Android Espresso runs tests quickly but as we always make sure the user experience is the best for cloud users, we clean and reboot devices. This typically takes less than a minute and tests will be executed right after.

Move to the result page of a test run and you’ll get all details of that run with logs, screenshots, performance/memory charts – and now also with recorded video of the test session.

video recording in testdroid cloud

One of the most significant benefit of doing this with our device farm is that you are not limited with number of devices you can use for simultaneous test runs. Literally, we have hundreds of unique models that can be all assigned for test sessions and with Espresso test results are quickly ready.

Happy Espresso Testing folks!

Panel Discussion – The Future of Mobile App Development

$
0
0

As in today’s digital world, mobile apps are dominating human being’s daily lives, from banking to eating to traveling. It’s no secret that mobile is taking over web in the foreseeable future and that a mobile app is a must and ideal access point for servicing customers.

With that being said, having or developing a mobile app won’t simply bring you the success for the future. In fact, the fierce competition of mobile apps poses huge challenges to mobile app developers in terms of winning customers.

To prepare the future and break down the opportunities and threats in mobile app development, we will join a panel discussion hosted by our partner – GreenhouseCI at Microsoft Flux in Helsinki, Finland on Oct. 26th. Many interesting topics will be covered as follows.

  • How much of the mobile app development can be automated already today?
  • How does the automation impact the traditional app development?
  • As a part of this transformation, what kind of new roles will emerge in mobile app development?

Together with other experts in mobile landscape, Niko Cankar, Product Manager at Bitbar, will share some insights on how to tackle the difficulties in mobile app development and mobile test automation for today and the future.

Are you interested in this panel? Come and join us if you are around Helsinki. Please sign up here to show your interest.

Niko Cankar from Bitbar - Microsoft Flux

See you at Microsoft Flux.

See You at DroidconUK 2016 in London

$
0
0

Hello everyone,

Droidcon is back to UK this week from Oct. 27-28, 2016. As usual, DroidconUK 2016 is one of the largest annual Android fests in Europe. It is a perfect gateway for Android enthusiasts and market players to explore all the latest Android technologies and updates. Bitbar team will be visiting the event at Business Design Centre in London and meeting experts from international Android community.

If you are also going there, we’ll be happy to see you at the show and shed some light on how our cutting edge Android app dev-testing process have helped our top clients transform their mobility strategy. We’d also like to hear and learn from you on how Android app testing is managed in your team. Send an email to Robert Seege at robert (dot) seege (at) bitbar (dot) com or Jouko Kaasila at jouko (dot) kaasila (at) bitbar (dot) com to schedule a face-to-face meeting.

For anyone who’d like to get an idea of how Android app testing can be improved, you can sign up here. And we’ll be in contact with you as soon as possible.

Hope to see you there and enjoy the event.

The Most Popular Devices Globally for Mobile App Testing

$
0
0

“What devices should we use to test our applications” is a question we get on daily basis from our customers. As we have over 70,000 users from all over the world and from every possible industry sector, there is no simple answer to this question.

The diversity that different application segments require for mobile app testing is enormous and for example game developers tend to use different types of devices for testing when compared to enterprise app developers. The very same applies for users, people who use that app/game on their devices. We’ve included both Android and iOS devices in our data.

Which Mobile Devices and Platforms Should You Test On?

How can a mobile app, game and website developer maximize the coverage and device compatibility across the most relevant devices available out there?

In short, there are significant differences within mobile user segments and not every type of device is used for every app. For instance, in the gaming sector, gambling and casino users use very different devices that high-end 3D gamers. Customers of an app utility company in the energy sector use entirely different device that the users of Pokemon Go, and so on.

There are many ways to create a test device matrix for the mobile app testing: If you already are in the market with your app, you get some relevant statistics from the app store (Apple Store and Google Play). If you are just entering the market, then you do not have that data at hand. Some mobile analytics companies also release device usage data, which can be used to determine what devices to use in your development, QA and testing.

You can also gather sales data, but newer models are never in the top of used devices as they are just entering the market. Typically it takes three to six months to see which devices will gain the popularity and are used for certain types of apps in the market.

Furthermore, if you are using data from mobile analytics company, there can be bias in the data. If the analytics company is mainly serving gaming companies, their metrics is biased towards younger and gaming oriented device users.

The most important questions to answer to get an ideal and comprehensive understanding of device roster are as follows:

  • Where is your target audience? In which countries are your users? This is the first criteria to define device roster for your testing needs as even the device with all specs, and brand name, indicates it being similar with global device variants that’s not the case. There are tons of customizations and different add-ons on certain devices used in certain mobile networks (and devices branded for certain telcos).
  • What are the form factors and types of devices used by end-users? Nowadays, mobile apps runs across variety of different form factors (phones, tablets, wearables, etc.) and in many cases apps are optimized for better user experience in each of these.
  • What is the ‘target OS’ version and what other variants should be supported? Some applications are restricted to work only on the latest OS versions due to used APIs and integrated services. These applications won’t install and work on the older ones and typically users should upgrade their device with some newer OS version to get app working. This is crucial to get the right OS-device combination and make sure application works on these variants.

How Was The Data Collected?

We collected the data from mobile web access. Mobile web usage should be the most unbiased as web is used on every device, among young and old users, low income and high income, globally in every country, social media users, shoppers, news readers, sport fanatics, men and women: they all use mobile web daily. Download the comprehensive mobile device listing for mobile app testing.

Our data is collected from web usage data and is based on global web traffic data from hundreds of thousands of websites based on the user agent information. Based on this you can get your test device matrix in order.

Naturally, it’s easy to say that the comparison of Android and iOS devices is straightforward and most media does the comparison based on Samsung Galaxy and Apple iPhone latest versions. But if you look at some this data provided about the failures, there are lots of differences when it comes to both, Android and iOS devices. Among Android phone vendors, Samsung handsets experienced the highest rate of failures at 43% globally. The Galaxy S6 was the handset that experienced issues most commonly in Samsung’s device roster, while the iPhone 6 experienced the most malfunctions of all of Apple’s smartphones.

Interested in Full Detailed Report with Device Listings?

We have gone through all data and we have break down the data based on countries and what are the most popular device models used. If you need more information, or if you want us to deliver the report to you in Excel format, please contact our sales (sales at bitbar.com) and we’ll be happy the share all data + findings with you. You can also download the report from mobile app testing resources page.

Happy Testing folks!

The State of The Art in iOS 10 Test Automation Frameworks

$
0
0

The iOS 10 has rolled into Apple devices and has already got a significant install base on different Apple devices out there. Historically, the pace has been even faster when it comes to getting the latest and greatest iOS version adopted by 75% of device users. In addition, the iOS 10 adoption hasn’t gone as smoothly as prior ones for those who use it for test automation and are using iOS 10 with their existing test scripts and assets.

In this blog we’ll look at the state of the art with iOS 10 test automation and what mobile app developers should consider when building their infrastructure and using de-facto frameworks for their test automation needs.

What Has Changed in iOS 10?

The recent launch of iOS 10 and its sub versions has caused lots of issues for iOS app developers and especially, iOS test automation. The whole ecosystem of developers and testers have been forced to tweak their platforms, test scripts and infrastructure (plus development tools) to get things running smooth from continuous integration to real device testing.

The MixPanel report on iOS adoption reveals that over 75% of users have already upgraded to the iOS 10 base version or any of its subversions (or beta versions). As said, this hasn’t happened as quickly as we’ve expected to see much faster adoption of iOS versions on users devices.

This ‘slowness’ in adoption also creates fragmentation on iOS and causes applications to behave differently, even on the same device (with the same hardware) but running the different OS version. The only thing app developers can really do is to make sure that app is thoroughly tested on all possible variants, and this is where test automation has its strengths.

MixPanel Report on iOS 10 Adoption

Impact of iOS 10 on Xcode Development Environment

The biggest change in Xcode development environment is the deprecation of UIAutomation. This has had an impact on various defacto open source test automation frameworks, such as Appium and Calabash.

For example, many of iOS test automation frameworks used by mobile app developers are built on top of UIAutomation and as Xcode 8 replaced UIAutomation with Xcode’s new test framework – XCUITest – the old Xcode Instruments based test scripts need to be deprecated.

QUICK TIP! If you running a test script built for prior Xcode versions, all uia_* calls will raise an error with the latest Xcode. How can you tackle this and what are the options to keep your internal test automation process running? We’ll shed some light to the state of the art with iOS 10 test automation in this blog.

The Requirements of iOS 10 for Mobile Test Automation

First of all, it’s always recommended to use real iOS devices (iPhones, iPads etc.) for testing. And with test automation, using Appium, Calabash or simply built-in XCUITest you can quickly and easily build your test scripts to ensure application quality meets the user expectations.

As stated before, UIAutomation has been deprecated from the latest Xcode and if you still use it – or you use some older version of e.g. Appium – there are things that you should be aware of. UIAutomation was supported with Xcode 6.x and 7.x and you won’t have any issues with running iOS 8.x and 9.x installed devices on that environment.

The XCTest is a framework that was introduced back in the Xcode 5 and it’s a modern version of OCUnit. If you are still running OCUnit tests there is a reference guide to walk you through migrating OCUnit tests to XCTest by Apple. However, XCTest can be still used with the latest Xcode 8.x versions.

XCTest serves as a basis for KIF (Keep It Functional) test automation framework which allows an easy creation of test automation scripts for iOS applications. The KIF builds and performs the test scripts using a standard XCTest testing target, and it will work just fine on the latest Xcode 8.

State of the Art with iOS Test Automation

Then, let’s move to the cross-platform frameworks.

Calabash iOS 10 requirements are pretty straightforward and you can find a step-by-step instructions on that blog how to make sure things work fine with any iOS 10 variant. Download our Calabash 101 to learn basics and advanced tips to leverage the power of Calabash for mobile app testing.

A New Way to Use Appium/Selenium with Real Devices on Cloud

Appium, however, do require some attention and test automation functionality depends on a certain version of Xcode and iOS. For example, if you are using older version of Appium (version below 1.6) the framework is supported only with Xcode 6 and Xcode 7. This comes from the UIAutomation dependency and it will only support iOS 8.x and 9.x versions.

In order to get your Appium test scripts (with minimal or no tweaks at all) running on iOS 10.x you need to upgrade to the Xcode 8 – and then your Appium scripts will also work fine on the older iOS versions as well. However, it’s good to prepared to do minor tweaks on your test scripts as iOS versions have evolved and brought some new functionalities and APIs that change how to UI looks and feels for user (or for test automation script).

If you are looking for a recommendation on which iOS devices (with certain iOS version) you should test your app, do check this report and get the comprehensive listing of which Apple devices are used in certain countries:

The Most Popular Devices Globally for Mobile App Testing

Happy iOS Test Automation, Folks!


Using Fastlane for Continuous Delivery of iOS Apps

$
0
0

Continuous *everything* has quickly become one of the most crucial backbones of mobile DevOps workflow. Many of today’s mobile developers use continuous integration to build, test and deploy their apps, games and even web apps. The process is typically scripted and configured so that all steps take place automatically and source code is stored on repository (Github, some local one etc).

In this article, we take a look how mobile continuous delivery and continuous integration works for iOS app development and testing. We’ll also take a look at Fastlane and how mobile devs can get the best out of it.

The Modern Mobile DevOps

The companies with Mobile DevOps approach and culture has adopted various principles that evolve and new tools are brought into process. App development, continuous delivery and integration tools are optimally adopted when automation is used for various phases of the product development: build, testing, deployment and monitoring.

7 process steps for better mobile devops

The modern mobile devops includes 7 different steps that are used across and inside organizations as part of their daily tasks. In this context, it’s highly crucial that tools and methods used are aligned and integrated with the overall goal. And especially when it comes to considering what tools are used, how those fit together and enable seamless tool flow from planning to production.

Test automation is a critical part of the flow and also important for iOS app development as it enables process to be highly iterative, repeatable, and robust. Automation is actually an enabler for continuous everything, in each step of the process.

Fastlane for Continuous Delivery of iOS Apps

As there are plenty of Mobile DevOps tools and all have different use cases and sometimes those tools can be overlapping each other in the overall Mobile DevOps process, we love to experiment and also use different tools and methods here at Bitbar for our internal Mobile DevOps workflow. And frankly, there are many when it comes to using these tools in our internal process and automation. One of those tool that I find handy in terms of iOS automation is Fastlane.

Fastlane for Continuous Delivery of iOS Apps

It is one good optional tool/set of practices to use as part of your iOS app development. It can help in effort to automate your beta deployments/releases for both Android and iOS apps. At least from my point of view, the most significant help that it can offer is in code signing and dealing all tedious things around it.

Fastline provides several interesting and useful components/tools for making the continuous delivery environment smoother for the actual app development and getting all the assets ready for the release.

The features/components in Fastlane that are relevant to continuous delivery are as follows:

  • deliver uploads screenshots of your application, all relevant metadata and required binaries to iTunes Connect. This feature can be used to submit an iOS application to App Store review. Typically, this feature is used when your tests are passed and you have the release version of your app ready.
  • snapshot generates localized iOS screenshots for different device types and languages for the App Store and can be uploaded using deliver.
  • frameit allows its users to place a device fram around the screenshot. This can be done with a single command and it produces highly usable screenshots of the app with the actual device mockcup.
  • sigh can fully manage all aspects of provisioning profiles. Using one command user can create, renew, and fix provisioning profiles. It supports store releases, Ad-Hoc, Development and Enterprise profiles.
  • produce set a created iOS app on Developer Portal and/or iTunes Connect.
  • cert is a dedicated feature for code signing. With ‘cert’ users can quickly create code signing identities for development or release distribution. ‘cert’ also allows use of local certificates (if user has installed any).
  • scan makes it easier to run iOS tests on Xcode simulator or any connected devices on your local environment.
  • gym builds and packages an iOS app. With ‘gym’ it is easy to generate a signed .ipa file and push that for real device testing.

Let’s look at few examples. First, using ‘gym’ user can quickly build and package app for tests. Before the ‘gym’ is executed the xcodebuild can be used to clean up and to package distribution builds, this can be used to create builds without actual dependencies to provisioning:

xcodebuild clean archive -archivePath build/MyApp \
                         -scheme MyApp
xcodebuild -exportArchive \
           -exportFormat ipa \
           -archivePath "build/App.xcarchive" \
           -exportPath "build/App.ipa" \
           -exportProvisioningProfile "ProvisioningProfileName" 

The ‘gym’ can included with all details about the build and there are plenty of parameters that can be used in the context.

  # Build the app
  gym(
    scheme: "#{options[:scheme]}",                         // e.g. scheme: app.bitbar.com
    configuration: options[:configuration],                // configuration: app.build_configuration,
    provisioning_profile_path: options[:profile],          // provisioning_profile_path: /Users/name/...
    codesigning_identity: options[:codesigning_identity],  // codesigning_identity: "xxx"
    export_method: options[:export_method]                 // export_method: "enterprise", "adhoc" etc
  )

TIP! It’s highly recommended that developers using Fastlane (and those who use the above examples) make sure their xcodeproj is at least 1.3.2 (or newer).

Different Environments and Tools for Different Use Cases

Now, it really depends if you are building an app for internal tests or building an app for release distribution. If you build an app for release distribution, Fastlane is a great tool that can get things done super fast and help you to ensure everything is in place before you actually publish the app.

If you use Fastlane during the development and preferably together with continuous integration (e.g. Jenkins) Fastlane can also offer some nice benefits.

For debugging and further developing the app you need full-blown Xcode environment up and running. You also need the same if you run tests internally on simulators or devices connected to your machine.

Enjoy Fastlane!

Upcoming Webinar – How to Efficiently Automate Testing of React Native Apps

$
0
0

Reserve your seat now and mark your calendar! Our next webinar will go through how you can leverage test automation frameworks to test mobile applications built with react native. The webinar will include a Q&A session at the end so join us to ask our expert about how to adopt test automation for your react native apps.

How to Efficiently Automate Testing of React Native Apps

Date: 14th of December 2016
Time: 11:00am PST 

Target audience: React Native developers, app developers, QA, Managers

React Native is a fresh newcomer into mobile app development landscape and lots of Android and iOS apps are getting built based on this platform. React Native provides a unique approach and number of benefits to build apps to be cross-platform compatible on native Android and iOS platforms.

There is a myriad of different options for testing React Native apps, including test patterns and setup provided by React Native. Learn the best practices, get the best tips and tricks, and ask any questions related to getting React Native apps tested.

Join this webinar to learn how React Native applications can be tested, how to adopt test automation and use the best open source frameworks getting your React Native apps thoroughly tested.

In this webinar, the following topics are covered:

  • The React Native architecture from the testing point of view
  • Different frameworks for React Native test automation
  • The impact of programming language selection for test automation
  • Break-down of available tools, methods and frameworks
  • At the end of the webinar there will be 15 minutes allocated for questions and answers.

    webinar-reserve-your-seat

    Presenters

    ville-veikkoVille-Veikko Helppi – Bitbar

    Ville-Veikko heads the marketing and ecosystem building operations at Bitbar. He has more than 15 years of experience in the embedded engineering, business and leadership roles. Ville-Veikko holds an MSc in Technology and an MSc in Economics and Business Administration from the University of Oulu Finland.

The Basics of Mobile Continuous Integration Workflow

$
0
0

The mobile workflow has been improving a lot. If there would be only two things to thank for this achievement, no doubt those would be the continuous integration adoption as a part of the mobile development workflow and use of agile and mobile devops types of cultures inside organizations. In these, the automation is the key for successful app development, testing, deployment and eventually monitoring of it running in the user context.

The mobile app quality has become crucial factor for success in mobile ecosystem. From indie developers to SMB-sized app/game studios and larger corporations pushing apps for users in various app subverticals (banks, retail, insurance, travel, and a dozen of others), they all understand what gaining a five star feedback for their app means.

We’ll take a look at how mobile continuous integration can contribute.

Historically, automation has been one of the cornerstones (and yes, selling points) for continuous integration and today continuous integration is very much the most important core pieces of most agile, mobile devops driven, development efforts and processes. In fact, the agile methods and mobile devops approaches have lifted continuous integration in its position and it has worked both ways making mobile CI popular among the agile organizations.

Agile Process as Part of Mobile DevOps

The use of automation is already in an epicenter of how developers build their software. Typically companies rely on continuous integration tools (like Jenkins) that bring clarity for development, testing and deployment.

In a nutshell, continuous integration provides a workflow to help managing code and its regressions, and then enabling efficient testing of app builds. With this sort of Agile approach, continuous testing can also happen every time code changes in repository and build gets automatically deployed.

Why Mobile Continuous Integration is Popular?

While for many of mobile developers continuous integration is already a core element there are still organizations jumping on this bandwagon. Especially those organizations that aren’t necessarily yet mobile-first with their doings may also lag with enough motivation and skills to adopt all the greatest mobile devops tools and methods.

However, the mobile continuous integration is popular among development organizations and despite there aren’t much survey data available on how many organizations that has produced the top mobile apps are using CI systems, the growing number of providers with various flavors in continuous integration have provided a boost for both agile and devops minded organizations.

Mobile DevOps and Why it is Popular

The mobile continuous integration speeds up daily doings by automating the development-testing-deployment flow. This has had a direct impact as improved app store ratings (as quality of app improves), generation of more revenue (better usability, stability and improved user experience) and faster response to any app related issue. The last one is probably the most remarkable benefit coming from the mobile continuous integration and ability to quickly turn around a new build for testing and deployment for users.

Mobile Continuous Integration Workflow

As said, (full) automation of entire development-testing-deployment flow is the most significant value that continuous integration provides. All tasks that would be done manually would only create time-consuming and error-prone aspect to this sort of development flow.

Furthermore, in order to maximize the effectiveness, efficiency and productivity of the development workflow always starts with the full adoption of automation, in it should be applied too steps of the process. All builds should be tested for acceptance, compatibility, integration and performance – and many more aspects – but this is exactly where mobile continuous integration has its value to offer. With automated, continuous integration, deployment and testing, every application or regression going through and coming out from the development pipeline can be tested in timely manner and provide results for the next iteration.

Mobile Continuous Integration and Mobile App Testing

Who will benefit from Mobile Continuous Integration?

First of all, developers love continuous integration. Many of modern mobile developers have found CI systems extremely easy to integrated with, get instant feedback on how their latest app version/regression works and what sort of issues might need attention. This all can be achieved with full logs of test runs, screenshots, hardware optimization details and recorded video of that specific test run. Itself, the logs are the vital for developers in order to fix any issues with an app.

Anyone managing the development, testing and deployment aspects also love continuous integration as the managing the overall process and all details of it are easier, results can be gained from out-of-office-hours and managing this type of process is much easier (compared to managing all aspects separately). And furthermore, the management will see impact both on top-line and bottom-line as increased productivity, effectiveness, cost savings and much better quality.

The QA is a huge fan of mobile continuous integration as they are the one who take care of tests, test scripts, frameworks, and basically all things happening between the build and delivering test results back to engineering.

Live Q&A Session at Bitbar Testing – Ask Us Anything

$
0
0

We’ll be hosting a live Q&A session to answer any of your technical, business or other testing-related questions on the 8th of December. Mark your calendar and submit your questions – we’re truly looking forward to help you out with any of your questions. So if you have a puzzle that needs a correct piece, we’re providing out best help and effort for mobile app testing, mobile game testing and mobile web testing during this event. Don’t miss this one!

screen-shot-2016-11-23-at-2-14-50-pm

Live Q&A Session at Bitbar Testing

Folks, this is your chance to get the best consultation for YOUR mobile app testing and development process. We’ll kickstart a live session where we answer your questions, focus on the most problematic topics in the field of mobile testing and anything that you’ve been struggling with. The first event is planned for the 8th of December 2016 at 11:00 PST.

You can sign up and submit your questions here.

BROADCAST INFORMATION

Date and time: 11:00 am PST, Dec. 8th, 2016 Duration: 1 hour Target audience: Mobile developers, testers, QA, managers Are you struggling with some specific topic when it comes to mobile testing? Do you need a helping hand with your tests? Or do you have an issue with a certain test automation framework? Or maybe you need new ideas how to improve your internal mobile devops process? We’re here to help! In this live broadcast, we’ll go through your questions submitted through the form on the right. We pick the best questions, provide a mini-lecture about that topic and get your questions answered and help you to solve the problem. Join our interactive Live Q&A Broadcast by signing up and submitting your question. You can also interact us during the session and we’ll make sure you get your question answered. What should you ask and how can we help? If your questions are related to…

  • Test Automation Frameworks with Any Technical Level
  • Devices, Operating Systems, Cross-platform issues
  • Mobile DevOps, Agile, Continuous Integration, Tools
  • Best Practices, Tips, Tricks or Anything That Helps You

We’ll dedicate an entire hour for Q&A and will go through your pre-submitted questions anonymously during this event.

You can sign up and submit your questions here.

Technical Experts at Your Service

Shawn Edge, Head of Consulting

Shawn heads the Professional Services and Consulting at Bitbar. He has more than 10 years of experience with cloud computing, mobile development and test automation. Shawn holds an MBA in Entrepreneurship from Babson College and an BA in Information Technology and Business Administration from Curry College.

 

ville-veikkoVille-Veikko Helppi, Head of Demand Generation

Ville-Veikko heads the Marketing and Ecosystem building Operations at Bitbar. He has more than 15 years of experience in the embedded engineering, business and leadership roles. Ville-Veikko holds an MSc in Technology and an MSc in Economics and Business Administration from the University of Oulu Finland.

Appium Tip #27: Using Appium for Mobile Game Testing

$
0
0

Appium is one of those frameworks that scales well across different use cases. For example, many of today’s popular mobile games do get tested using Appium and Image Recognition. This is extremely easy and effortless way to create tests for graphics-based content and mobile games are natural use cases for Appium Image Recognition.

We’ll take a look at Appium image recognition features, how to get started with this setup and use real Android and iOS devices from Bitbar Public Cloud.

Why Using Image Recognition with Appium?

Image recognition technique (sometimes also called OCR, Object Character Recognition) has become popular among mobile game developers as they’ve find it very easy to use and handy for creating automated tests for their mobile games. It’s worth mentioning that image recognition use cases are not limited to mobile games but image recognition can be used together with Appium also for native mobile apps, both on Android and iOS.

The main thing with Appium image recognition is that tests are easy to create and those tests would work on both platforms (cross-platform usability). The need of using image recognition for mobile games is coming from the UI components. When graphics content (from game engines, strict OpenGl ES content) is used on screen, many of these test automation frameworks cannot recognize UI elements characteristics, such as IDs, element attributes, other UI characteristics and so on. Despite human recognizes a button or other visual element on the screen, test automation scripts sees that only as pixels.

Because of this, image recognition has become an awesome way to automate mobile game tests simultaneously even on hundreds of real mobile devices.

Using AKAZE and OpenCV for Game Testing

Required Components for Appium Image Recognition

The following components and software is required to get started with Appium image recognition:

  • Bitbar Public Cloud – a web service for running tests on real mobile devices. You’ll need to have an active account for running these tests in cloud.
  • OpenCV – OpenCV (Open Source Computer Vision Library) is an open source computer vision and machine learning software library. OpenCV was built to provide a common infrastructure for computer vision applications and to accelerate the use of machine perception in the commercial products. Being a BSD-licensed product, OpenCV makes it easy for businesses to utilize and modify the code.
  • Bitbar Akaze – fork of official Accelerated KAZE repository with json support added.
  • jsoncpp – JSONCPP provides C++ support for example. With help of JSONCPP it can be used to represent numbers, strings, ordered sequences of values, and collections of name/value pairs. This is added to to the Bitbar Akaze library. NOTE! If you are looking to build Akaze and OpenCV for other platform, you basically need this one.
  • Maven – Used to compile the test code and launch it.

Using these components with Appium and Bitbar Public Cloud you are able to get your test runs started and execute in timely manner.

Example – Using Java for Appium Image Recognition

First of all, take a look at our Appium image recognition example at Github. This provides out-of-the-box example for Java using OpenCV and Bitbar AKAZE algorithm to execute Appium test scripts.

The example project can be used for local tests or with Bitbar Public Cloud and Private Cloud both for client-side and server-side execution. The only different between using the client-side and server-side execution from the script point of view is the Appium Desired Capabilities and the need to tweak those to work against the back-end (Bitbar Public Cloud and real devices).

Installing and Setting Up OpenCV

The OpenCV java libs can be found under ./lib//opencv/ directory inside the project. In order to install libraries locally with maven, just simply execute the following command line:

mvn install:install-file -Dfile=lib//opencv/opencv-2413.jar -DgroupId=opencv -DartifactId=opencv -Dversion=2.4.13 -Dpackaging=jar

Note that each platform has its own version of the libraries, so modify the command accordingly. If a different (newer) version of OpenCV is used, OpenCV version number needs also to be updated in pom.xml file.

Installing and Setting Up Bitbar Akaze fork

The AKAZE C++ implementation can optionally be found and built from Bitbar Akaze fork. The current project contains the ./lib//akaze/ folder with pre-built binaries for Linux, Mac and Windows. The sample project uses only the akaze_match binary currently.

Everything else is fetched by Maven automatically.

Additional Information on OpenCV and Bitbar AKAZE Fork

The example introduced above relies on AKAZE algorithm to find the matching keypoints from two images and store them into a json file. Furthermore, example uses the OpenCV Java bindings to process the json file with keypoints and find the homography of the wanted image in a scene (a screenshot from device screen).

The AkazeImageFinder.java class will run akaze_match, then use the keypoints from json to try to identify a given image inside a scene and return the corners of the image found.

In this example, we look for specific images from ./queryimages/ folder and try to find them on a screenshot taken from device.

Once the image is is found, test script can tap/click it, drag and otherwise interact with the game, do more holistic gestures (swipes, zooms, pinchs etc.) for game running on device. Full reference to all possible interactions and UI commands can be found in the TestdroidImageRecognition.java class.

The class has different functions for working with and manipulating the image captured on the screen and also finding those images. These are then used inside the test classes for the game tests. Few examples of used functions as follows:

// returns the corners of the image if found, or null if no image was found
public Point[] findImage(String image, String scene) 

// takes a screenshot, then tries to find the image on it and return the corners
public Point[] findImageOnScreen(String image) 

// takes a screenshot, tries to find the image on the screen, then tap the middle of it
public void tapImageOnScreen(String image) 

// takes a screenshot, finds the image on the screen, taps and holds it, then swipes the screen while still holding it
public void swipeScreenWithImage(String image, int repeats)

// takes a screenshot, tries to find the image, taps it and drags it to a certain position given as x and y offsets from middle of the screen
public void dragImage(String image, double x_offset, double y_offset)

How to Run Appium Tests locally using CommandLine with Maven

This sample project uses the Bitbar Sample App available in this repository at apps/builds:

Example Apps for Bitbar Public Cloud Tests

The project expects to find these applications (APK for Android and IPA for iOS) at the root of the project with names application.apk and application.ipa. You’ll also need to have an Appium server launched. For iOS, the UDID of the device should be preset in the server settings – if you use local environment and devices. For test runs on Bitbar Public Cloud you basically don’t need to preset or configure UDIDs or sign app with certain provisioning profile as it is taken care for you automatically when test is initated.

On your local environment, tests can be executed with Maven using the following command:

mvn -Dtest= test

For example, to execute only the test “mainPageTest” from class AndroidSample.java you can use the following command:

mvn -Dtest=AndroidSample#mainPageTest test

To first clean all the previous test result files, add keyword clean to the command:

mvn -Dtest=AndroidSample#mainPageTest clean test

You can also use an IDE to launch the tests. Make sure the project is correctly imported as a Maven project and that the pom.xml file has been correctly discovered for dependency management.

Running Tests on Bitbar Public Cloud as Server-Side Run

First, you need to create a project for Appium test run on Bitbar Public Cloud. This can be done by manually logging in and creating a project OR alternatively you can use a Bitbar API to create your project. With cURL it would be created this easily:

$ curl -X POST -d "name=NewProject" -H "Authorization: Bearer abcdefgh-1234-ijkl-m5n6-opqrstuvxyxz" https://cloud.testdroid.com/api/v2/me/projects

More information about Bitbar API (also known as Testdroid API) can be found in this cheat sheet.

Another thing you to configure before starting your test run is the project type how you want your test run to be executed. It can be Appium Server Side for Android or iOS depending on which devices you want tests to run.

Once you have your project created, use the provided scripts to create the test zip from your project:

./createAndroidZip.sh
 
// or alternatively ...

./createiOSZip.sh

Now that you have your test zip and application file (the example uses the Bitbar Sample App available in this repository at apps/builds), you’ll be ready to begin creating test runs in your project.

First, upload the app and test zip in Bitbar Public Cloud, choose the device group and finally make sure you have set high enough timeout for your test in the Advanced options (default is 10 minutes).

If you change the name of your Android or iOS test class, you will need to update it to the run-tests_android.sh and run-tests_ios.sh TEST and JUNIT variables as appropriate:

# Name of the desired test suite and optionally specific test case, eg: AndroidSample#mainPageTest
TEST=${TEST:="AndroidSample#mainPageTest"}
# JUnit file wont have the #caseName ending
JUNIT="AndroidSample"

How to build the latest AKAZE and OpenCV

OPTIONAL: Building the Latest Libraries for Image Recognition

This example has been tested on Mac Yosemite. The very same steps also work on major Linux distros.

First, we’ll need to compile up to date version of jsoncpp (needed by Akaze later on). At least on Mac, jsoncpp installed through brew gave linking errors while linking with Bitbar Akaze.

jsoncpp

Python 2.6 is needed to extract amalgamated source and header files:

git clone https://github.com/open-source-parsers/jsoncpp.git
cd jsoncpp
python amalgamate.py

By default, the following files are generated and are needed to compile new AKAZE binaries.

  • dist/jsoncpp.cpp: source file that needs to be added to your project.
  • dist/json/json.h: corresponding header file for use in your project. It is equivalent to including json/json.h in non-amalgamated source. This header only depends on standard headers.
  • dist/json/json-forwards.h: header that provides forward declaration of all JsonCpp types.

You will also need to build and copy the libjsoncpp.a library to your local lib directory:

mkdir build
cd build
cmake ..
make
cp src/lib_json/libjsoncpp.a /usr/local/lib/

OpenCV

Start with the following command to build a new library for OpenCV:

git clone https://github.com/Itseez/opencv.git  
cd opencv
git checkout 2.4  
mkdir build  
cd build/  
cmake -G "Unix Makefiles" ..  
make -j8
make install

This creates Java jar files for image recognition sample. Latest jar files are installed by executing the following command:

mvn install:install-file -Dfile=path/to/opencv/build/bin/opencv-2413.jar -DgroupId=opencv -DartifactId=opencv -Dversion=2.4.13 -Dpackaging=jar 

The pom.xml file needs to be updated with installed OpenCV version (2.4.13 in this case).

Bitbar AKAZE

You can build Bitbar’s AKAZE fork using the following commands:

git clone https://github.com/bitbar/akaze.git
cd akaze

# copy previously built versions of jsoncpp to 'src/lib/jsoncpp/', 'src/lib/json/' and src/lib/jsoncpp.cpp
mkdir ./src/lib/jsoncpp/
cp -r path/to/jsoncpp/dist/json ./src/lib/jsoncpp/
cp -r path/to/jsoncpp/dist/jsoncpp.cpp ./src/lib/
mkdir build
cd build
cmake ..  
make
cp bin/akaze_* path/to/image-recognition/akaze/bin/  

That’s all folks! You should be now up and running with the latest assets for Appium image recognition and running your tests smoothly on the environment of your choice!

Happy Mobile Game Testing!

How to Launch Test Automation Runs from Command Line

$
0
0

Many developers work on their console view significant portion of the day. Getting something done quickly and efficiently is one of those benefits that working directly from command line provides for our every day lives. Even test automation test scripts can quickly be started from the command line and in this blog we’ll take a look at how to get this done quickly and efficiently just using a bash / command line.

Don’t forget to read it entirely! There is a really nice helper script included in this article that will surely help you with your Appium testing!

REST API Access to Real Devices on Cloud

Since the launch of Testdroid Cloud (Bitbar Public Cloud nowadays) the API access was an absolute must for many of test automation users. It basically provides an instant way to launch test runs, manage all aspects of projects, devices (groups of devices) and fetch back test results with rich dataset. This way users were able to get test runs started and see the progress on their local environments, plus integrate any of their development and test management tools with our device farm of real Android and iOS devices.

The use of continuous integration tools were also integrated with the API and efficiency after each and every build from build to test was enormously improved. If you are looking for a way to integrate continuous integration tools with real devices on cloud, take a look at our REST API documentation.

The Requirements for the use of API

The REST API provided for Bitbar Public Cloud is extremely easy to adopt and use. The full API reference guide provides all information about your Bitbar account management, projects, test runs, devices, framework supports and bunch of other great features that makes test automation effortless with physical devices on the cloud service.

  • Bitbar Testing Account – You need an account in Bitbar Public Cloud to test your Android and iOS apps on devices. Everything presented in this blog can be also done manually (e.g. manual testing with remote access to devices). If you don’t have an account, you can create an account here.
  • API Key – Once you have logged into service, you can get your personated and unique API key from the top right menu (Profile -> My Account -> Access via API):

API key access to Bitbar Public Cloud

  • Device Group(s) – To get your tests running on certain devices, you should create a device group where those devices are identified. The easiest way to create a device group is landing on the service, dragging and dropping desired devices on a device group. After this, you can use these devices simply based on device group ID.

Different Options for Command Line Utilities

Bitbar Public Cloud doesn’t limit what bash or command line tools (or programming languages) you want to use. The light-weight API takes care of all gateway management, accessing devices and managing test runs and projects for you.

Project Creation with REST API

Let’s look at the simple example of how to use cURL to authenticate your access, and use POST to access a project or create it:

$ curl -H "Accept: application/json" -u <API_KEY>: -X POST -d "type=<PROJECT_TYPE>" -d "name=<project name>" https://cloud.testdroid.com/api/v2/me/projects

For the you should copy-paste your unique API key and for the you could set any of existing project types with Bitbar Public Cloud. This example creates an Appium Server-Side project under your account:

$ curl -H "Accept: application/json" -u M4vN5mVKFewM9jPK0cJw9t2NgiZjOf4J: -X POST -d "type=APPIUM_ANDROID_SERVER_SIDE" -d "name=TestAppiumProject" https://cloud.testdroid.com/api/v2/me/projects

As a response message you’ll get something like this:

{"id":106673414, "archivingItemCount":120, "archivingStrategy":"DAYS", "common":false, "description":"", "name":"TestAppiumProject", "sharedByEmail":"ville-veikko.helppi@bitbar.com", "sharedById":6105119, "type":"APPIUM_ANDROID_SERVER_SIDE", "createTime":1480503902000, "archiveTime":null, "frameworkId":541, "archivingStrategyDisplayValue":"120 days"}

And if you look from Bitbar Public Cloud, the API call has created a project under your project listing:

project view at bitbar public cloud From the JSON response you can parse the project ID (106673414, in this example) for further use. More advanced version (and very cool way) to get only the project ID as a response would go as follows:

$ curl -H "Accept: application/json" -u M4vN5mVKFewM9jPK0cJw9t2NgiZjOf4J: -X POST -d "type=APPIUM_ANDROID_SERVER_SIDE" -d "name=TestAppiumProject" https://cloud.testdroid.com/api/v2/me/projects  | sed -e 's/.*id\":\([0-9]*\).*/\1/'

Verifying Device Groups

You can nicely pull down the list of all device groups by using the following command:

$ curl -H "Accept: application/json" -u <API_KEY>: https://cloud.testdroid.com/api/v2/device-groups

It’s always a good idea to verify that device group exists before trying to initiate test runs on devices included in a specific device group. This can be done quickly with a following command:

$ curl -s -H "Accept: application/json" -u <API_KEY>: https://cloud.testdroid.com/api/v2/me/device-groups/<DEVICE_GROUP_ID>

As a response you’ll get list of device groups that are available for your user account. For instance, device group ID 14 is the free device group with Android devices. The response will look like this:

{"id":14,"creditsPrice":0,"deviceCount":3,"displayName":"Free Android devices","name":"free-android-devices","osType":"ANDROID","userId":null}

Launch Appium Server-Side Tests from Command Line

It’s very typical use case that users want to launch their Appium tests from local environment, but pushing both app and test package into Bitbar Public Cloud using a command line.

For the Appium Server-side test runs, the tests need to be uploaded as a zip package, where at the root of the zip is the “run-tests.sh” script that calls the Appium tests as on your local computer. Note that “run-tests.sh” is different for iOS and Android tests. Example “run-tests.sh” scripts for Android and iOS can be found at Github.

In addition, you can find few handy helper scripts from Github that assist you with creating and packaging tests. For example, “launch-tests.sh” helps you to get test run started. “createiOSZip.sh” and “createAndroidZip.sh” will quickly zip a test package for you. The following line will upload your test for a specific project:

$ curl -H "Accept: application/json" -u <API_KEY>: -X POST -F "file=@<ZIP_FILE>" "https://cloud.testdroid.com/api/v2/me/projects/<PROJECT_ID>/files/test"

You can also check if the test run is finalized by using a command line:

$curl -s -H "Accept: application/json" -u <API_KEY>: "https://cloud.testdroid.com/api/v2/me/projects/<PROJECT_ID>/runs/<TESTRUN_ID> | sed -e 's/.*state\":\([A-Z"]*\).*/\1/'

And when it is done, you can pull all the results back to your local environment for further inspection:

$ curl -s -H "Accept: application/json" -u <API_KEY>: -X POST "https://cloud.testdroid.com/api/v2/me/projects/<PROJECT_ID>/runs/<TESTRUN_ID>/logs.zip

NOTE! The test run logs are not available instantly after test run is finalized, but you might need to wait a second for them up to show up!

One Command for Appium Test Run Launch

At the very same Github repository, you can find a launch-tests.sh file. We’ve created this to help you to launch a test run just using one line on shell. Here is an example:

$ bash launch-tests.sh -a -p "My Android Server Side Appium" -k M4vN5mVKFewM9jPK0cJw9t2NgiZjOf4J -g "HTC+Huawei" -f ../../../apps/builds/BitbarSampleApp.apk

The usage and parameters for launch-tests.sh are as follows:

-a/i – defines whether you are starting your test run on Android or iOS devices (and what type of device group you are trying to use)

-p <PROJECT_NAME> – can to choose a specific profile. If not given, a new project will be created.

-g <DEVICE_GROUP_NAME> – in the above example there is a “HTC+Huawei” device group on my settings. It’s worth noticing that you don’t have to use a device group ID but the name will work just fine.

-k <API_KEY> – API key for authentication and access between your local environment and Bitbar Public Cloud back-end.

-t – for creating and uploading a new test zip file.

-f <APP_FILE_PATH> – for uploading a new app file.

This script has helped many developers to get their Appium tests started quickly and only using command line. We hope it will help you too!

Happy Testing Folks!

New Ebook: The Beginner’s Guide of Using Appium for Mobile App Testing

$
0
0

Appium has quickly become one of the most prominent test automation framework for mobile app, game and web testing. As an open source test automation framework, it drives Android and iOS apps, regardless of native, hybrid or mobile web apps, using the WebDriver protocol.

Download this Guide to Learn All Basics about Appium and How to Set Up your Appium Testing Environment

manifesto-ebook-devops-download

As one of the most widely used frameworks in Testdroid Cloud and with many years of experiences of supporting it, we have decided to compose the very first Appium ebook and share it with all of you. This ebook gives you enough info and insights on how to implement Mobile DevOps approach and the outcomes you can get from the adoption.

For Appium beginners, we hope this ebook has shed some light on the basics of Appium, including the definition of Appium, the supported programming languages, etc. And for those who have been using Appium many years, the ebook has consolidated your understanding of this open source and provided more useful tips.

Enjoy the ebook and happy testing at Bitbar Testing!


The Value of User Experience Monitoring for Mobile Apps

$
0
0

Maximizing and providing the best possible user experience is the top requirement for all mobile related products – and the top priority for their developers. Today’s mobile users expect apps, games and mobile web work flawlessly regardless of location where they use those and how they use those. In this perspective monitoring a native app, game or website in production is important, but it’s even more important to get the right metrics out of that monitoring data, and understand how to build better end-user experience.

Introduction to User Experience Monitoring in Mobile

We’ve discussed about synthetic mobile monitoring here at Bitbar blog few times, and as that practice isn’t too new, it also has things that are strongly deriving from the desktop world. Something that has worked well on desktop may not be as successful with mobile related things.

Therefore, building an end-user experience monitoring for mobile apps, games and web must be fully mobile-first and monitor exactly the right things around use cases. In short, User Experience Monitoring (UXM) is a modern monitoring practice for mobile. It is a form of synthetic mobile monitoring (also known and called as proactive mobile monitoring) that replicates real user interactions for mobile apps, games and websites. The monitoring results guide developers to improve their apps and enhance the app user experience.

User experience monitoring monitors and measures all critical aspects of native mobile applications, even mobile games and websites on mobile devices. It leverages all aspects of mobile platform (software and hardware) and makes 24/7 monitoring of service availability, compatibility and accessibility easy and effortless.

The whole point with user experience monitoring is that it works identically like a real user would use the app, buy services, interact with app’s features that communicate with some back-end implementation etc. The use case would be identical also to real-user monitoring (RUM) but there wouldn’t be actual users doing this but all interactions would be replacated as test scripts and other simulated inputs.

Bitbar User Experience Monitoring Sneak Peak

The Benefits of User Experience Monitoring

First of all, user experience monitoring utilizes identical set of equipments, hardware and software, that would be used by an end-user. This makes monitoring and all its data trustworthy and accurate. Preventing any sort of performance, compatibility and usability issues are in significant role of enabling better user experience. And when looked this from the developer’s point of view, preventing something that may have negative impact on their mobile product, their business and their brand, are something that should be taken seriously and prevant to happen as early as possible.

The user experience monitoring has 6 unique benefits over any other form of mobile monitoring, and those are as follows:

Any issue should be visible as soon as it happens. When using user experience monitoring for mobile apps, games and websites all details about the app behavior, launch, execution and interaction is provided with network stack information, screenshots and additional log data. With these test results users can optimize and fix any issues related to their product running on different physical locations and networks. The user experience should be monitored 24/7 and intervals should be as short as possible to provide information when something isn’t working.

Getting only the right data. With real user experience monitoring nothing is simulated or emulated. That’s the basis to get only reliable and trustworthy data about the user experience, performance, stability and usability of your product running and working for end-users. User experience monitoring should provide all necessary network, OS/platform and user level details that makes debugging and fixing of those problems quick and easy.

Easy to setup, even to other corner of the world. As we’re talking about monitoring that happens in a real network, in real physical location any place in the world, it should be easy and effortless for its users to get things up and running. All business and performance critical information should be on real-time, provided with fine-grained details about those form factors for user experience.

The most secure way to monitor apps.The best competitive advantage in user experience monitoring is that nothing gets out to users that could exploit your app, service or any aspects of it. The user experience monitoring enables monitoring of applications even in beta so you don’t need to go through tedious app release cycles but just uploading your APK or IPA to the service and selecting locations/networks will get your monitoring checks going.

Improved App Quality and Better Perception by Users. Probably the most fundamental value that user experience monitoring offers is that all that metric achieved from real-world execution can get you the right data to improve those factors for better user experience. As the app quality, its attributes and end-user perspective is considered during the monitoring, all of those have a direct impact on app quality and eventually how end-users accept your product.

Use of Existing Test Automation Assets. When mobile apps are build today for large number of different devices, different user personas and segments, mobile apps should have been thoroughly tested before publishing those out for users. Test automation has been an instrumental way to get various aspects of mobile app tested in an automated process, and this is something that is available in user experience monitoring as well. With sophisticated test automation combined into our monitoring product, you can build any levels of test automation into monitoring process. Using open-source test automation frameworks with monitoring makes creation of complex and highly sophisticated tests easy and effortless.

The Most Valuable Features of User Experience Monitoring

Compelling features that make end-user mobile monitoring easy, quick and effortless are important for all products that aim to hit certain audience and provide stunning user experiences with its features and performance. There are few distinctive features in user experience monitoring that makes it unique when compared to all other monitoring techniques:

User testing for native apps, games and mobile web. User experience can be tested and monitored on different locations, using different networks, and variety of different important metrics can be fetched and monitored during the process. User experience monitoring doesn’t limit its functionalities or use cases to mobile web only but provides the first mobile native app monitoring capabilities for its users.

Reuse of Appium test scripts. Appium is one of the hottest test automation framework for mobile app testing at the moment. If you use Appium for mobile app testing, our user experience monitoring also takes those Appium test scripts and allows them to run on any locations around the world. This will improve the testability and test automation aspects and results as an improved app quality and reusability of your current test assets.

Application, Transactions, Pings, Back-End Integrations. Our user experience monitoring provides versatile features for mobile monitoring. If you are working with a back-end, want to get app launched and get all possible metrics and data about its performance, or simply get data about a monitor check, then use of user experience monitoring is highly encouraged.

Real network traffic and data (no emulation). Mobile apps rely on third-party service providers like CDNs, ad networks, e-commerce platforms, and social media networks to get things done. With help of user experience monitoring you get an efficient way to manage all third-party services, get all the data that your app is pushing for those third-party services, and to see and inspect networks traffic and stack traces of those. Clear and comprehensive reports can be obtained and all details of performance, compatibility, usability and user experience can be combined into one, cohesive report.

When things go wrong, you must know about it, instantly. In user experience monitoring, many things can quickly pass by users but sophisticated scripts take care that nothing is passed by those. You’ll get notified about problems and any issues instantly, and via different preferred channels.

Availability and Performance Equals as Revenue Generation

If your website is down and you are not aware of this, your business quickly drops to zero. When any of blocking issue, problem or slow-down happens on your asset you should be notified as soon as possible and get instructions of how to get rid of the revenue blocking issue. That’s what user experience monitoring is also extremely useful for.

With help of user experience monitoring provided by Bitbar your business can monitor the most critical assets in your revenue generation. Whether those are native mobile app, mobile game or mobile website that your target audience is using on mobile devices, there is tremendous value that Bitbar Monitoring has to offer for you.

We’ll be gearing towards the launch of the product and will surely keep you updated. Meanwhile, we have a trial for beta users available and it can be requested on Bitbar Monitoring website.

Looking forward to hear from you!

Introducing Expanded Professional Services

$
0
0

Hello fellow Testdroiders!

I wanted to introduce myself and share some new things we’ve been working on over here at Bitbar.

But before we start, we are giving out End-of-Year holiday gifts. Hurry up and claim your gifts today.

I recently joined Bitbar about a month ago, I was previously an Automation Engineer for several fortune 40 companies.  There’s a lot of change happening in the industry at the moment. A lot of companies are adopting Agile and DevOps practices and making a huge shift to using open source tools. I’ve been in the industry for over a decade now and I’ve seen first hand how these practices work in organizations of various sizes.

There is so much more these days to understanding what a QA Engineer does and what kind of role this person has in Agile/DevOp groups and it’s one of the reasons why I decided to join Bitbar. I want to help people like you and your organization succeed at it.  There are so many frameworks now and methodologies that most companies are pushing from the top down, but they haven’t actually used the tools and processes so they don’t know what it takes to be successful!

You’re probably thinking what this has to do with Bitbar…

I’m happy to announce that Bitbar has now expanded it’s Professional Service offerings that your team or company can take advantage of to be ensured you are setup to succeed. 

Below is a map of the new offerings:

DevOps Testing Consulting Training
CI/CD Integrations Choosing a Framework QA and Test Process Improvement Best Practices
Strategy Script Maintenance Testing Strategy Framework and Tool adoption
Reporting Framework kickstart QA and Testing Maturity assessments TDD/BDD
Tooling  Managed Automation Testing Services Manual to Automation Workflows Improving stability with Testing

What I love the most about Bitbar is that we don’t push technologies on teams to use. We work with you to understand how your team operates and based upon that we can come up with a long-term plan that will really increase the quality and reduce testing time to the app store.  Everything we develop or work on is open sourced so that it can be reused locally and in other environments without high switching costs.  It’s very expensive these days to switch from proprietary frameworks not only from a cost standpoint, but also time and resources.

For the holiday season as your team figures out 2017, Bitbar is offering a 1-hour free consultation to help you strategize for the New Year.

How to get started with any of these offerings? Just let us know and schedule a session with us!

*Note: First come first served based upon availability.

Happy Holidays and Claim Your Holiday Gifts

$
0
0

Hello everyone,

Year 2017 is around the corner and holiday season is approaching again. I bet you have been preparing and purchasing all kinds of gifts for families, friends and working partners.

As been grateful for supporting and trusting us over the past year, Bitbar has prepared holiday gifts for all of you and we believe that the gifts will help you achieve a greater success in the New Year. Let’s unbox and check out what special things you’ll get.

  • Free Mobile Testing Consultation – Complimentary 1 hour strategy session with our new Head of Consulting, Shawn Edge!
  • Up to 20% Off Dedicated Devices – Integrating with CI, have long tests or require a VPN? Add dedicated devices to your Testdroid account!
  • 10 Free Hours in Public Cloud – New signups get free time on the Testdroid Cloud!
  • New Annual Plans Receive Bonus – We’ve got a special stocking stuffer for folks that want to solidify a testing strategy for 2017!

Keep in mind that these special offers are valid until the year ends. Please claim your gifts here as soon as possible!

* Testing consultations are provided on a first come first served basis and are subject to availability.

Pros and Cons of Using XCTest for iOS Testing

$
0
0

There are actually very few test automation frameworks that are tightly coupled with the development tool itself. XCTest framework is one of those frameworks that enables its users to write basic unit, performance and some level of UI tests for iOS apps. And as always, frameworks that couple tightly with their development tool and environment has some pros and cons that users should be aware of. In addition to pros and cons of XCTest, we’ll take a look at some basic things about XCTest framework in this blog.

The thing with frameworks (like XCTest framework) that integrate tightly with development environment is that those frameworks typically provide easy-to-use and seamless workflow with other components and features of the development environment. Also, there has been lots of changes in the iOS app test automation landscape lately due to Apple’s decision of deprecating UI Automation from Xcode.

Now, if you haven’t used XCTest before and you started out with it, there are few things worth of mentioning before diving in. Let’s start with a brief introduction.

A Brief Introduction to XCTest Framework

Like Android Studio, Xcode provides feature-rich software testing capabilities for developers that can significantly help enhancing the stability of software. Furthermore, Xcode provides XCTest and XCUITest that are extremely helpful for achieving and building better quality software. Thoroughly tested apps, and regardless if done in unit level or UI level, improve the user experience and accelerate adoption of those sort of apps.

Frankly, XCTest is not a new framework but it has evolved quite well with Xcode releases. In fact, the XCTest framework was introduced with Xcode 5 couple years ago. What XCTest basically does is to allow its users to do unit testing for Xcode projects (iOS apps among them) as it is currently considered as one of the top option for iOS app testing. And writing any tests with XCTest is a trivial task to iOS developers because XCTest is fully compatible with both Objective-C and Swift. In addition, all test classes developers create in Xcode project are basically subclasses of XCTestCase.

XCTest tests can be executed in simulator or real physical device. If you use real devices locally, you just need to make sure all provisioning side of things (provisioning profile) is a valid and set properly to test target. The test methods used in XCTest are instance methods so no parameters are passed nor they return a value. For this the name also begins with ‘test’ and all added tests are visible in Test Navigator of your Xcode project.

If you are interested to compare the top iOS test automation frameworks for app testing we have provided some comparison of those, with code examples and also some best practices here at Bitbar blog.

Pros and Cons of XCTest Framework

Many of today’s test automation frameworks are based on frameworks and layers that development tools provide with them. In case of iOS this is XCTest and with Android most of the frameworks are based on JUnit and Android instrumentation.

The advantages of XCTest over the other frameworks for iOS app testing are as follows:

Easy to Learn and No Additional Components Required. Xcode provides everything to get started with test automation with XCTest. Xcode’s XCTest is an integral part of the tool so testing is fairly easy to start and convenient to work with.

Native iOS Language Support. Basically writing tests with the same programming language that your application is build with is not a requirement, but it gives some confidence for developers to create tests for their apps. Other way around, some developers may also think this differently and prefer other additional languages, frameworks and tools to be used in test creation. Nevertheless, there is no learning curve or language barriers to get started with XCTest test creation.

Xcode Test Recorder. This is mostly a feature for UI tests but as XCTest is closely related with XCUITest the UI recording is possible with Xcode environment. The UI testing capabilities with Xcode include UI recording, generating code out of those recordings, run tests identically as those were intended while UI test was recorded. Record-and-playback testing tools have plenty of benefits and can get testers do the job even without understanding of underlying software. In addition, recording tests again is possible or simply editing the generated piece of code with whatever changes have been done for app itself. In short, record and playback tools provide fast way to create tests, decent level of accuracy, and not being too sensitive for user-input errors.

Integrating with Continuous Integration. Integrating XCTest with continuous integration is also easy. Xcode allows XCTest tests to be executed using command-line scripts/shell and seamlessly integrated with Xcode’s continuous integration Bots. However, there is a way to integrated XCTest scripts and the development environment with more widely used CI systems, such as Jenkins, but there are lots of things you need to know and sometimes – despite XCTest and Xcode have provided this capability for some time – tests end up failing just for no reason.

Faster than ‘On-Top-of-It’ Frameworks. Many other frameworks are relying on XCTest. And despite that those frameworks provide more features, higher abstraction (or at least way to think so) level for testing and better capabilities, they still rely on foundation of XCTest. This naturally makes XCTest faster as you don’t need to rely on abstraction APIs, albeit in many cases lightweight.

XCTest isn’t perfect but it provides some excellent basic functionality and capabilities to exercise tests on your iOS apps. As XCTest has improved by each version of Xcode, there are few cons you should consider:

No Cross-Platform Support. Apply typically builds everything to be available only on their own tools, devices and environments. As this is understandable in case of integral testing API and functionalities, many of testers prefer cross-platform test automation frameworks, and have that one test script to work on both platforms, Android and iOS. Then great option – and also XCTest based framework on iOS – is Appium. On Android, Appium utilizes Selendroid and uiautomator as its foundation and converts those commands written in Selenium Webdriver to native commands.

Limited Programming Language Support. As this is clearly one of iOS app development’s advantages, it is also one of its cons. Basically app developers and tests created for those apps are limited to build with Objective-C or Swift. Again, abstraction framework on top of XCTest will expand the programming language selection and provide testers a freedom of choice with their tools and programming languages. Appium is a great example here again as it provides support for all major and several not-so-mainstream programming languages as well.

Flaky. XCTest isn’t that new but it still has some issues with basic usability and in robustness of creating tests for iOS apps. Doing some the basic unit tests and running on those in simulator may work just fine but when you try to run the same tests on devices, you’ll see that there is some room for stability improvements with XCTest and Xcode in general.

Conclusion

XCTest is a valid choice for basic unit level testing of iOS apps and functionality. However, you need to add lots of those sort of basic tests to thoroughly cover the logic, and that makes functional UI testing more suitable for iOS apps.

What are your experiences with XCTest and do you feel it will be the number one choice for app developers? Weigh in with a comment on section below!

How to Create IPA and XCTest Package for iOS Testing

$
0
0

The Xcode’s XCTest framework is getting used more and more by developers and QA folks that aim to test their iOS apps efficiently. This framework is a great addition in iOS developers toolbox and in order to get you up and running with it here are some basic step-by-step instructions on how to get started with XCTest and how to create IPA properly for a test session.

Methods to Create iOS Package Archive

The application and test package are both required for XCTest testing. The same thing applies for any functional UI test automation and then application (whether IPA or APK) can be used for target devices and test package for instrumentation or to be used as part of the device session. More specific information about iOS development certificates, provisioning profiles and identifiers and how to prepare IPA for Testdroid Cloud can be found at Bitbar blog.

Working on Xcode to Create IPA for Testing

First, we’ll take a look at Xcode and how you should be working with it to produce IPA compatible with a device session, and with the right configurations.

1. Archive Your Build.

When you archive your build, the package will be compatible with an iOS device. When your build is done and archiving has finished, select the build from Archive list and click “Export…”:

How to Archive IPA from iOS Project

2. Select The Right Method for Export.

When the following window is shown, simply select “Save for Ad Hoc Deployment” and click Next.

Save for Ad Hoc Deployment

3. Identify Yourself (and the Build).

Use the same identify what you use in build settings for code signing. If your project and Xcode is properly configured you should see the following type of dialog proposing the first usable identifier:

Use Identifier the same way you use with code signing

4. Select Supported OS and Devices.

It’s almost always recommended to include all possible device support for your app. However, if you want to reduce the size of your IPA you can shrink it by selecting to support only certain devices and OS versions. In that case you would select Export for specific devices and select devices from the dropdown. To support all of them (recommended), just select “Export one app for all compatible devices”:

export one app for all compatible devices

All done! Now just follow through the wizard to locate your .ipa file and everything will be ready for the test session.

Working on Command Line to Create IPA for Testing

To get started with command line script you first need to make sure IPA file will be testable and it can be packaged properly.

1. Select to Build for Testing.

This can be done Product -> Build for -> Testing menu:

build ipa for testing using xcode

2. Locate the App File on Your Harddisk .

Next, select your project in Project Navigator and right click to “Show it in Finder”:

select show in finder in project navigator

3. Copy the Application File.

After Finder dialog has been opened and files are shown, just highlight the .app file and right-click to see copying option, as follows:

copy app file to right place

4. Create IPA from Command Line.

Finally, open the terminal, and create IPA package with following command line:

$ mkdir /ProjectName
$ cd ProjectName
$ cp -r /Path/To/Your/IPA/File/LocalizationDemo.app .
$ cd ..
$ zip --symlinks -qr "LocalizationDemo.ipa" ProjectName

Now you have an IPA file to be used with a test session on devices.

Create a package for XCTest

Things will start with compiling unit tests. It will actually happen automatically if you have checked target properly. This can be done or just verified that everything is properly set up under Product -> Scheme -> Edit scheme.

Select Target on the left-hand side menu and check all items on Run column:

configure target properly in Xcode

This will make sure your tests will be compiled whenever your app is getting built.

The next thing you need to make sure of is that all used classes for testing are available in test bundle and memberships are appropriately tagged. This can be done on the right-hand side menu “Target Membership” for each file. In the following example, MyModel.swift file is the one under test:

target membership in xcode ios project

Another option is to use @testable annotation for importing different modules.

Now, to compile tests for real device, select device to be used from the menu and press Command + B (or Product -> Build). Note that since Xcode has been changed quite a lot with the latest version, you have to deal with those tests differently based on which Xcode version you are using.

Xcode 7

In Xcode 7 you can right click on .xctest under Product, and select Show in Finder:

xctest in Xcode 7

Xcode 8

In Xcode8 .xctest can be found inside of the .app, so in order to locate is right click on top of the app, Show in Finder, right click again top of the app in Finder and select Show Package Contents:

xcode 8 and xctest test package

Then go to the Plugins folder and right click top of the .xctest and select compress:

xctest packaging with xcode 8

Now you have XCTest package as a zip file:

xctest as a zip file

These files are now usable locally with your real, physical iOS devices, or alternatively with mobile app testing cloud service. Looking for some basic material about iOS app testing? Look no further, here is all you need to know in order to get started!

Happy iOS Testing Folks!

Viewing all 187 articles
Browse latest View live