Robotium Guide for Beginners

Robotium For Beginners

Test Android Sample App

Reasons Windows Phone Apps are Rejected

Incorrect app screenshots

Requirement 4.6 - App screenshots. Your app screenshots should not include any emulator chrome, frame rate counters, or debug information. They should not be altered or be transparent. Also, photos of your app running on a device or the emulator are not substitutes for a screenshot taken with the emulator.

• Tip: Use the built-in emulator screenshot tool to take the screenshots. The Windows Phone 8 SDK ships with emulators for WVGA, XVGA, and 720p resolutions.
• Tip: Don’t take WVGA (480 x 800) screenshots for Windows Phone 8 XAPs. Instead, use the Dev Center feature that automatically scales the XVGA screenshots down to the WVGA resolution.
• Tip: Screenshots are not required to be localized, however, you do need to provide at least one screenshot for each language supported.

Here are a couple of examples of bad screenshots:

Bad screenshot 1 – Note emulator chrome	Bad screenshot 2 - Note frame rate counter in upper right

And here are the correct screenshots:

Good screenshot 1 - No emulator chrome	Good screenshot 2 - No debug information

Missing information to test the app

Requirement 5.1.4 - App Testability. Many apps require login credentials to run. If your app requires an existing account, make sure you create a test account that can be used by the certification team during testing. Don’t forget to include the account credentials in the Certification notes in your Dev Center submission. Click More XAP Options on the Upload and describe your XAP page.

Include test account credentials in Certification notes field.

App crashes

Requirement 5.1.2 - App closure. This requirement is simply to verify that your app doesn’t crash during certification testing. As you know, if your app crashes in release mode, it just goes away without any user prompt. Certification will reject your app if it “unexpectedly terminates” during testing.

BugSense and Little Watson can help you collect unhandled exception telemetry data. See this KB article for more info on how to avoid crashes: Troubleshooting Windows Phone App Problems that occur after Submitting.

Incorrect icons and tile images

Requirement 4.7 – Required app images. Developers sometimes forget to replace default icons and tile images in an app created from a Visual Studio template. Other tools such as App Studio and Apache Cordova provide default images that are to be replaced with unique icons and tiles that reflect your app. The default images are useful in letting you know the required size for these assets.

Default tile provided by App Studio - replace before submitting

Default tile provided by Visual Studio – replace before submitting

• Tip: Visual Studio creates a default large tile when using the Project New template -FlipCycleTileLarge.png. This tile (691 x 336) is required only if your app supports large tiles. By default, this option is disabled in the WMAppManifest.xml settings. If your app doesn’t support large tiles, you can delete the tile from the project. This will save space and installation time for this unused asset.

Incorrect use of the Back button

Requirement 5.2.4 - Use of Back button. The Back button behavior is narrowly defined. The Back button should:

• Close the app only if the app is on the main page
• Go to the previous page only if not on the main page
• Close an open dialog
• Close the soft keyboard

There are two exceptions to this:

1) If the app is a game, and if during game play the Back button is pressed, game play can be paused and present a pause prompt. Pressing the Back button again should dismiss the pause prompt and restart game play.

2) If you need to confirm with the user that they really intend to close the app when the Back button is pressed, you can display a confirmation prompt (for example, “Are you sure you want to quit?”). This should only be done when the Back button is pressed and the user is on the main page. An affirmative response should exit the app. A negative response should return the user to the main page. You can do this by overriding OnBackKeyPressed.

• Tip: If you are writing a C++ app or game, see the Marble Maze sample for sample code on implementing the Back button behavior in a native app or game.

Insufficient localization information

Requirement 5.5.1 – Language validation. For each of the languages your app supports, you must provide a localized app description. This is the description entered as part of your Dev Center submission. Certification testing also verifies that your app displays properly for each of the languages your app supports.

• Tip: Use the emulator to quickly switch between phone languages. To do this, press Settings, and then press language + regions. Then change the language setting to one that your app supports. Don’t forget to tap restart phone – otherwise the language change will not persist. When the emulator reboots, deploy, start your app and verify the correct language is displayed. Note that the emulator supports all of the display languages supported by Windows Phone, whereas your development phone likely doesn’t.

Lack of support for both light and dark phone themes

Requirement 5.5.2 – Content and themes. This requirement ensures your app displays properly in both light and dark themes. You can switch between themes on your phone. To do this, press Settings, and then press theme.

• Tip: Use Blend and Visual Studio during layout to easily switch between themes.

