According to the BI article, “Android Hackers Plan App Store of Banned Apps,” a group of Android Developers are looking to start their own app store for all the banned and rejected apps that didn’t make the cut.  The article includes a quote from the potential founder that, “apps removed from the Market include, one-click root apps, emulators, tether apps, Visual Voicemail apps, and more.”

It sounds great but we already know about the growing number of malware on phone operating systems, the Android especially.  The other alternative for apps is to create mobile-specific landing pages (i.e. HTML5 apps), like Grooveshark (music) and Untappd (beer reviews) have done, making the apps available via your mobile browser.  Since their launch, Untappd has launched a native app for iOS and Android but has not shared details on traffic comparisons.  [It won’t be applicable to most mobile users but we cover some security exploits and common attacks in our Security Testing whitepaper.]

Am I the only one uber-sensitive about the integrity of my phones OS and Apps?  Would you download an app that isn’t scrutinized for security?

Many consumer apps have figured out how to cater to the specific limitations of mobile devices (screen size variance, touch screen usability, the range of OS options) but professional apps are still largely lagging behind.

Quinton Alsbury (who owns a company – MeLLmo – that develops apps for businesses) highlighted where many business-minded apps are going wrong in this guest post on CNet:

We’ve all been there–squinting at a spreadsheet on a mobile device, zooming in and out in attempt to make sense of the information. Each swipe of the finger triggers a blank screen as the data renders and slowly reappears and our frustration builds. …

Why do apps aimed at business users continue to cram features and functionalities designed for the PC into a mobile phone, ignoring all the things that make consumer apps successful–namely, design, speed, and interactivity?

Many business app developers are fundamentally misunderstanding the mobile user experience by producing “shrink to fit” versions of solutions designed for the PC. The mobile experience isn’t about accessing several gigabytes of data; it’s about quickly accessing the information you need, when you need it.

By “shrinking” existing PC tools, they’re essentially jamming a large, complicated, and bulky system onto a smaller screen. What results are apps that contain too many features, respond too slowly and ultimately result in low user adoption and usage.

Information Week also recently featured a commentary piece on the bulky state of business apps. Maribel Lopez, the author, agreed that professional apps do not preform as well as most consumer apps. But she was careful to highlight some additional challenges to creating a professional app.

First, what should the company mobilize? Companies have dozens, if not hundreds, of apps, many of them custom built. … Also, the company needs to mobilize a whole process, not just an app. Mobilizing one app may allow an employee to complete only a portion of a process–finalizing a sale, for example, is often composed of transactions from multiple apps, such as CRM, inventory, and purchasing.

Second, how should I mobilize these apps? Does IT build apps that are native to the device, embrace an HTML5 mobile Web experience, or build a hybrid of native and Web? If it selects native app development, it also has to choose which mobile operating system platforms. … What companies are learning is that there’s no single software development model that works for every mobile scenario. Most businesses will use a mix of native, hybrid, and mobile Web. The decision will depend on the depth of functionality the app requires.

Third, what are the top priorities for mobile development? … Just taking an app that was created for desktop use and making it accessible on a mobile device won’t work. IT must understand what functions of the app should be accessible on a mobile device, and how much they need to be revised for mobile work.

Maribel is taking the angle of companies developing their own specialized, customized apps, but her points also apply to outside groups looking to develop a good general business-facing app. You can’t fit all the features of a desktop app into a successful mobile app – and honestly, you probably don’t need to. Maribel recommends taking a step back and starting simple:

Many businesses try to replicate the entire desktop app for a mobile device. For an initial mobile rollout, it is perfectly acceptable to pick one or two functions of the application and deliver those well. … And once the mobile app is live, be prepared to listen to employees, hear what’s missing, and quickly add new features.

That last sentence is really the key – figure out what the employees want and need, and forget everything else. A successful app is only successful because users decided to actually use it. And on that note, here’s a list from Entrepreneur of the “10 Must-Have Business Apps for 2011“:

• Square (payment)
• Evernote (task management)
• Scanner Pro (document scanning)
• Flight Tracker Pro (travel)
• MightyMeeting (presentation management)
• Gist (contact management)
• LinkedIn (contact management/networking)
• Print n Share (wireless printing)
• Jump Desktop (remote desktop)
• OmniFocus (task management suite)

