Debugging Software

I guess the question is “who isn’t going mobile?” When enterprises woke up on Jan 1 and found that in Q4 well over 100 million smartphones and 25 million tablets were shipped –whether they liked it or not, they were not just “going mobile” but running to catch the train.

We’ve been watching the mobile space for about a year and as recently as last summer, mobile application development for our enterprise customers was more of an horizon event than a current project. But now, we’ve clearly reached a tipping point–what a difference 6 months makes.

With smartphones and tablets crashing into enterprise IT, everything from mobile device management to mobile security to mobile application development is a number one priority. Predictably, the requirements are many and the answers are few—especially given the n-dimensional problem of hardware, operating systems, languages and networks.

This all preamble to the news that we’ve just announced two products focused squarely on mobile application development and deployment for HTML5 and JavaScript–across all device and all operating systems. Our application record and replay technology—so potent for C, C++ and Java—bridges some deep gaps in mobile application development vis a vis standard enterprise web applications. Everything from debugging to testing to security to real user monitoring and customer support reminds us of the state-of-the-art circa 1999.

In addition, there is a marvelous ecosystem of HTML5- and JavaScript-focused Mobile Application Development Platforms such as Titanium, Sybase Unwired Platform, Adobe AIR and PhoneGap—a natural home for our mobile products and where we fit seamlessly and productively. Plus Microsoft is coming with Metro.

So, we are excited about the mobile space and ReplayMOBILE and apmMOBILE are the first of a family of mobile products that will ship this year. Because of where we sit in the code execution on smartphones and tablets, we see everything from what part of the code is exercised to what works (and doesn’t) through what data flows through to “did that last dot release of the O/S just break our app?”

We’ve heard “wild west” often applied to mobile application development. Here comes the cavalry.

Check out our HTML5 and JavaScript products at

http://www.replaysolutions.com/products/replaymobile.

When light beer burst on the scene a generation ago, the biggest marketing challenge was to convince consumers that brewers could actually extract calories while still maintaining acceptable flavor. OK, that was a long time ago and now we have a full range of caloric options for beer. But every marketer (and beer drinker) will remember “Less Filling, Tastes Great”.

We will be making some exciting product announcements next week that addresses a similar kind of tension—this one in the software defect resolution space. Typically if a tester, developer or support person wants to get started on diagnosing an application bug, they’ll do some screen scrapes and a log dump but what really accelerates defect resolution are source-level root cause diagnostics. With current profilers, monitors and probe products, the tradeoff between “there’s bug in your code and here’s some logs” and “you have a fatal exception and here is the offending thread and corresponding source code” has, up until now, been very difficult to reconcile.

That’s right, up until now. Given the experience we have working deep in Java code execution and the 100% visibility into program execution that our app recording technology provides, we have come up with some very clever ways to deliver both triage speed and root cause depth in the same debug UI. The quality equivalent of great tasting light beer.

Stay tuned for some truly electrifying advancements in software defect resolution. (Hint: Sept 27).

Given the business we are in, software quality is one of our core motivations. A recent posting on STP, the Software Test Professionals site (http://www.stpcon.com/Item/1027/?utm_source=Email&utm_medium=email&utm_content=081611-TQA&utm_campaign=NEWSLETTERS) posed the question: “Can You Really Test Quality into a Product?”. The point of the article, that “doing it right the first time” is really the only guarantee of quality, harkens back to the seminal Phil Crosby quality principles that we have talked about in previous postings.

When it comes to producing quality software, it’s hard to argue against setting (and freezing) requirements, communicating them perfectly to all constituencies and then following a well-defined and monitored development process. That’s what we all aspire to. The problem is, just like with airplanes, automobiles and pharmaceuticals, the real world of complexity, human foibles and change always intrudes. That’s why testing exists—to catch defects before they get baked into the final product.

Software testing is the safety net underneath what is hopefully sound process and practice and while no one likes bug fixing, if defects are found early enough in the cycle, properly documented and communicated with enough information to find and fix them quickly, then quality will improve. It’s not the “free” quality that Phil Crosby espoused, but with the tools and techniques that are now available to QA and Dev teams, it’s less expensive that it used to be.