It’s bad when you have to pull an application because of some major bug. But when you have to do so within minutes of releasing the software, you’re in the middle of a disaster. That’s what happened to Google.
The company launched its Gmail app for the iPhone and iPad. Just one problem: A bug “broke notifications and caused users to see an error message when first opening the app.” That was after Google announced how the mobile app would deliver better email speed and efficiency.
Google wasn’t the only company that has faced glaring product glitches. Apple had released the iPhone 4S only to find a significant drop in battery life. After a month of problems, the presumed solution reputedly still left some phones with a power problem.
Both these major technology firms had the sorts of belly flops that, in an internal IT context, would make corporate executives shake their heads and wonder how quickly they could hire a new staff. With a computer science degree you’ve gained the knowledge of how to not only write code, but find the problems. However, you have to test thoroughly enough to find them in the first place. In particular, you must be smart about what could go wrong and catch the most obvious problems early.
IT departments need an approach to testing that is similar to what is done with cloud-hosted applications. If you’re running software on a cloud hosted by Amazon or Rackspace or some other vendor, you don’t have the access to the actual hardware that powers the code. It’s like the proverbial black box: you put something in and magically get something out. You don’t see the mechanism.
To test products in such an environment means indirect indicators. You don’t measure whether the bit rate on a particular network link has slowed or if there’s a bottleneck on a RAID array. Instead, you look to the user experience. Have things slowed down for the user? How bad is the lag? Is business getting closed as quickly as usual?
Many IT departments focus testing on internal performance of software and how it interacts with a server, network, or storage. But no matter how clean that may seem, an unexpected error message that pops up the first time a vice president fires up the new application can render it meaningless.
Even though internal testing is critical, have someone look at the application through a new user’s eyes. Look for anything that will jump out at the user, including interface glitches and obvious faults in operation. Getting the user-facing part right doesn’t make up for any other problems, but it does help preserve relations with other parts of the company and keeps confidence from eroding.