Testing the application

How many times have you used a commercial software application, only to have it bomb out on you at a crucial moment? Most likely, the problem was caused by insufficient testing that didn't catch all the bugs. All nontrivial software has bugs, but in the best software, the bugs are simply more obscure. As you'll see, you sometimes must work around the bugs in Excel to get your application to perform properly.

After you create your application, you need to test it. This is one of the most crucial steps; it's not uncommon to spend as much time testing and debugging an application as you did creating the application in the first place. Actually, you should be doing a great deal of testing during the development phase. After all, whether you're writing a VBA routine or creating formulas in a worksheet, you want to make sure that the application is working the way it's supposed to work.

Like standard compiled applications, spreadsheet applications that you develop are prone to bugs. A bug can be defined as (1) something that does happen but shouldn't happen while a program (or application) is running, or (2) something that doesn't happen when it should happen. Both species of bugs are equally nasty, and you should plan on devoting a good portion of your development time to testing the application under all reasonable conditions and fixing any problems that you find. In some cases, unfortunately, the problems aren't entirely your fault. Excel, too, has its problems (see the "Bugs? In Excel?" sidebar).

Bugs? In Excel?

You might think that a product like Excel, which is used by millions of people throughout the world, would be relatively free of bugs. Think again. Excel is such a complex piece of software that it is only natural to expect some problems with it. And Excel does have some problems.

Getting a product like Excel out the door is not easy, even for a company like Microsoft with seemingly unlimited resources. Releasing a software product involves compromises and trade-offs. It's commonly known that most major software vendors release their products with full knowledge that they contain bugs. Most of the bugs are considered insignificant enough to ignore. Software companies could postpone their releases by a few months and fix many of them, but software, like everything else, is ruled by economics. The benefits of delaying a product's release often do not exceed the costs involved. Although Excel definitely has its share of bugs, my guess is that the majority of Excel users never encounter one.

In this book, I point out the problems with Excel that I know about. You'll surely discover some more on your own. Some problems occur only with a particular version of Excel - and under a specific configuration involving hardware and/or software. These are the worst bugs of all because they aren't easily reproducible.

So what's a developer to do? It's called a workaround. If something that you try to do doesn't work -and all indications say that it should work - it's time to move on to Plan B. Frustrating? Sure. A waste of your time? Absolutely. It's all part of being a developer._

What about Beta Testing?

Software manufacturers typically have a rigorous testing cycle for new products. After extensive internal testing, the pre-release product is usually sent to a group of interested users for beta testing.

This phase often uncovers additional problems that are usually corrected before the product's final release.

If you're developing an Excel application that more than a few people will use, you might want to consider a beta test. This enables your application to be used in its intended setting on different hardware (usually) and by the intended users.

The beta period should begin after you've completed all your own testing and you feel that the application is ready to distribute. You'll need to identify a group of users to help you. The process works best if you distribute everything that will ultimately be included in your application: user documentation, the installation program, help, and so on. You can evaluate the beta test in a number of ways, including face-to-face discussions, questionnaires, and phone calls.

You almost always become aware of problems that you need to correct or improvements that you need to make before you undertake a widespread distribution of the application. Of course, a beta testing phase takes additional time, and not all projects can afford that luxury._

I probably don't need to tell you to thoroughly test any spreadsheet application that you develop for others. And depending on its eventual audience, you might want to make your application bulletproof. In other words, try to anticipate all the errors and screw-ups that could possibly occur, making concerted efforts to avoid them - or, at least, to handle them gracefully. This not only helps the end user but also makes it easier on you and protects your reputation. Also consider using beta testing; your end users are likely candidates because they are the ones who will be using your product. See the upcoming sidebar "What about Beta Testing?"

Although you cannot conceivably test for all possibilities, your macros should be able to handle common types of errors. For example, what if the user enters a text string instead of a numeric value? What if the user tries to run your macro when a workbook isn't open? What if he or she cancels a dialog box without making any selections? What happens if the user presses Ctrl+F6 and jumps to the next window? When you gain experience, issues like these become very familiar, and you account for them without even thinking.

0 0

Post a comment