These apps are fairly basic business/business person apps – nothing too specialized or intricate – but still important and useful to business in general. Interestingly, three of Entrepreneur’s top apps were also on a PCWorld top 10 business apps list in 2009 while others fulfill the same need but replaced the earlier top performers.

As the two lists prove, there’s been a fair amount of turnover in the business app market over the past few years, and that’s bound to continue. But with the use of smartphones growing and the new trend of companies allowing their employees to use their own phone, 2012 might be the year business apps catch up to the success of their consumer counterparts.

We’re 17 days away from the new year, and far before Auld Lang Syne begins playing and we pretend to know the words (after all the champagne, who can remember the lyrics we optimistically Google’d the day before anyways?), we’re pondering what changes are in store for us the next twelve months.

In a whitepaper released by ABI Research this week, their tech analysts took a collective look into the crystal ball for 2012 and (in their words) “have drawn some bold lines in the sand on a plethora of top-of-mind topics.”

But instead of predicting what WOULD happen in the mobile and telecom space, they took a different spin on the usual list and forecasted what WOULDN’T happen.  Nice twist.  (And a really good read.)

One of their more interesting predictions for those of us in software testing is by Patrick Connolly, Senior Analyst of Telematics and Navigation:  “Indoor location will NOT become commonplace in 2012.” 

It’s easy to see how this could be true…but also surprising.

After all, for as many articles that have been written about the technological challenges in making Indoor Location Based Services (LBS) a reality, there has been an equal amount of big name, big buzz announcements about it over the past few months.  There are dozens of industry-leading companies—including Apple, Navteq, Qualcomm and Nokia—tackling the challenge from every angle.

There are even some major apps launching to give Indoor LBS a jolt from vision to reality.  For instance, Google announced on their Mobile blog in November that the new Google Maps 6.0 gives users (on Android OS 2.1 mobile devices) the ability to Map the Vast Indoors, vis-à-vis:

“When you’re inside an airport, shopping mall, retail store, or other public space, Google Maps 6.0 for Android brings the freestanding map directory to the palm of your hands –helping you determine where you are, what floor you’re on, and where to go indoors. For example, in this busy travel season, you can use Google Maps 6.0 to help you find your way around airports.”

So what does Connolly think we can expect in 2012?  He proposes that there will be “isolated mobile applications and services around individual high-traffic public areas like airports and malls.”

For software testers, the proliferation of LBS (indoor and out) means it’s becoming ever critical to move a portion of the testing out of the lab and into the wild so apps can be tested in real world conditions.  After all, if LBS is inaccurate inside a mall by 100 feet—and the store we’re trying to find (hello, Cinnabon!) isn’t anywhere near where we thought it was– it might as well be off by a mile.  The ball is increasingly in our court to make sure this cool, new tech is a consumer delight… not a dud.

As an industry, we’re on the cusp of some exciting indoor location, tracking, mapping, and navigation apps that will enrich the user experience.  And we’re playing a critical role in making it possible.

We’ll toast to that.

As you’re probably aware, not every app is original. In fact, most of the apps in existence are anything but unique. Scroll through your app store for five minutes and see if you can argue otherwise.

Anyway, this glut of apps – especially copycat apps – has gotten so ridiculous that it’s got several high-profile tech bloggers essentially begging to make it stop. Here’s an excerpt from Can We Stop The Copycat Apps from Rip Empson of TechCrunch:

While I encourage developers to continue making great apps, I do question the need for both making and for approving the parade of — for lack of a better word — “rip-off” apps. What am I talking about? Example: Over the last week, I’ve watched another fairly blatant copy of Angry Birds hover inside the “Top Free iPhone Apps” list on the App Store, even grabbing the second spot at one point.

I’m not naming the app explicitly, because I don’t want to give the game free publicity. That’s what they want, and it’s probably a good idea to avoid promoting the production and downloading of spammy (cr)apps. But needless to say, the scenario is familiar: The game’s icon is practically identical to that of Angry Birds, it has “Angry” in the title, the design and gameplay — while not exactly identical — have enough similarities to make for some serious eye-rolling. Not to mention, the game is awful. One-star reviews abound.

And here’s fellow TC blogger Alexia Tsotsis, just a few day prior:

Stop making apps, or gimmicks, things that don’t solve problems. Don’t build something silly and ill-thought out just because you have a celebrity co-founder and/or lots of investor money that will help you scale initially no matter what.

