System Boundary Diagrams sometimes come up in the context of a Use Case and sometimes in the context of Software Testing. Either way they are a useful in the effort expended when determining what to test. While the ‘normal’ System Boundary Diagram shows the boundaries of the system and thus the boundaries of the testing, we try to use it only as a starting point for other diagrams that may also aid in defining the testing effort and scope.

The initial System Boundary Diagram shows the systems that are in scope and the interfaces to that system. Clearly we are testing the systems that are in scope and those interfaces. Unless there is a compelling reason to extend the testing, we would normally stop at that point and consider the rest to be out of scope.

However, we can also use other diagrams provided they are available to us. A data flow diagram can certainly aid in writing test cases that look at data and how it is treated throughout the system. A hardware diagram can make sure we have tested all the pieces of hardware that may be used in the final system or put them into our testing environment. A data dictionary, while not strictly a picture, can make sure we have considered all fields in the system and made sure (via inspection) that they have the right characteristics. If there are multiple layers to a system then a diagram at each level can help in testing that level, depending on how critical it it.

The other aspect of drawing diagrams is to ensure that the system designer does understand the system and all its components. The act of drawing a diagram tends to make that clearer to them.

As has been often said: “A picture is worth a 1000 words”. 

Discussion Questions

  1. Have you used a System Boundary Diagram?
  2. Was the System Boundary Diagram useful?
  3. Did you have trouble acquiring the System Boundary Diagram?

Next Week: Training