Remember the old saying, “Everyone is talking about the weather, but nobody is doing anything about it?” That’s pretty much the case when it comes to using the cloud as part of a software QA process.

In research conducted by SD Times in July, we asked, “At what stage is your company, or companies that you consult, using the cloud for software testing?” Very few respondents indicated that they use the cloud in this way:

At what stage is your company, or companies that you consult, using the cloud for software testing?

We are using the cloud for software testing on a routine basis 7.9%
We are experimenting with using the cloud for software testing 17.3%
We are studying the technology but have not started yet 26.7%
No plans to use the cloud for software testing 39.6%
Don’t know 8.4%

When it comes to software quality assurance, what happens in Vegas stays in Vegas most of the time. Or to put it more clearly, the activity usually but not always is conducted by the organization’s employees:

Does your company outsource any of its software quality assurance or testing?

Yes, all of it 4.4%
Yes, some of it 26.6%
No, none of it 65.0%
Don’t know 3.9%

There’s no one favorite model about where testing lives. Is it part of the development group? Is it separate? Is it sometimes separate and sometimes integrated? The answers were surprisingly evenly split.

Does your organization have separate development and test teams?

All test and development teams are integrated 30.2%
All development teams and test/QA teams are separate 32.7%
Some development and test/QA teams are separate, some are integrated 34.6%
Don’t know 2.4%

Enterprise developers can’t simply throw the code over the metaphorical wall once it was completed and let other IT staff take complete responsibility for quality assurance – even after deployment.

We asked, “Who is responsible for internally-developed application performance testing and monitoring in your company?” with separate answers for prior to deployment and after deployment. The answers showed that developers still responsibility after deployment – and sysadmins were in the loop during the development process.

Who is responsible for internally-developed application performance testing and monitoring in your company?

Software/Application Developers prior to deployment 60.8%, after deployment 47.7%
Software/Application Development Management prior to deployment 52.8%, after deployment 53.8%
Testers prior to deployment 50.3%, after deployment 41.5%
Testing Management prior to deployment 48.7%, after deployment 38.5%
IT top management (development) (VP or above) prior to deployment 36.7%, after deployment 34.6%
Systems administrators prior to deployment 24.1%, after deployment 45.4%
Networking personnel prior to deployment 21.5%, after deployment 31.5%

When it comes to software quality assurance, one thing is for certain: We are all in it together.

At the Google I/O 2012 conference, the Internet giant announced the availability for its Chrome browser for both Android and iOS devices – both tablets and handsets.

The next day, I was able to install the Chrome browser for iOS immediately onto an iPhone 4 (a device released in June 2010), an iPhone 3GS (released June 2009) and an iPad 2 (released March 2011).

Chrome for Android was also available immediately for the Google Nexus 7 tablet given to each attendee of Google I/O 2012. When I went to install it onto a Samsung Galaxy Tab 10.1 (released February 2011) it didn’t work. It also didn’t work on my older HTC Evo phone.

As a teenager would say, “You can run Chrome on a three-year-old iPhone but not a one-year-old Android tablet? Epic fail.”

Take a look at the requirements. In the Mac ecosystem, Chrome requires iOS 4.3 or later. That version of the operating system was released in March 2011, but could be user-installed onto older hardware.

By contrast, the Google Play store says, “This app is incompatible with all of your devices” and indicates that Android 4.0 (Ice Cream Sandwich) or above is needed. It’s the very rare machine that can be upgraded from Android 3.x to Android 4.x. And thus, you have the incongruity that a three-year-old Apple device can run Google’s feature-packed browser, but a one-year-old Android tablet (heralded as a showpiece by Google!) cannot.

This is going to hurt Google in the long run, if they continue to leave operating system upgrades in the hands of the device makers, and if they let hardware makers orphan handsets and tablets so quickly after they are released.

Microsoft, of course, is orphaning everyone who purchased a Windows Phone 7.x handset, because those phones won’t be upgradable to Windows Phone 8.x. However, I feel confident that this is a one-time break from the past. Also, Microsoft, like Apple – but unlike Google with Android – is keeping in control of the upgrade path.

It’s bad enough that Android devices offer different user experiences depending on which hardware maker you prefer. The look and feel of an HTC is light years from that of a Motorola or Samsung phone.