The truth is that the hardest part is hanging onto that first spike of users, and there is no number of TechCrunch posts about your every-single-decimal point update that will get you there, you actually need to solve a problem – even if that problem is “How the hell do I entertain myself for the next fifteen minutes?”

Focus on building a service not just an app; a service may have an app component — like Spotify, for example — but that app component must only exist to make life easier for the user of your service, exist to add value not just to be cool.

Of course, we couldn’t agree more with these statements, especially the bolded excerpts. The great thing about all of the application marketplaces is that reputation and quality reign supreme. So by all means, go ahead and launch that copycat Angry Birds application if that’s your thing, but don’t expect many 5-star reviews (or users).

For the rest of you trying to create a functional, secure and unique user experience, start here.

Four-year  WHS Technology Teacher Daniel Downs, realized that the future of technology is moving toward mobile devices. He has created a curriculum that challenges the students in the design, implementation, and testing process using tools chosen for their superior interactive educational value. These tools such as Adobe Flash CS5 and Accelerometer programs, allow the students to achieve an unusual classroom success—the success of being able to design, implement, test, and immediately use their designs on technology already part of daily life. …

The Designing Applications for Androids class, in two months, has designed and published 32 original Children’s Games. … These are all currently published on the class’s tablet computers. Currently students are designing Apps to potentially replace the school’s paper agenda planners. …

Soon, students will conduct a survey of the entire WHS community’s mobile device application needs. Then, they will design apps to satisfy these needs. In one semester, students will have learned to design, implement, test, survey, and design for others.

Read the whole article >>>

The best part of this course isn’t that we’re getting students into official mobile app developing sooner, it’s that the class also stresses testing as an important part of the app creation process. (It’s mentioned consistently throughout the article along side design and implementation and is never glossed over).

Time and time again, expert QA professionals have said that testing needs to elevate its status within the software development life cycle and that testers and developers would be more efficient if they mutually understood each others’ tasks and actively worked together. This Winchester High School class isn’t just teaching these students that mobile app development is a viable career path, it’s also introducing them to the world of software testing and reenforcing its importance to a successful product.

And in case schools are still unsure how a mobile app design class fulfills adequate education requirements, Mr. Downs created a slide show outlining the thought process behind the class and what it teaches students. Slides 8, 12, 13, 16 and 19 specifically mention testing. In fact, Mr. Downs says, “Once you have chosen your platform and begun to create apps you will need to choose testing devices or emulators.” That’s “need,” not “should.”

Let’s hope the students take the testing message to heart and that other schools follow WHS’ lead.

Unfortunately, my four-year-old has already implored me to take down the skeleton and spiders hanging in the doorway because they’re going to scare away Santa.  So, rather than arguing the salient fact that Santa shimmies down the chimney versus ringing the doorbell, I’ve officially started morphing decor from the marvelous macabre to merry old Saint Nick.  Kids: 1. Mom: 0.

Nonetheless, the fact hasn’t escaped me that we’re two weeks away from Cyber Monday (November 28th), an occasion that online retailers have been planning for months.  Since summer, global brands and independent e-tailers have been testing and re-testing their mobile apps and web sites for functionality, usability, localization glitches and possible bottlenecks in site performance that could jeopardize their revenue potential.

Moreover, the ante has been upped now that the iPad and other tablets have entered the scene.  Online retailers that spent the last few years optimizing their mobile apps and porting them to additional platforms like Android, are now going through the process from scratch with tablets.  Not only are the specs non- standardized, varying significantly by manufacturer, device and network performance like smartphones.

But user behavior on iPads and tablets is very different than on smartphones.  Tablets require a completely different design strategy based on the high-resolution screen, the added real-estate that allows for more merchandising (but tempts marketers into overly cluttered UX’s and drop-down menus), and even the finger-swipe ability and need for larger buttons.  In the end, it equates to more need than ever for sophisticated testing, tweaking (in design and functionality), and testing again.

As Jason Ankeny wrote in FierceMobileContent this week, “The holidays are coming, and this year, there are essentially two types of people: Those adding tablet devices to the top of their wish list, and those who already own tablets–and plan to use them to complete their seasonal shopping tasks.”

So how many mobile—tablet and smartphone–consumers are we talking about?  Well, according to Prosper Mobile Insights’ Mobile Survey published last month, here’s a data slice suggesting what tech executives, brand managers, and QA teams should expect for the 2011 holiday season:

Somewhat/Very Likely to Purchase Products on Mobile Device (Mobile Holiday Shoppers)

• Thanksgiving Day: 30.1%
• Black Friday: 66.9%
• Saturday after Thanksgiving: 58.6%
• Sunday after Thanksgiving: 48.6%
• Cyber Monday: 63.5%

Mobile isn’t a “nice to have” to bring home independent and global brands’ year-end sales.  It’s a gamechanger.

Today, Alex Schmelkin wrote in “Best Practices for Tablet Commerce” on Business2Community’s site: “Ultimately, with the explosive forecast being what it is for tablets, retailers will need to continue improving their t-commerce UX optimization. Online merchants must recognize the looming changes in consumer habits and prepare for a tablet based future or proceed with negligible modifications at their peril.”

So the question for every online retailer is, Are you ready?

Our Testing the Limits “reunion tour” rolls on this month with Michael Bolton, back for another lively session of Q&A. Michael is best known as the founder of DevelopSense, his Toronto-based testing consulting firm, and as a leading figure in Rapid Testing and the Context-Driven school of testing. In short, he’s one of the industry’s most highly regarded writers, speakers and teachers – and it’s a real pleasure to have him back. For more on Michael, be sure to check out his website, blog or follow him on Twitter.

In part I of our healthy two-part interview, we get his thoughts on test cases not being related to testing; the sub-par debate skills of testers; the quality chain of command; objections to Rapid Testing and much more. Be sure to check back tomorrow for Part II. Enjoy!

uTest: It’s been almost two years since our last interview. Where does the time go? We’ve followed you pretty closely during that time (on Twitter, don’t worry), but for those who haven’t, what have they missed? New publications? New courses? New ideas on testing? What’s new with Michael Bolton?

MB: I’ve been traveling like crazy this year, and I’m booked pretty heavily through the end of the year.  I’m beginning to set up my schedule for next year—so if people would like to schedule an in-house class, now is a great time to ask.  For new publications How to Reduce the Cost of Testing, a new book edited by Matt Heusser and Govind Kulkarni, has just been released. I’m pleased to say that I’ve got a chapter in there, with a number of other members of our community.

I don’t specialize in new ideas in testing so much, but rather in refining and reframing ideas we’ve had for years in more specific and, I hope, more useful ways. The other thing that I love to do is to bring ideas from elsewhere into testing.  Currently I’m fascinated by the work of Harry Collins, who studies the sociology of science and the ways in which people develop knowledge and skill. Tacit and Explicit Knowledge is his most recent book; The Shape of Actions is older.  I’m most interested in the idea of repair, which is Collins’ notion for the ways in which people fix up information as they prepare to send it, or as they receive and interpret it.

As an example, I’m 5’ 8” tall.  If I ask you how tall I am in centimeters (and provide you with the ratio of 2.54 centimeters to the inch), you’ll probably do a little math in your head to translate 5’ 8” into 68 inches.  If you do that, it’s because you have tacit knowledge that a foot is 12 inches, and it’s quicker to do five times 12 in your head and add eight than to work it out on the calculator.  Then you’ll report that I’m 173 centimeters (or 172), rather than what the calculator tells you:  172.72.  If you round the answer up or down to a whole centimeter, it’s because you have tacit knowledge that the extra precision is useless when my height changes more than that with every breath. The calculator doesn’t know that, but people often fix up the interaction with the tool, applying that kind of tacit knowledge without noticing that they’re doing it.  Collins argues that we give calculators and computers and machines more credit than they deserve when we ascribe intelligence or knowledge to them, even when we do it casually or informally.

My latest hobby horse is definitely not new, but I’d like to have a go at it anyway.  I’d like to skewer the idea of the test case having any serious relationship to testing.  Test cases are typically examples of what the product should do. That’s important; we often need examples to help explicate requirements and desires. But examples are not tests, so I’d like to call those artifacts example cases or examples rather than test cases. They’re confirmatory, not exploratory; checks, not tests. Brian Marick has written a lot about examples; Matt Heusser has too; so has Gojko Adzic. James Bach has been railing about test cases for a long time.  Often test cases are overly elaborate, expensive to prepare and maintain.  They’d be even more expensive if testers didn’t repair them on the fly, inserting subtle variations making observations that the test case doesn’t specify.  Just as Collins suggests about machines, test cases get more credit than they deserve.  As Pradeep Soundarajan would say, the test case doesn’t find the bug.  The tester finds the bug, and the test case has a role in that.  Now: the development of checks and the interpretation of checks—those things require all kinds of sapience and skill.

