Tip 15: Don't test your own software or write your own test plans.

Do you have dedicated testers where you work? Possibly not-not many companies do. Many companies say they "can't afford such a luxury." Well, in my opinion, they're a luxury that's really worth it (as many of the leading software development companies in the world already know).

Independent testers should (and often do) exhibit the following characteristics:

Are impartial

Are less informed about the usage and the type of input your code expects

Are usually more knowledgeable about the usage and the type of input your code doesn't expect

Are more likely than you to spend time trying to break code

Are typically more leery of your interfaces and more critical of your coupling

Are into doing you damage and breaking your code

Are more informed than you about system limits

Unlike you, actually want to find bugs in your software.

From time to time, Microsoft talks about its ratio of developers to testers: around 1:1. You do the math; for every programmer there's a tester. In fact, rumor has it that some developers occasionally get shifted to being testers. This could happen if a developer consistently develops very buggy software. Nothing like a shift to testing to improve one's knowledge and appreciation of what good solid code involves.

Define constants using a TypeLib or an Enum.

When you create error values try not to use the so-called Magic Numbers. Thirteen is such a number, as in Err.Raise Number:=13. What does 13 mean? Basically it's a pain to resolve, so attempt always to use more meaningful names.

Visual Basic doesn't come with a set of symbolic constants defined for its own errors so I thought I'd put one together for you. Here's a snippet: