Boundary testing and wrapping; or 1,073,741,824 * 1,073,741,824 = 0
I have never been really good at math. Sure I understand basic formulas, but I rely on a calculator when I run out of fingers and toes. I am envious of people who can look at a hexadecimal or octal value and convert it to an integer value in their heads without a second thought. But, I do know that when I multiply 1,073,741,824 * 1,073,741,824 the result should not equal 0! No, this isn't some perverse bug in Calculator (calc.exe), but this sort of magic math sometimes manifests itself in the outputs of various calculations. (And there is a lot of calculating going on in even simple software programs.)
Familiarity with data types and specifically the physical linear boundaries of data types can help expose defects or explain unexpected errors encountered while testing, especially when evaluating output variables. For example, the physical linear boundary of a type int is -2,147,483,648 through +2,147,483,647 because this data type is a signed 32-bit (232) integer value. A value greater than +2,147,483,647 input into a control that only accepts a signed integer value will throw an overflow exception error. But, what happens when we have 2 input parameters that accept type int and the result of the calculation is greater than the maximum bounded value of the data type? Well, the answer to that questions depends on the data type used to store the output. For example, we should expect the result of the variable z below to be 4,294,967,294.
int x = 2147483647;
int y = 2147483647;
int z = x + y;
However, the result is actually -2! How did that happen? Since the maximum value of a signed int is 2,147,483,647, when y is added to x the number simply wraps itself within the physical bounds of the data type. If we added 1 to 2,147,483,647 the int value would equal -2,147,483,648. (In the above example, the number keeps counting positively to eventually equal -2). Hopefully, it is easy to understand why wrapping can be a bad thing! I am thinking some billionaire would be pretty upset if his/her bank balance was $2,147,483,647 and he/she made a deposit of let's say $10,000 on Monday, then wrote a check for $5 on Wednesday and the check bounced because of a negative balance of -2,147,473,649!
Historical failure indicators suggest traditional boundary type defects have a high rate of occurance any time complex calculations act on linear bounded input or output values. This doesn't imply that "most bugs occur at boundaries," (in fact that is quite a foolish notion). It simply means that empirical evidence has consistently proven traditional boundary defects are likely to occur at the edges of bounded linear variables, especially involving the output variables of complex calculations.
A real life example of a wrapping type bug can be found in Word 2007; although it is not quite as obvious as the above example. In the below example, the string is indented 5.9" to the left. 
Figure 1.
If we increase the size of the indentation to 6.0" the last character of the string wraps to the next line in the document, and this 'wrapping' is also displayed in the Preview window as illustrated below.
Figure 2.
If we increase the indentation using the numeric up/down control buttons to 6.1" or larger we get an error message indicating the indent size is too large even though the Preview window illustrates the 'g' character wrapping to the next line! (In fact, if we input a size of 6.001" or larger we get the error message.) 
Figure 3.
Hmm...OK...so it will wrap one character but not 2 or more? That's a little puzzling!!! (And yes, I know that I can append additional characters to the end of the string after wrapping in Figure 2., but that is not really relevant to the problem at hand. ) Puzzling for sure, but at least the program stopped us at some point it calculated to be "too large,"and didn't continue to wrap to a negative value as it did in Word 2003!
But, one thing I really dislike about software is when it does something, and then gives me an error message that makes it seem like I did something wrong. For example, if we reset the indentation back to 6.0" as illustrated in Figure 1, then highlight the string, and then click the Bullets button in the tool bar the string wraps to a vertical column of characters as illustrated in Figure 4. Next, we bring up the context menu, select Paragraph menu item and notice the software set the Left indentation to 6.15". So, although we couldn't manually input any number greater than 6.001" I am thinking if the software did it own its own, then it must be OK...right? But, now we push the OK button on the Paragraph dialog and we get an error message that implies we did something wrong! How can that be...we didn't change the indentation value, the software set the incorrect value? (Also notice the Preview pane doesn't even look close to what is happening...I guess that's what one would call WYSIAWYG or what you see is almost what you get.)
Figure 4.
I understand that word wrapping and word breaking algorithms are really hard especially given the complexity of the interactions between font types, kerning, bullets and numbering styles, paper width, margins, and numerous other variables. This is just used as an example of a traditional output type boundary defect caused by incorrect calculations. This example is used here to illustrate how this category of defects can manifest various symptoms due to a single root cause, and to also provide insight to you, the professional tester, as to how to think about and expose these types of traditional boundary errors.