A test, to me, is an investigation, not a bit of input and output for a function.  Yet people tend to think of testing in terms of test cases.  Even worse, people count test cases; and even worse than that, they count passing and failing test cases to measure the completeness of project work or testing work.  It’s like evaluating the quality of a newspaper by counting the number of stories in it without reference to the content, the quality of the writing, the quality of the investigation, the relevance of the report, whether a given article contains one story or a dozen, and so forth.  Counting stories would be a ludicrous way of measuring either the quality of the newspaper or the state of the world. Yet, it seems to me, many development and testing organizations try to observe and evaluate testing in this completely shallow and ridiculous way. They do that because seem to think about things in terms of units of production. Learning, discoveries, threats to value, management responses… none of these things are widgets. They not things, either, for that matter.

uTest: In a recent blog post, you wrote about the inability of some testers to properly frame tests, mainly because they haven’t been asked to. Generally speaking, what other qualities or skills do you find testers to be lacking in?

MB: Oh, dear, it’s so sad because there are so many gaps. James Bach, in a recent chat with you, identified rhetoric—how to speak and write clearly, articulately, and precisely—as something that many testers are missing.  Many testers aren’t so good at developing an argument (in the sense of a line of reasoning rather than a fight).  Many testers see obstacles to their work as problems for testing, when in fact they’re pretty much always problems for the project.  Testing helps to reveal those problems if you have an appropriate mind set.  (I wrote about that recently here.)   It seems that many testers, like many programmers, often lapse into the binary fallacy—something is either one thing or another, yes or no, true or false, pass or fail.

Tom Waits put it beautifully in an interview a couple of years back, when someone asked him about how he finds the truth of his character. “Truths,” he said.  “Truth isn’t a word that should be used in the singular. It should always be used in the plural.”  Rob Sabourin has been observing gaps in testers’ command of math, and how to apply it in testing.  As a craft, we seem to be aiding and abetting management in bad measurement; we need more people to study how to do measurement well. At the Pacific Northwest Software Quality Conference, I was delighted to see Kristina Sitarski—who studied anthropology in university—deliver an excellent analysis of interactions between herself and a tester she was pairing with, focusing on learning and perceptual styles.  If we want to be well regarded as a craft, we need more reports like this, based on studies of what we actually do.  We don’t need any more of the inept works of fiction and fantasy that you see in neo-Platonist process manuals.

uTest: We see that you were disappointed in the New Yorker iPad app, tweeting something to the effect of “it might have been tested, but it wasn’t fixed.” In your view, is quality lacking in the mobile space? If so, why? Is mobile inherently more of a testing challenge than its web and desktop cousins?

MB: When I tweeted that, the New Yorker app was crashing for me within a few moments of starting up.  I had to wait a few weeks while that got sorted out. The magazine as delivered to the iPad is typically on the order of 150MB in size, where (comparable product heuristic!) The Economist is on the order of 3MB.  The product would frequently crash during a download, and wouldn’t pick up where the download had left off.  Even if downloads were successful, downloading the New Yorker every week would wipe out the base amount of data consumption on my mobile billing plan.  It would be cheaper to buy the dead tree version of the magazine.

Certainly there’s a great deal of extra complexity to be dealt with in the mobile space, when we look at the number of different systems and functions through which a given bit of data passes, or the enormous number of platforms on which people want to run apps.  Before Windows came along to abstract the hardware, there were drivers for each video card, each printer, each mouse, each network card times each operating system.  But then each application program came with special drivers to talk to each kind of hardware.  Developing and supporting all that stuff was completely nuts. Since there’s a perception of lots of opportunity and lots of money in the mobile space, there’s a gold rush and lots of people are heading for the Klondike. Now there are competing mobile OSs, times all those versions of those OSs, times all those handsets and tablets and mobile browser versions and interconnecting apps and services.  So in a way, we’re back to the late 80s and early 1990s, back in the DOS days, when I first got involved with programming and support and testing.  Hey you kids, get out of my yard!

uTest: You’ve said before that “decisions about quality are inherently subjective” and that “testers are not responsible for making decisions about quality, but rather for informing decisions about quality.” So our subjective question for you is this: Should testers be responsible for making decisions about quality?

