Do we like lectures? May be naah….

My job entails working with some of the brilliant technical minds, across organizations, culture & geographies. Solving some of the major technical challenges, ramping-up teams on different niche technologies, for their project or futuristic requirements. One common thing, we do observe is, do really people enjoy lecturing? In my opinion, out of 8 hours a day, may be not more than 30-45 mins. What people really enjoy are activities and engagement during learning.

Referred by Debasis Das, read an article in New York Times Lecture me, Really

Happy reading.

BYOD, MDM, Consumerization (Mobile Strategies) Tips of 2013 – Part 1

Consumerization, BYOD, managing mobile devices and the cloud have been hot topics for IT professionals this year, and there has been a lot to keep up on.

Mobile devices and operating systems kept the bring your own device (BYOD) trend going strong and essential questions about how best to handle mobile strategies, mobile device management (MDM), workers’ cloud use and more. Read up on the 2013’s  most popular tips:

Tip 1: iOS 7 features for IT

Apple’s iOS 7 came out this year and brought with it some new tools for managing mobile devices and applications. Managed open in, per app VPN (virtual private network) access, an improved Volume Purchase Program and an updated MDM protocol can all help IT administrators retain control over iOS devices.

Many exciting consumer-focused features were shown at Apple’s Worldwide Developer’s Conference, but some of the real benefits of iOS 7 come from Apple’s efforts to be the mobile enterprise manufacturer of choice. From mobile device management options to per app VPN access, iOS 7 offers quite a few enterprise features that IT should get to know.

MDM in Apple iOS 7

Open in management. This Apple iOS 7 feature gives IT the ability to control which apps workers can use to open and share documents and attachments. For example, if a user receives a Microsoft Word attachment in his email and wants to open it in a third-party app, IT will have approved certain apps — such as Quickoffice — that can open that document.

Easier MDM enrollment. IT can set up corporate-owned iOS 7 devices with all their MDM requirements right away, rather than sending out the devices to the employees and having them set them up. The less time and money it takes to set up devices, the more devices that IT can procure for the workforce.

Enterprise SSO. Single sign-on (SSO) allows workers to log in only once and gain access to all their apps, including corporate-developed and App Store apps. As the years go by and companies switch to being mobile-only, users will appreciate not having to enter their username and password everywhere.

Other Apple iOS 7 features

Per app VPN: This feature configures apps to connect to the virtual private network (VPN) upon launch. It’s another tool that should make IT happy, but there are questions around how per app VPN works in conjunction with an MDM system.

Many company-developed and third-party apps need to have code within them to be managed by MDM. The per app VPN feature may allow IT to manage iOS 7 devices without any special code, or perhaps every time users open an app, they’ll be prompted to sign into the VPN. Plus, there may be differences in security measures; some MDM tools sandbox and encrypt data in different ways, and most VPN applications just protect a URL or path for data to travel over securely.

Third-party app data protection: Data protection uses workers’ passcodes to build a strong encryption key so data is secured without any additional configuration by IT. Apple says that all third-party applications have data protection enabled by default, which means that data stored in applications downloaded from the App Store is protected by users’ passcodes until they unlock their iOS 7 devices. This Apple iOS 7 feature could ease the security fears of some IT departments, but questions remain about the level of encryption of data stored in the cloud.

Improvements to Mail: The native Mail experience keeps getting better. With the Mail app in iOS 7, users can view PDFs, sync notes with Outlook and organize smart mailboxes — that is, group messages that meet a certain criteria, such as those from a specific email address. But if the note syncing happens through iCloud, that could create a point of concern for IT.

Post to continue with other tips.

F# – Programming Language

F# (pronounced F Sharp) is an open-source, strongly typed, multi-paradigm programming language encompassing functional, imperative and object-oriented programming techniques. F# is most often used as a cross-platform CLI language, but can also be used to generate JavaScript and GPU code.

F# is developed by the F# Software Foundation, Microsoft and open contributors. An open source, cross-platform edition of F# is available from the F# Software Foundation. F# is also a fully supported language in Visual Studio. Other tools supporting F# development include Mono, MonoDevelop, SharpDevelop and the WebSharper tools for JavaScript and HTML5 web programming.

F# originated as a variant of ML and has been influenced by OCaml, C#, Python, Haskell, Scala and Erlang.

More about F# at: http://www.tryfsharp.org/

Android Testing – Part III

Also be sure to check an app’s effect on battery life. Many users expect a phone’s battery to last an entire day, at minimum. And with phones performing more and more tasks, battery life is stretched ever thinner. If an app sucks more than its fair share of power it will be ditched by users. To be sure an app isn’t a power hog, would recommend both a normal use test and an idle use test.

