Back when I started developing software, life was easy. I got my stack of 80 column keypunch cards together, walked over to the reader (praying I didn’t drop the stack), loaded them and off the program went. I know you think I’m joking (or don’t even know what I’m talking about, which is more likely), but sadly, I am not. The truth is I was taking pre-built stacks and only supplying parameter cards but that’s how I started. Soon after, thankfully, we moved to green screen terminals, and then to PCs. Talk about progress! It was for them anyway.
Seriously though, when I started really developing software, it was mostly client server stuff (using Powerbuilder) and it was Windows and as long as it looked okay and worked on a 1024×768 screen I was okay (don’t even get me started with the QA person who’s first test case was to sit on the keyboard). Even for my first few web jobs we only supported Internet Explorer and the same resolution commitment had to be met.
My, how things have changed! Welcome to the new digital reality, where apps run on everything from watches (and sometimes much smaller in headless fashion) to systems with gigantic screens and everything in between.
Even when you narrow the field to just include tablets and smart phones, there is still an enormity of form factors, screen resolutions and networks that, when matrixed together pose a formidable testing challenge.
This leads us to a pretty fundamental question – How do I validate my mobile app?
In my opinion, the answer to that question is ultimately test automation. The more tests you automate, the broader the coverage you have and the more efficient the end to end process becomes. But that, my friends, is the subject for another blog.
Let’s answer a simpler question – How do I validate my app on more devices and networks in a way that doesn’t require me to own all of them. One answer is Device Test Clouds. Device Test Cloud vendors provide cloud based devices, wired to real networks that organizations can subscribe to in order to meet their testing needs.
In some ways this is not exactly a new topic. Milja Gillespie discussed the topic in her blog SAP HANA Cloud Platform 3rd Party Integration Framework: Testing Mobile Apps with Keynote Mobile Testing. Since we released that blog we have also added Perfecto Mobile (http://www.perfectomobile.com) as a second Device Test Cloud provider.
Up until now, however, use of these services required a Fiori mobile developer to first build his app, then switch context into the Fiori mobile admin console, and then test his app. Workable, but not optimal. All that changes with the integration of Device Test Cloud support into the Fiori mobile developer experience. With this most recent update, developers can build and test their application without switching context, launching the Device Test Cloud provider from within SAP Web IDE.
So how do set up this awesome new feature? I’m glad you asked, because I’m about to tell you!
Step 1 – Enable the mobile service for SAP Fiori: This process is described in Dhimant Patel’s Blog SAP HCP, mobile service for SAP Fiori – Part 1.
Step 2 – (Optional): Enable a Device Test Cloud provider: Once the service is enabled, click on the Fiori Mobile tile, then click Go to Admin Console. Once the console loads, click on Account > Device Test Cloud and select one of the listed providers. Currently two providers are integrated, Perfecto Mobile and Keynote by Dynatrace. You’ll notice that there is space for a custom provider as well. Any third party that wants to integrate with our interface can provide you with the appropriate Base URL and the integration should work just fine:
Note: Licensing and support in all of these scenarios comes from the vendor, not SAP.
Another Note: In a production environment, this feature is only available to Account administrators. If you’re not an account admin, well then you’re pretty much stuck. You’ll have to contact your account admin and ask him to perform these steps.
Still Another Note: In the trial environment, this step can be skipped, as a Developer can enable the Device Test Cloud provider as part of first use. However, we’re seeing a few integration issues right now, so I’d recommend that you perform this step now so as to avoid any issues later.
Step 3 – Build Your Packaged App: This process is mostly covered in my blog title The Fiori Mobile Developer Experience has arrived!, so I won’t go into the process in all that much detail here. But suffice it to say it’s really two steps. The first step is to take one of the Fiori templates and create / extend your Fiori web app. The second step is to, using Fiori mobile and the Cloud Build Service, create your packaged app. This is the process of taking an app that runs purely in a web browser, and packaging it so that it can execute within the context of a native container. Once that’s done, you’re ready to bring the Device Test Cloud into the picture.
Once you’ve completed the build process, you’ll be left looking at a screen with a QR code:
As discussed previously, if you have an iOS or Android device you can scan the barcode, install the app and do all the testing you want. But testing only on your own device isn’t really full app validation, is it? What if you don’t have an iOS or Android device, but your app needs to support it? What if you need to test on multiple networks? Device Test Cloud integration allows you to validate your app on all the platforms and networks that your app is intended to support.
Step 4: Launch your app on a cloud device. To access the Device Test Cloud is easy. Simply click on the Close button to close this window (The QR code can be accessed again later by right-clicking on the project name, selecting Fiori Mobile > Show Build Results at any time.). Right-click on the project name, select Fiori Mobile and you should see two menu items – Launch on Device Cloud (iOS) and Launch on Device Cloud (Android):
Only if the app has been signed during the build process will these menu items show up, so make sure you sign your app when you build!
If you skipped Step 2, and the Device Test Cloud provider has not be configured, you will prompted to configure the provider now:
Follow the steps outlined in Step 2, and then come back and launch the Device Test Cloud again. At this point you’ll see a confirmation message:
Basically this message just says that we’re about to turn you over to a 3rd party, and that as a customer you will be interacting directly with the third party for topics like support and data privacy practices.
A new window will open, and typically the third party will present you with a Welcome screen.
After that, you will need to approve the transfer of user information and the app binary to the third party:
Once you are done with those screens, you will be presented with the third party home screen. In the case of the Device Test Cloud integration, SAP transfers not only the app, but different information about the app, such as form factors supported and minimum OS level supported so that the third party can intelligently display the correct devices for this app. In the scenario below, you will notice that only Android devices are displayed, because we are testing an Android app.
Voila! At this point you can select a device and begin your testing. How easy was that??
Which third party should you pick? Well, that’s up to you. Since SAP considers this a category (Device Test Cloud providers), you should expect that everyone listed provides similar basic capabilities (real devices on actual networks, support for automation, etc). But each vendor has its own unique value proposition. and pricing models and service levels may vary. You need to do your own due diligence.
Good luck and good testing!