MB: Like everyone else, testers should be responsible for making decisions about the quality of their own work. But we already have lots roles and titles for people who make decisions about the work of other people:  we call them “product manager”, “program manager”, “project manager”, “product owner”, “director of development”, “vice president”, “CEO”.  I urge testers: You want to manage a project? Become a project manager.  I urge quality assurance people: You want to assure quality?  Make sure you have real, final authority over the product and the people who produce it. That is, become a manager. You’re not a gatekeeper of quality; you’re a speed bump on the road to quality.  (Speed bumps are also known as “sleeping policemen”.  That’s apt.)

uTest: You’ve been traveling the world the last few years teaching courses in Rapid Software Testing. In your experience, are certain regions of the world more open to this testing mind-set than others? If so, why do you think this is the case?

MB: It seems that Rapid Software Testing has a lot of traction in certain circles in northwestern Europe, especially Sweden, places where there seems to be a deal of room for intellectual rigor and independence at the same time.  Rikard Edgren had an interesting explanation for the success of rapid and context-driven testing there.  He said that the Swedes in particular believe really strongly in the social contract, that people are interdependent, that society should take care of everyone, that things like education and health care are rights, not privileges, and that people should reasonably expect get them at a high level of quality. And to pay taxes for them.  Although, he said, the Swedes aren’t crazy; no one likes paying taxes, but it’s part of the deal if you want all this other good stuff.  So there’s this sense of mutual support and strong government, and the Swedes (broadly speaking, of course) believe in that… but they don’t like other people telling them what to do.  When Rikard say that, I thought it fit really well with what we espouse:  We’re all in this together.  We give ourselves and each other freedom to do the right thing and to screw up.  We also take responsibility for our actions, and we take responsibility for taking care of each other.  We work collaboratively, but we recognize that few people like being under someone else’s thumb.  That kind of freedom combined with responsibility allows people to blossom, I think.  I’d argue the Baltic countries have been ahead of North America for a while in terms of politics and social issues. Rapid Testing is popular in New Zealand and Australia too, to some degree. It’s that spirit of independent interdependence, if you will.  James is excited about Estonia, too, but I haven’t been there.  Yet.  The UK has this emerging group too.  So we’re seeing shoots coming up through the snow.

uTest: In our last interview, you mentioned specifically that New Zealand and Scandinavia were producing some excellent testers with fresh insight and new ideas. Have your travels uncovered any other areas of testing innovation?

MB: When I do, they’re almost always local geographical pockets, or some skunkworks when they’re inside larger organizations.  Steve Green runs this cool little testing services company in England that focuses on skilled testers and very fast turnaround. Paul Holland has been doing rapid testing for years at Alcatel-Lucent, with excellent results. Pradeep Soundarajan is running a testing services company in India that specializes in rapid testing approaches. That company is profitable in its first year.  Darren McMillan has done some really great work in explaining the ways in which he’s been using mind mapping. Those are only some of the prominent people. Alas, NDAs, company confidentiality policies, modesty, and fear restrain people from saying too much about what is and isn’t working.

In addition, everyone does rapid and exploratory work to some degree, but I’ve never seen process enthusiasts who have actually observed processes closely enough to notice that.  If you want to observe process, you have to observe people.  Most process enthusiasts I’ve seen observe artifacts, rather than real work in action.  The Social Life of Information talks about how quickly we could find blatant errors in our process models if only we took a more diversified anthropological approach.  Don’t get me wrong; I’m at best a dilettante in that stuff myself.  But I think we have to start getting serious about it.

Editor’s note: That’s it for now. Be sure to check back for Part II tomorrow!

According to CNET:

“Developers who created their apps specifically to run on Honeycomb-based tablets will need to tweak their APKs (Android packages) to either prevent or support their installation on smaller-screen devices.

The [Google Android developers] blog also offered some recommendations for tablet app developers on how to ensure that their design of the Action Bar widget works on smaller handsets.”

Additionally, be on the look out for the release of the ICS SDK, rumored to be available in a matter of weeks. According to Google:

“We haven’t released the ICS SDK just yet, but you can start preparing your Honeycomb apps by thinking about how they should work on smaller screens.”

Well, it’s just enough to whet anyone’s appetite! We shouldn’t have to wait too much longer before we learn more. For now, I’ll save this dessert for later.

We decided to launch it at TechCrunch Disrupt in San Francisco because the very concept of in-the-wild software testing (versus traditional methodologies) is, well…disruptive. 