Normal use test: Start on a full battery and use the application for 6-12 hours and measure the battery level at the end of each ½ or 1 hour. You may use an automated testing tool to do this so as to keep the test running for the required time interval. This test will tell you how quickly your application drains the battery when in ‘normal’ use, with all the foreground and background features of the application running normally.

Idle run test: Turn off the screen lock and power saver modes. Then start on a full battery and keep the application running on its main, home or dashboard screen as appropriate, and measure the battery level at ½ or 1 hour intervals. This test will measure the battery drain due to such things as intentional or unintentional automatic screen refreshes, and due to the background threads or services running in your application.

5. Common Issues

In addition to the regular testing considerations, a handful of issues pop up across the Android world more regularly than we’d like. Be sure to test for these common bugs across multiple devices pre-launch.

Special Characters: If the app includes a search field or data entry form, test its special characters compatibility. Depending on the programming language, special characters can cause the field to choke. This is especially important if the app is going to be used internationally or with a native language that includes special characters (such as Spanish).

Long Strings: Long strings of characters are more of a fringe use case. Nonetheless, it is important to make sure an app can handle at least moderate length strings of characters. Let the type of data field – and the assumed typical entry – dictate an acceptable length.

Tap and Hold: Even if an app isn’t designed to support the long-hold copy and paste function or the tap and hold move function, make sure it isn’t confused by those actions either. Even if users don’t perform these functions intentionally, it’s very possible that they’ll get distracted and accidentally hold the screen for too long. You don’t want the app to freeze or crash as a result of this real-world scenario.

Virtual Keyboard: The majority of Android devices are touchscreens with virtual keyboards. If a user accidently – or intentionally – raises the keyboard on their device the app screen can distort or, worse, the app itself can become unusable.

These are a handful of common bugs Android users encounter every day, so being sure your app isn’t tripped up by them before launch can give you a leg up on the competition. When testing, remember to think like an end user and test how the app responds to potential real-world situations. Even if an app isn’t designed to support a function doesn’t mean a user won’t try – and be angry if the app crashes.

6. Android Security

It’s no secret that Androids are susceptible to malware – largely because of the open nature of Google Play and the presence of unmonitored, third party app markets. Couple the consistent malware reports with users’ increasing interest in privacy, and an accidental security slip up can be disastrous to your app’s success. At the very least, be sure an app successfully accomplishes these six key security factors:

  • Confidentiality: Does your app keep your private data private?

Integrity: Can the data from your app be trusted and verified?

Authentication: Does your app verify you are who you say you are?

Authorization: Does your application properly limit user privileges?

Availability: Can an attacker take the app offline?

Non-Repudiation: Does your app keep records of events?

It is also helpful to have white hat security experts attempt to manipulate at least the most common security vulnerabilities, such as accessing data due to unsafe storage or transmission practices, cracking inadequate encryptions and unlocking hardcoded passwords. If an app is easily hacked it probably will be hacked.

Finally, test an app’s access to device APIs (such as contacts, photos, camera or GPS). According to the tenants of the Open Handset Alliance (which Android is a member of), “An application can call upon any of the phone’s core functionality such as making calls, sending text messages, or using the camera, allowing developers to create richer and more cohesive experiences for users.” However, when stories about Path “secretly” accessing users’ contacts sparked insight into this common practice, users started becoming more concerned with apps accessing unnecessary personal data. To avoid incurring user ire, test that an app clearly prompts users to grant access permission during download or launch. With so much competition in the app market, it is easy for users to find a replacement that they feel does not unnecessarily invade their privacy.

7. Useful Insights

Testing is an art, so everyone does it a little differently. Still, the best testers aren’t afraid to learn new things and pick up new pointers. Here are a few tips to help you test and to keep you in the mind frame of the end user.

When capturing videos of an app under test, it’s useful to hold each action and leave each screen displayed a little longer than you would in normal use. This makes the video easier for test managers and developers to follow and possibly pinpoint which action went wrong.

Digging through Google Play reviews reveals which issues users hate the most. Here’s what a recent look tells us:

  • 40% complain about installation
  • 16% complain about performance
  • 11% write about app crashes
  •  3.5% report hangs or freezes
  •  2% complain about the UI
  •  1% had security or privacy issues

Bad reviews can kill an app before it even gets off the ground. Thorough testing of these six known problem areas can help you avoid poor reviews.

Emulators are helpful for early stage functional testing, but it is extremely important to test apps on real devices. A keyboard and mouse cannot adequately simulate touch screen usability. And some features, such as accelerometer response or location mapping, simply cannot be tested on a stationary emulator.

