What you should expect during the testing phase of your web or mobile app? Before we go into the testing phase of development, let’s take a minute to talk about the difference between a demo and a final product.
Demo vs. final product
Too often, developers push out a demo in a few days, and then everyone expects that the final product will follow a few days later. In truth, software products look a lot like an iceberg – it’s only 10% that you see on top, but to make it work there’s 90% under the surface that you’ll never see. Unless you’re a porpoise or something I guess. This underwater part of the iceberg is what you’re going to start running into in the testing phase, and it’s why your testing phase will usually take a percentage of the total development time. The bigger the project, the more test time you’re going to need to find bugs and fix them. In any project, it’s an important phase to go through.
However, some products are more difficult to test than others. For example, I come from the storage world, 6 9’s of reliability (rather than 100%) just means you’re going to go out of business. In the web world, it’s not as bad because you can make changes quickly. Mobile is somewhere in between, where you have to wait for submitted apps to reach your end users, and wait for them to run the updates. Also, remember that in projects dealing with money or security, the test time is going to increase. That’s just the nature of the beast when you’re dealing with people’s money and/or something that’s likely to get hacked (a security product, for example).
It’s a little like Whack-a-Mole
Now, once you’ve started testing, understand that you’re going to go through phases. With each set of fixes, there is the potential that something else has been broken. This is what I call software whack-a-mole. Smack one of those guys and another one pops up somewhere else. Assuming you’re developer knows what they’re doing, that process will continually decrease until you feel secure you’re releasing a quality product. NEVER release a product immediately after your developer has just made a change. You’re going to be tempted to rush something out the door, but the price you pay is always worse when you find out that 100,000 users downloaded your iOS app on the first day and it crashes on everything but the iPad… the thing you had your last bug on. Taking the extra time will almost always be a little frustrating, but honestly, that’s the price we pay for quality. Get a developer who encourages you to just get the product out there too soon, and you may pay for it in customers when your first release is hated by everyone you just marketed to – or for mobile applications, everyone who just gave you a crappy rating in the app store.
If this is for a mobile app, I strongly recommend going through a beta test phase. The best apps on the app store usually have gone through a rigorous beta test phase where not only do they find other bugs, but they find things users hate. Do this right, and you have the potential for a really nice pop on your release day. Miss it, and you’ll spend a lot of time in recovery. Once you’ve gone through the cycle, you’ll usually have a few bugs that you’ve decided are low enough priority (aesthetic or what have you) that you’re going to go ahead and release.
Get it through your testing phases and it’s time to add features, fix bugs you missed on the last version, and generally keep improving your product. Watch this video to learn everything you need to know about testing web and mobile apps.