Sure enough, TechCrunch Disrupt turned out to be the perfect event!  There were more than 2,600 innovative, entrepreneurial-minded techies, investors and exhibitors (35% more attendees than expected) filling the halls of the Design Concourse Center from Monday to Wednesday.  In its usual fashion, the conference itself attracted top industry-leaders such as Reid Hoffman of LinkedIn, Marissa Mayer of Google, Vinod Khosla, and even Ashton Kutcher.

uTest hosted a ton of terrific activities over the course of the event:

On Sunday, we spent the day at the Disrupt Hackathon, selecting a winner for uTest’s “Most Likely to Succeed in the Wild” award, which came with a prize worth $3,000 of uTest’s services.  Wow- what a day!  More than 700 participants worked overnight and coded a record number (130!) of hacks. We watched as each of the teams mustered the energy to climb on-stage and pitch their project in the allotted 60 seconds.  The sheer breadth of creativity was impressive.  Yet, we had to make a decision, so we chose the masterminds behind AirCart, which enables grocery store self-checkout through your phone, rather than the standard dedicated checkout stand. (See pic to the right)

On Monday and Tuesday evenings, we had a special surprise for Disrupt.  In order to promote in-the-wild testing, we sponsored the urban Serengeti-themed “In the Wild Oasis” RVIP, a mobile karaoke lounge created in a renovated Winnebago.  Sounds crazy and fun?  It was!  (The RVIP is the brainchild of Kestrin Pantera, who by the way, sounds dead-on like Susan Sarandon’s ‘Janet’ when she karaokes Rocky Horror.)

During Happy Hour, we were parked outside the front of the Concourse Center, where people climbed aboard, checked it out, had a drink, and started relaxing from the day.  From there, the RV– blanketed in lights and glowing like Chevy Chase’s house in Christmas Vacation– took to the ‘wilds’ of SF, providing shuttle service for folks to their hotels. But mostly getting a whole lot of smiles and laughter from people on the streets.

By 9:30 both nights, we’d arrived at the official TechCrunch after parties at 1015 Folsom (sponsored by Bridgewater) and Roe (sponsored by MailChimp).  Parked there, we partied through the night…usually until 2:00am.  Throughout the two nights, hundreds of Disrupters had climbed aboard, to have a drink, chat and network in the RV’s lounge.  Some groups had stuffed themselves into the photo booth for pics. 

And almost everyone karaoked.  How could they not?  When the entire RV is rocking from the dancing, and the whole crowd is singing Wild Thing, Hotel California or Rock Lobster…it’s impossible to resist!  Even TechCrunch reporter Jason Kincaid hung out and belted some tunes (btw: He has a great voice…who knew?).

As we’ve been known to say at uTest, “We take our jobs seriously.  But not ourselves.”  Disrupt was a great example.  People learned about in-the-wild testing and our business ideas, and we learned about theirs.  We connected with customers, old friends and partners, and made new ones.  And we all had a blazing good time.

Until next year…!

For many more photos, visit the TC Disrupt page on www.inthewildtesting.com or uTest’s Flickr page.

In fact, a few months ago we wrote about The Top Security Hacks of 2011, and referenced that the attacks on Playstation were estimated to have cost Sony $24 billion dollars– nearly 10x their revenue for the same period.

So here’s the point: Would you rather look back and say your company overshot and used too many systems for security testing?  Or get that nauseaus, sinking feeling in your gut when your CIO wakes you at 2:00am and says the company has spent too little?

That’s why– as the cornerstone of uTest’s showstopping announcement yesterday– we announced the launch of uTest Security Testing that leverages the talents of new and existing white hat security professionals within our crowdsourced community.  Since we now offer the first crowdsourced, real-world security testing in the world…there’s a new kid in town to join the collective effort to protect your company, and customers’, private data.

Moreover, we’ve joined forces with industry leader Veracode to provide seamless access to their complementary, cloud-based application security verification services.  Veracode has scalable, policy-driven application risk management programs that help identify and eradicate numerous vulnerabilities by leveraging best-in-class technologies from vulnerability scanning to penetration testing and static code analysis.

As a result, companies will have access to a cost-effective, powerful combination of automated (Veracode) and real-world (uTest) testing that mitigates security risks across the entire software development lifecycle.

We’re thrilled, honored and excited to be partnering with Veracode.  And we’re certain that our joint offering– as a complement to organizations’ in-house security testing– will offer tech executives peace-of-mind at a price with infinitely fewer zeroes than $24,000,000,000.