Though testing on Android presents a bigger challenge than most operating systems, it is not going away or simplifying any time soon. By knowing the challenges of Android testing, you can adequately address known issues, launch better apps and keep all your users – no matter what device or platform version they’re on – happy and satisfied.

Android Testing – Part II

2. Screen Size and Density

In comparison to the extremely controlled nature of iOS, the combination of screen sizes and screen densities in the Android universe add an extra challenge to app testing. Helpfully, and despite there being more than 200 distinct devices, Android classifies all official devices into one of four screen sizes and one of four screen density classes.

  • Screen sizes: Small, Normal, Large, Extra Large
  • Screen Density: Low dpi, Medium dpi, High dpi, Extra High dpi

Since testing on all devices is nearly impossible, these classifications will give testers and developers a good idea of how the app will appear on devices within the same screen size/density category. A recent breakdown of active devices looks like this:

 

Low dpi

Medium dpi

High dpi

Extra High dpi

Small Screen

2.3%

 

2.5%

 

Normal Screen

0.7%

26.2%

58%

0.9%

Large Screen

0.3%

3%

 

 

XL Screen

 

7.4%

 

 

 

As you can see, the most popular devices are squarely in the normal screen size range and generally sport either high screen density or medium density. This data is updated fairly frequently on the Android Developers website, so check it often as more devices hit the market.

3. Platform Versions

Android supports and tracks ten platforms/versions ranging from “Cupcake” 1.5 to “Ice Cream Sandwich” 4.0.4 (I am slightly outdated). Not all devices support all platform versions and new versions are not released to all handset makers at the same time. Instead, new releases are dripped out in increments, often leaving users eagerly waiting.

Despite being the most recent version, Ice Cream Sandwich is only the third most used platform and still has not been rolled out to all devices. “Gingerbread” 2.3.3 continues to dominate Android devices with 64% of use and “Froyo” 2.2 comes in second at 19%. Ice Cream Sandwich comes in third by only 1% (over “Éclair” 2.1).

By testing an app exclusively on the latest version you will isolate an extremely high number of users. Conversely, if you do not update an app to work consistently on newer releases you may lose current users as they upgrade. With so many platforms present on Android devices it’s important to test apps on at least the top three versions – if not the top four or five. To pinpoint the most popular versions visit Android Developers Platform Versions page, which tracks devices active in Android’s Google Play market.

WHAT TO TEST

As with all mobile app testing, common functions should be tested on as many devices as possible to ensure consistency. However, Android’s device and platform combinations present new challenges – a feature that functions perfectly on one device may cause a bug on another. In addition to normal testing considerations, there are a number of recurring issues that commonly crop up on a variety of Android devices. These issues are prevalent enough that they should be added to test cases on as many devices as possible.

Common Considerations

These functions may seem like no-brainers when it comes to testing, but skipping one can spell doom for an app.

a. Registration & Login: Testing should make sure the registration and login processes are intuitive, easy to complete and functional from start to finish. It is important to have testers on a variety of devices complete the entire registration and log-in process to ensure everything runs smoothly and no error messages occur.

b. Menu Options: Often times, menu options can be difficult to access and decipher. Make sure that menu items like Help, About, etc. are easy to find and navigate. This is especially important to test on a variety of screen sizes and with real users, since fingers are much larger than a mouse on an emulator.

c. Keys: Any problems related to scrolling, text selection, the back button, etc. are bound to lead to trouble, so make sure your key functionality is clear and consistent. Also, be sure to check that the app will function consistently using both a physical keyboard and touchscreen.

d. Interruptions: How does the app behave when the device battery is at full strength, medium strength and low strength? What about if the user gets an incoming call or text? If there is another app running in the background? These are all real life scenarios that users are going to encounter. Don’t let them take down your app. (Crash logs are particularly helpful in diagnosis if other events are adversely effecting an app.)

e. Error Messages: Your error messages should be clear, concise and actionable. “Error 12a26q” may make sense to the developers, but it doesn’t help users know what went wrong or how to fix it. Make your error messages easily understandable and you’re a step ahead of virtually all mobile applications on the market today.

f. Landscape v. Portrait: An app’s functionality and usability should not be affected when changing from portrait to landscape mode. Test to be sure buttons, fields and menu options are easily accessible and functional in both situations.

g. Settings: Change a device’s settings and repeat necessary tests to ensure an end-user’s custom settings won’t affect the app’s performance.

Also be sure to check an app’s effect on battery life. Many users expect a phone’s battery to last an entire day, at minimum. And with phones performing more and more tasks, battery life is stretched ever thinner. If an app sucks more than its fair share of power it will be ditched by users.