Independent testers should (and often do) exhibit the following characteristics:
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:
Public Enum vbErrorCodes VBErrReturnWithoutGoSub = 3 VBErrInvalidProcedureCall = 5 VBErrOverflow = 6 VBErrOutOfMemory = 7 VBErrSubscriptOutOfRange = 9 VBErrThisArrayIsFixedOrTemporarilyLocked = 10 VBErrDivisionByZero = 11 VBErrTypeMismatch = 13 VBErrOutOfStringSpace = 14 VBErrExpressionTooComplex = 16 VBErrCantPerformRequestedOperation = 17 VBErrUserInterruptOccurred = 18 VBErrResumeWithoutError = 20 VBErrOutOfStackSpace = 28 VBErrSubFunctionOrPropertyNotDefined = 35 . . . End Enum
Once you've added it to your project, this snippet is browsable via Visual Basic's Object Browser. To see how you might define constants using a type library, see Chapter 7.