ReadWriteWeb

When developers think of application testing, it always centers around how an app will perform on a particular device. This is especially important in the Android ecosystem that has upwards of 300 devices from a variety of original equipment manufacturers worldwide. From the inverse perspective, nobody ever thinks of the testing needs of the carriers and OEMs.

Cloud-based testing platform Apkudo thought about manufacturers and carriers with a new release of device analytics platform. Manufacturers can now test devices against the top Android apps before releasing. The idea is that if a device is tested from the supplier side, fewer handsets will be returned by consumers, potentially saving manufacturers billions of dollars.

Gesture-based input is the present and future of computing. We have added whole new meanings to words like swipe, pinch, zoom and flip. For mobile developers, reconciling touch-based input with design and functionality goals in apps has become a problem. Testing gestures in an app is time consuming and problematic.

A "cloud testing" company by the name of SOASTA wants to change that. It has come out with several new products today to help developers test gesture-based input for mobile applications. SOASTA said last year that 75% of all mobile and Web apps go live without ever being scale tested. By merging the cloud and new touch modules, SOASTA believes it has evolved app testing to finally catch up with input methods.

Last month, I wrote about a startup with a win-win proposition called BetaBait, which helps beta apps connect with testers. It allows developers to list their app in an email to interested testers for free. It charges $50 for a sponsor slot featured at the top of the email. No-brainer, right?

Co-founder Cody Barbierri wrote in to let me know that, in the two weeks since launch (and it was over the holidays, too!), they added over 1,400 testers and 250 start-ups. The email was getting too long, so they've revamped the process. Only newly submitted apps will be in the email, and the rest are listed on the BetaBait site.

For several years, a company called Green Hat (not associated with Red Hat) has been in the business of creating sophisticated software testing equipment for developers, particularly for service-oriented applications that use messaging queues. The problem with distributed application testing is that it's getting more and more complicated, especially as a multitude of new and independently evolving frameworks introduce dependencies that can't always be accurately simulated in a test environment.

So yesterday's acquisition of Green Hat by IBM brought up an interesting question: Will a company whose test environments were developed to support Oracle, Java Message Service, SAP, Software AG, and TIBCO as well as WebSphere MQ continue to do so after being acquired by the maker of WebSphere MQ? Today, we have the answer.

From the blogging-as-a-service department, here's a tool I think any app development team could use. BetaBait offers a simple proposition: sign up to try new apps on one side, sign up to find beta testers on the other.

It's a free, email-driven service. When you join, you're on the daily email list, which breaks down the apps by category. BetaBait charges $50 for a sponsor slot at the top of the email, so readers see sponsor apps first. That's it. If you've got an app, there's no reason not to use it.

We haven't written much about Hatsize.com, a cloud automation-testing outfit that has been around since 2000 and is based in Calgary. Their goal is to make it easier for enterprises to do demos and set up test environments using VMs. Today they came out with a nice buyer's guide. (Free registration required.) While a bit self-serving, it still is worth taking a look at if you are considering using a cloud vendor to automate some of your own testing needs.

Testing Android applications for bugs before rolling out to the ecosystem is a cumbersome process. There are only so many things that can be tested within various frameworks like Titanium, Sencha or Eclipse. Apps crash and sometimes the developer has no idea why it crashed for one device and not another. This is especially true in the Android ecosystem that has hundreds of smartphones worldwide

Two new application testing services for Android launched today in Apkudo and FoneMonkey from Gorilla Logic. Like many of the frameworks used to create Android applications, these options are very different from each other. Apkudo takes the approach of a "device cloud" while FoneMonkey provides a graphical control console for automated tests.

SolarWinds has a new synthetic user test tool being announced today, the Synthetic End User Monitor. They are branching out to generalized IT management tools and the product can be used to test a variety of web application situations, including cloud computing, e-commerce and Web access to databases.

You can't hug every cat and it's hard to test apps on every phone, too. "One of the major challenges for [mobile] platform vendors, carriers, and handset manufacturers is how to make sure the best apps are available on their products," writes mobile developer Jason Grigsby, co-founder of a new nonprofit organization called Mobile Portland.

"One of the biggest challenges for mobile developers and businesses is getting access to devices for testing. Not even the largest of companies can afford to purchase all of the possible devices on which their software or services may run on." Mobile Portland hopes to find a solution in the place where those two challenges come together and is building what it believes will be the first community mobile device testing lab in the United States. It's a very ambitious project.

Strangeloop president Joshua Bixby decided to take a look at Steve Souders' old claim that 80% of performance issues happen at the front-end. It turns out that for desktop browsers, that number is now at around 85%. But for mobile Web browsers, the number is more like 97%. He published the results here.

Regarding how large the mobile Web's front-end response time, Bixby wrote "I expected this number to be higher than the desktop number, but not this high."