Interview Questions

Testing Concepts

1. What is the main difference between Verification and Validation?
Verification is related to static testing, where as Validation covers dynamic testing.


2. Describe the difference between the Black box and White Box categories of testing.
Black Box testing is conducted with no knowledge of the of the application’s code or internal structure. White Box is conducted with knowledge of the code or internal structure.

3. Is it possible to use both Black Box and White Box Testing with Verification?
Yes, as documentation reviews are static inspection or ‘desk checks’ we might consider these Black Box and as Walkthroughs are done with the author these might be thought of as White Box. 


4. Name some types of testing that belong under the Functional testing group.
Types of Acceptance testing such as Alpha, Beta, UAT and OAT would fit under Functional Testing - though we’d expect some cross-over into Non-Functional also. It’s not common to assign Test Types as such as the focus is Features and Behaviours.


5. Name some types of testing that belong under the Non-Functional testing group.
Any Test Types that are related to 'emergent' characteristics and attributes of the application under test such as Accessibility, Localisation and Performance.

6. Summarise how Performance, Load and Stress testing types relate to each other.
Load and Stress testing are testing sub-types of Performance testing. Load testing focuses on normal operational profiles of the application, whereas Stress focuses on load outside of the expected operational profile.


7. When and against what might we use Static Black Box testing?
When performing an Inspection of Documentation, though ISTQB states this is White Box testing that would more accurately apply to Peer Reviews and Walkthroughs.


8. Are all forms of Validation testing dynamic? Explain why they are or aren’t.
Yes, because they involve running the code and when the code isn’t being run we’re doing Static Verification.

9. How does Regression Testing fit across the overall testing domain?
Regression Testing is not a specific Test Type but an Approach that covers both manual and automated execution and draws together Test Cases for many Test Types. 


10. Name the main ‘levels’ of testing as recognised by ISTQB, list any others you recognise.
There are four levels which are; Component, Integration, System and Acceptance.

Pros and Cons of iOS and Android Development & Testing

iOS and Android are very clearly the dominate mobile platforms at the moment. Many companies develop apps for both, but some companies still release apps on one platform first then expand the successful apps. But how do companies decide which OS to tackel first?

iOS Pros

‘There are mature APIs (application programming interface) in place which are well designed and debugged, and actually date back to NeXT system in the early ‘90s. These are complemented by good documentation, a decent dev community and lots of good quality open source code.’

‘There’s also a comprehensive tool chain which is easy to get started with, and a relatively quick code-compile-run turnaround when using the Simulator, all of which makes development faster.’

iOS Cons

The App Store review process is unpredictable and inconsistent.

Getting apps onto test devices can also be complicated at first, but third party tools are starting to make this simpler. Also, developer accounts are limited to 99 test devices a year, which can become a problem when you release multiple apps under one account.

Android Pros

There are definitely more inter-app integration possibilities. ‘

You have fewer restrictions on what your app is allowed to do, but it’s a double-edged sword, as this can open the door to malware.

With Android it’s much easier to get your app on devices and far easier to publish app to Google Play store.

Android Cons

The sheer number of Android devices out there in the field makes testing on all of them virtually impossible,’ laments Venn.

‘Dev tools are clunky and painfully slow to use – sometimes it can actually be quicker to deploy your app to a device rather than to the Android dev emulator, which is ironic when you consider that it’s there to make testing easier.’

To cap it all off, uptake of new OS versions has been very slow so far. This leads to frustrating incompatibility issues across different devices.

iOS and Android UX Design Similarities and Differences

The same app can be available for iOS and Android, but making sure the app looks, feels and functions correctly on both major platforms is a huge development and testing challenge. Android is famously more open in terms of its app standards while iOS has a specific set of guidelines that must be followed. This makes creating the same app for both platforms a bit challenging. To help you get your head around the issue, The Archer Group has put together a list of  iOS and Android app design similarities and differences. It’s changed a bit as new devices (specifically the iPhone 5) have hit the market, but they are still good points to know.

UX Similarities

·        Application structure: The basic flow of information can be similar in both iOS and Android platforms. It’s rarely necessary to define      completely unique information architecture for each platform.

·        Expected functionality of basic UI components: Many UI components, including tabs, sliders, pickers, text fields, checkboxes, switches, and buttons, are very similar across both platforms. The design treatment and placement of the UI components varies between platforms, but their expected functionality is quite similar.

