Identifying boundaries
Boundary value analysis is one of the most popularized testing techniques out there, and rightly so. It yields results. Most people think of a simple example when they think of boundary value analysis; like a field with a maximum character limit of 20 characters and visible character limit of 10 characters. We know that the field has three explicit boundaries: 0, 10, and 20 characters.
What's often more interesting to me, are the other boundaries related to that field. For example, it's likely that whatever value I enter is going to get stored somewhere. The variable where it's stored has boundaries based on it's datatype. If it's stored to a database, the field has boundaries. If it's stored to a file, the input and output programs that read and write the value expect certain boundaries. If it's ever rendered on the screen, it's rendered based on certain assumptions about it's boundaries. And certainly any processing done using the value includes boundaries (whether the programmer was thinking about them or not).
All of this leads to some interesting analysis of what we really mean when we say we're doing boundary value analysis. We're really looking at all of those various places where a boundary might exist. We're also looking at the potential interations of those boundaries with other variables within the system, and often we won't know what those are right away. Recently, I tried to illustrate some of the complexities of this in an example I did using Microsoft Word. In that example, I tired to model the boundaries related to bullets and numbering.
Here are some of the high-level things I think about when doing this type of analysis:
What's often more interesting to me, are the other boundaries related to that field. For example, it's likely that whatever value I enter is going to get stored somewhere. The variable where it's stored has boundaries based on it's datatype. If it's stored to a database, the field has boundaries. If it's stored to a file, the input and output programs that read and write the value expect certain boundaries. If it's ever rendered on the screen, it's rendered based on certain assumptions about it's boundaries. And certainly any processing done using the value includes boundaries (whether the programmer was thinking about them or not).
All of this leads to some interesting analysis of what we really mean when we say we're doing boundary value analysis. We're really looking at all of those various places where a boundary might exist. We're also looking at the potential interations of those boundaries with other variables within the system, and often we won't know what those are right away. Recently, I tried to illustrate some of the complexities of this in an example I did using Microsoft Word. In that example, I tired to model the boundaries related to bullets and numbering.
Here are some of the high-level things I think about when doing this type of analysis:
- What boundaries can I see (explicit)?
- What boundaries can't I see (implicit)?
- What boundaries exist around persistence?
- What boundaries exist around business processes and interaction?
- What boundaries are shared with other variables?
- What boundaries can be modified or configured (meaning they're variable, not static)?
- What boundaries exist in relation to time (get reset, race conditions, etc...)?
- What external boundaries influence this boundary (like the size of a disk or size of a piece of printed paper)?