When even Google’s own apps won’t work on older machines, most of us lose. Who is the winner? The lack of backwards-compatibility and customized user experiences suits the needs of the hardware makers – not consumers, developers, or even enterprise customers. I’m sure they like this situation just fine.

The past few weeks has seen a lot of excitement in the mobile space. This past week we had Google I/O, where we got a first look at Android 4.1 “Jelly Bean,” which offers solid improvements. The previous week Microsoft unveiled Windows Phone 8 – a near-total relaunch that will excite future customers and ISVs, while disappointing existing Windows Phone 7.5 customers. This is comes on the heels of Apple’s World Wide Developer Conference, which highlighted iOS 6’s new social media integration, home-grown mapping engine, and faster browser engine.

All of these platform upgrades are due to ship in 2012.

We also heard from Research in Motion about a delay in its already-pushed-back BlackBerry 10 smartphone operating system. It’s now scheduled for the first quarter of 2013. The company also lost a ton of money in the past quarter. It’s reasonable to predict that BlackBerry is toast, or soon will be.

Let’s dig a bit deeper into the three, uh, more viable smartphone platforms – and what they mean for us.

Apple’s iOS 6 is merely an incremental upgrade. Apple has moved from Google’s mapping system to its own Maps engine, which is fully accessible via APIs. You can also integrate Facebook into apps, tap into the Reminders system, go closer to the hardware with the camera, and leverage an improved WebKit rendering engine.

The good news is that from the developer perspective, not much has changed; you get some new capabilities, but if you don’t need them, you don’t need to do anything.

Existing Apple customers won’t be standing in line at midnight to download iOS 6 – but they will appreciate its upgrades. That’s because Apple continues to win the award for best support of older hardware. All current iOS devices, including iPhone, iPad and iPod touch, should be able to run everything in iOS 6. Most features will run on the 2011’s iPad 2 and even 2010’s iPhone 4.

Microsoft’s Windows Phone 8, code-named Apollo, is a huge, huge, huge upgrade. Everything changes. It’s a real reboot, as the platform moves from the Windows CE kernel to the Windows kernel (either x86 or the new Windows RT kernel for ARM processors). For the first time, Windows Phone can run on multi-core hardware and use screens larger than 800×480. Because the WP8 kernel is the Windows 8 kernel, WP8 phones should work with any Windows 8 device driver. That should let you do some pretty interesting hardware integrations – and gives WP8 a huge advantage of iOS and Android.

Near Field Communications (NFC) is a big part of WP8, as it is with Android. iOS still doesn’t get NFC – but I expect Apple to catch up fast, perhaps with the next-generation iPhone and an iOS 6.x update.

Most importantly for apps developers, you can also write apps in C/C++ or even use the .NET framework with C# or Visual Basic. That truly enables code migration to the mobile platform.

The bad news is that WP8 will require all new hardware. The only upgrade for existing WP7.x users (including those who just bought the much-hyped Nokia Lumia 900 phone)  is a cosmetic upgrade called Windows Phone 7.8 that improves the Start Page with new colors and three sizes of Live Tiles. Beyond this small enhancement, every existing Windows Phone customer is out of luck until their carrier’s contract lets them buy a new phone. Ouch.

Google’s Android 4.1 Jelly Bean is another incremental upgrade, similar in scope to what Apple is doing with iOS 6. The biggest change is called Project Butter, which improves the dreadful synchronization of the touchscreen with screen composition/refresh. This, along with improved triple buffering should go a long way toward eliminating common complaints that the Android UX is sluggish, unresponsive or even buggy, when it’s simply out of sync.

Another area of improvement is notifications – where you can provide more info to the end user, and even let them respond without switching to your app. You can more easily communicate with devices connected via USB or Bluetooth, access the NFC stack, and work with a better HTML5 renderer. A popular feature should be an upgrade to Ice Cream Sandwich’s message queuing service. Called Google Cloud Messaging, the system can now deliver up to 4K of data – and can leverage multicast.

We don’t know which existing Honeycomb (Android 3.x) and Ice Cream Sandwich (Android 4.x.x) devices will run Jelly Bean. This is determined largely by each hardware maker on a model-by-model basis. If past experience is any guide, some existing Android handsets or tablets will be upgradeable to Android 4.1, but most will be orphaned.

That’s a shame — but it’s better than those poor Windows Phone 7.x owners can expect.