·        Gestures: The most basic and common touch gesture controls used in applications are similar in both iOS and Android. The tap, drag, flick, swipe, double tap, and pinch gestures are typically used for similar actions across both platforms. The only gesture that has significantly different usage across platforms is the “tap and hold” gesture, which is much more commonly used in the Android platform to reveal a contextual menu of options or to enter a data selection mode.

UX Differences

·        “Back” navigation: “Back” is a UI element in iOS applications, placed in the upper-left hand corner of the navigation bar that navigates backward only within defined screens in an application, never across the entire device. In Android devices, there can be two different “back” actions: “up” and “back”. “Up” was introduced primarily for Android 3.0+ devices without hardware keys and is a UI element represented as an icon on the left-hand side of the top action bar. “Up” navigates back within an application. Android “back”, in contrast, is a button on the physical device that goes back in history across the entire device.

·        Tab navigation placement: Tab navigation is typically used to navigate through primary functions in an application. iOS tab navigation is represented through a tab bar at the bottom of the application. Android recommends that tabs be placed at the top of an application. In addition, by iOS standards, only 5 tabs can be displayed at a time. In Android, however, scrollable tabs can be used to display more tabs than can fit in the viewable screen width.

·        Search: In iOS, the standard UI control for searching within an application is a search bar that is placed at the top of a searchable screen. In Android, several different search options are available. A “search dialog” component can be used that is similar to the iOS approach and places a search bar at the top of the screen. However, this bar is hidden until the user presses a search button within the user      interface. An alternative search approach in Android 3.0+ is to use a “search widget” that allows search to be placed anywhere within the application interface, typically within the application’s action bar at the top of the screen.

How to record your Android tests with Robotium Recorder

How to record your Android tests with Robotium Recorder

Android

Android

Android is an operating system based on the Linux kernel, and designed primarily for touchscreen mobile devices such as smartphones and tablet computers.

It was initially developed by the  Android, Inc. and later Google bought in 2005.

Features of Android include:

• Messaging
• Web browser
• Voice based features
• Multi-touch
• Multitasking
• Screen capture
• Video calling
• Multiple language support
• Accessibility
• Streaming media support
• External storage
• Java support

Each version of Android since 1.5 has been developed with a specific codename. These codenames are chosen alphabetically, and have thus far all been dessert items (or, generically, sweet/sugary foods). 

The following names are used for the currently existing Android releases. Note that versions 1.0 and 1.1 were not publicly named. 

Android 1.0 and 1.1

Android was born in 2008 on the gawky, gangly but ultimately powerful and fun T-Mobile G1. Made by HTC but flogged by T-Mo, this early version of Anroid was full of potential, but we deemed it best suited to early adopters and gadget hounds.

Although the G1 couldn't beat the nascent Apple iPhone in the style stakes, it offered most of the major Android features that we've come to know and love.

What you get:

• The Android Market served up apps without the stringent entry rules of the Apple App Store, leading to a vibrant selection of apps, ranging from the sublime to the ridiculous.
• The Android browser made surfing the Web on your phone a pleasure rather than a pain, thanks to the ability to render pages quickly and accurately.
• Google Maps used the phone's GPS and Wi-Fi to pinpoint your location on an infinite map, so you need never be lost again.
• Syncing with our contacts, email and calendar online initially made us wary of sharing all our data with Google, but our privacy concerns were soon vanquished by the sheer convenience of accessing everything, from anywhere.

Android 1.5 Cupcake

The sugary code-names started with Cupcake, the first major update to Android, which dropped in May 2009. Cupcake was packed with new features, but perhaps the most significant was the virtual keyboard, which paved the way for buttonless blowers such as the HTC Magic.

What you get:

• Shortcuts and widgets on the home screen meant our mobiles could now be obsessively tweaked and personalised.
• An on-screen keyboard meant tapping virtually could replace typing on the real thing, making phones lighter and leaner.
• Video recording was added to the camera, and the ability to upload videos straight to YouTube helped fulfil our dreams of stardom.
• Stereo Bluetooth lets you listen to music without wires.
• The Web browser gets a speed boost and the copy and paste function.

Android 1.6 Donut

In October 2009, we bit into Donut. It offered fewer major improvements, now that most of the key features were in place. But it brought Android to a new crowd, thanks to the addition of support for CDMA -- the technology used by some American mobile networks.

What you get:

• The universal search function helped us pinpoint our apps and contacts on the phone, or jump to searching the Web.
• Support for more screen resolutions opened the door to Android phones of different sizes.
• Google Maps Navigation added free turn-by-turn sat-nav.

