Business owners are hearing a lot about why they should build mobile apps: they’re great tools for marketing, good for building brand loyalty, useful for customer retention, practical for gathering customer data.
Sure, but an app can really backfire for your company if it doesn’t work, gets bad reviews, or creates problems such as security breaches.
Kevin Surace is CEO of Appvance, a company that provides app testing and validation. He says it’s a huge mistake to launch your new app without testing it first. And he says your app developer is not the person to do that. Yahoo! Small Business spoke with him about why and how you need to test your mobile or web apps before launch.
Your company tests mobile and web apps for performance and security risks and can determine the root cause of bottlenecks when there are millions of users. This doesn’t sound like a service for the typical small business owner.
Today, there are small companies that put out apps—startups that don’t have 5 people in them—and suddenly have 1 million users. This is a different time than it was 5-10 years ago. An app can be seen and interacted with by tens of thousands of people much more rapidly than you thought. We see lots of apps and sites fail when only 1,000 users sign on.
What’s going on when an app fails with only 1,000 users?
Most developers have no experience in scalability. They don’t know what performance testing would be. They don’t know about load balancers and database configurations and a whole bunch of other things. Why would they? They developed your site, they threw it on WordPress, and off you go. Or they developed a native app for you, you got it on iOS and Android, and you got it approved at the iTunes and Google store.
Then users start giving you one star. Why? They waited 10 seconds and they said this thing sucks and they exited. You don’t want one star, no matter how small or large a business you are. You can’t just rely on your app developer to give you an app that gets five stars. Being a five-star app has to do with the quality of the app and the content, way it looks, and its performance, as healthcare.gov clearly found out.
So you need to hire a developer who also knows how to do performance testing?
You don’t want your developers doing your testing. That’s the fox watching the henhouse. Your developers don’t want you to do testing, because that will find things wrong. I’ve never seen anyone do performance testing that passes. Ever. Eventually they pass after fixing their code for several weeks.
OK, then in addition to hiring an app developer, you need to hire someone to test your app?
You have to do unit testing. You have to do functional testing. Ask, “do all the features work the way they’re supposed to?” And then you have to say, “What happens when I put 1,000 people on this as opposed to one?”
Your app, especially your native app, could freeze up with only five people using it because it was expecting things to come back from the server in a certain order and they no longer happen in that order. You have no way of knowing that before launching, because your developer isn’t going to put 100 people on it, and he’s not going to test it for performance. Why would he?
Testing performance and scalability are things you should be doing all the time no matter the size of your app usage. It’s just part of the process of developing an app. You develop, you test, and then you test for functionality, performance, and scalability. And then you launch.
There’s a message here for small and medium businesses: You should be demanding functional, performance, and security testing from your vendors. You can’t just say, “Go develop this app, thank you.” You won’t get any of those things and you will get an app with functional, performance, and security problems. I can guarantee it.
So what happened with Healthcare.gov? Was it not tested at all?
You hit it. Believe it or not, they did their functional tests. And QSSI, which was the sub to the main contractor CGI, admitted they didn’t know how to do, nor did they intend to do, performance testing. They didn’t even have time to do performance testing. So the day they launch, millions of people get on and the entire things collapses. Um, yes, of course. It was never tested for that. Who knows if it was written for that?
QSSI had never written anything that was that scalable. Why would they know how to make it scalable? Even teams who do write things that are that scalable don’t know how to make the next one that scalable because there are always differences.
You cannot rely on coders to make something scalable. They code and then you rely on testing to make it scalable. Scalability and performance testing tells you where your problems and bottlenecks are. The government’s subcontractors failed to do that.
Now, the President shouldn’t know that level of detail; arguably, even the head of Health and Human Services shouldn’t be at that level of detail. But it’s a real wakeup call to everybody that you shouldn’t be putting apps out there without functional, performance, and security testing. It doesn’t matter if you’re a big brand or a small brand; you’ll destroy your brand if something goes wrong.
What do you mean, specifically, when you talk about security with regard to apps?
I’m talking about app penetration—the ability to penetrate an app. Forget the network; that is pretty well secure these days. But app security, app penetration, has become the number one issue in the last two or three years.
Over 85 percent of break-ins occur at the app level, not the network level. And the reason is that the app has access to your full database—proprietary information, customer information, credit card information. Of course the app has to have access to that, because that’s what the app was built to do: interact with that. If you can break into the app as the bad guy you can get all the good stuff and you don’t have to break into the network, which is really hard now.
So app penetration testing should always be done. It’s called “white hat testing.” We happen to do that as a feature of our performance testing. Other companies do that too.
You do functionality testing to make sure it functions as you want, you do performance testing to make sure it scales and that it has reasonable transaction times that scale. Performance testing will show the scalability index; it shows that the app slows down at certain levels. But if it slows beyond a certain point—like a few seconds to respond—then customers leave. And they don’t just leave your app, they leave your brand.
And then there’s security testing, because app penetration is the way people steal your goods. They’re going to try to break in.
What about some of the more publicized break-ins lately. For instance, was the Target security debacle due to an app penetration?
No, that was a very unusual situation. There, your credit card was safe if you used their app. It wasn’t safe if you used their stores. That’s because their POC terminals where you swipe your credit card have an open source real time operating system. Everybody had access to the source code, so it was very easy to break into the Target system and drop in a little code so that every time someone swiped a credit card it sent information to the bad guys about your card. It was quite insidious.
Fair warning to all: All of your systems that take that information may not be secure. In this case it wasn’t the web app that was the problem, it was the actual hard credit card reader in the stores.
What’s an example of an app fail at the small business level?
I have many. For instance, I had a client that was not a huge business launch an app that was a contest for their users—not simply a commerce app. The whole thing slowed down so much that it turned into really, really bad reviews for them. What could have been a great, exciting product launch turned into a disaster. I also have examples of very large businesses, such as of a bank that didn’t handle something correctly so you could see other people’s account information on your app. It only happened when you had 5,000 concurrent users.
I want to educate small businesses that they need to consider the Q/A in app development. Whether they become customers of ours is not material. It’s important to teach the world that you can’t just write this stuff and walk away.