Android 2.0 and 2.1 Eclair

We didn't have to wait long before Android 2.0 arrived, a mere month after Donut, in November 2009. Eclair reached out to the suits with support for Microsoft Exchange server, which most businesses use for email.

Android 2.1 Eclair arrived in January 2010. It fixed some bugs and let app developers play with more features, but it didn't add any features for users. 

What you get:

• Exchange support, so you can finally get your Outlook email. There's also a unified email inbox. However, it's still kept with POP and IMAP email in a separate app to Gmail.
• Support for multiple Google accounts lets you stock up on all your Gmail.
• Camera settings including support for a flash, digital zoom, white balance and color effects.
• Searching within text messages and MMS messages.
• Multi-touch support in the on-screen keyboard helps it figure out what you're trying to say if you accidentally type two letters at once. The dictionary incorporates your contacts so you get people's names right, too.
• The Web browser gets a refresh with a new address bar and thumbnails for a sneak peek at your bookmarks.

Android 3.0 and 3.1 Honeycomb

Honeycomb expanded Android to fit the big screens of tablet computers. This version of Android is a separate branch that's only for tablets, and will never come to phones.

Android 3.1 was announced in May 2011, and adds a peck of user interface refinements to Honeycomb. We haven't tested this version yet, but Google writes that the tweaks will make "UI elements easier to see understand and use". Widgets will also gain the ability to be dragged bigger or smaller, to suit your screen. Android 3.1 also adds support for plugging USB flash drives into your tablet to transfer files without connecting to a computer, as well as USB keyboards, mice and joysticks.

What you get:

• A blue wire frame design gives Honeycomb a Tron-inspired look.
• Home screens appear to rotate on a 3D carousel as you swipe through them.
• Widgets are bigger and bolder to suit the tablet-size screen.
• The hardware buttons -- home and back -- have been moved on to the screen as virtual buttons that move with you as you rotate your tablet. Meanwhile, the app menu is re positioned to the upper right-hand corner. There's also a new button that fires up a list of currently running apps, visible as thumbnail images.
• Key apps, such as Gmail and YouTube, are heavily redesigned to take advantage of the space available.
• The Web browser introduces tabbed browsing, a feature familiar from desktop browsers such as Chrome. There's also an incognito mode to browse on the quiet.
• A larger, multi-touch keyboard lets you hold down multiple keys to temporarily switch between letters and numbers, for example.

Android 4.0 Ice Cream Sandwich

Ice Cream Sandwich (ICS) was announced at the Google I/O conference in May 2011. We had to wait until the Samsung Galaxy Nexus landed in our laps in December before we could see it first-hand. ICS was designed to merge Gingerbread -- Android for phones -- together with Honeycomb, which was designed for tablets.

Below are top 10 reasons why ICS is better than Gingerbread. 

• Browser
• Declining calls with a text message
• Better data usage management
• More app storage space
• Better camera software
• New Action Bar
• Face unlock
• Widget previews
• Improved folders
• Live Effects

What you get:  

• A speedier, smoother browser.
• A data traffic monitor to help you avoid busting your network data limit.
• More storage space for apps.
• A new user-friendly action bar replacing the Menu button.
• Face recognition for unlocking your phone.
• The ability to decline calls with pre-penned text messages.
• And most fun of all, live video effects for making your mates look grotesquely disfigured.
• One drawback is the fact that ICS lacks support for Adobe Flash, but it's no longer such an issue since the company has already confirmed that it's dropping support for it.

Android 4.1 Jelly Bean

Jelly Bean, announced in June 2012, may not be a big jump in version number, but adds a host of important updates to Android. Here are the features you can expect to see in Android 4.1.

What you get:  

• Google Now, an assistant tool that displays relevant information based on your search history and location data.
• A higher frame rate makes swooping through menus and home screens feel buttery smooth.
• View photos you've taken quickly by swiping from the camera to filmstrip view.
• Widgets and apps politely move out of the way when you add new ones.
• Notifications now include more information, such as photos or subject lines in emails.
• Search results can now display answers to questions, rather than simply a list of Google web links.
• A new gestures mode to improve accessibility for blind users, letting you navigate the UI using touch and swipe gestures, in combination with speech output.
• The first device to run Jelly Bean will be the quad-core, astonishingly cheap Google Nexus 7tablet. If you want more information on this version of Android, check out our in-depth guide to Jelly Bean.

Continue to Android Testing