20 Nov The Role of Testing in Creating
“Why do we need to test anyway?!” This is how many people feel in the business of creating software. One MAJOR reason is test helps us avoid problems in production! I submit that whether complex or simple, the following process is followed all over the world.
Make → Test → Use
Let’s think back to younger days. There’s a big tree, some old boards, some slightly rusty nails, and we want to make a ladder which reaches to the sky. We get to work … you use the hammer and I’ll hold the board. The first few rungs of our makeshift ladder are easy to make while we’re standing firm on solid ground. Then, however, when it’s time to go higher. We need to rely on the first rungs to nail rungs that rise higher. We take turns at first gently putting our weight on our rungs, and then jumping on them as best we can. If satisfied, now we can confidently use what we’ve made. And up and up we go. (I hope Mom doesn’t catch us before we’re done.)
MAKE Create a rung of the ladder, by nailing it to the tree
TEST Try each rung by standing on it, and then jumping on it
USE Use each rung to make another rung further up
There’s the value of testing, in living color, in real life:
The only way we KNOW something is GOOD is to try it.
The only way we KNOW something is GOOD is to TRY it. There is the value of test, right there, in a nutshell! From this profoundly simple example, we can see how we just naturally test whatever we make.
Now for an example in the software Performance Testing realm. When I was at Disney, there was a major new version of a foodservice application, which would forecast and control inventory, manage menus, and provide nutritional accountability for most of the restaurants on property. This software company had made this system and declared it would serve the needs of Walt Disney World, one of the largest single-site employers in the United States. (No need to be concerned there, right!?) Well, it turned out, in the performance testing effort, we put the system through its paces and regrettably proved that it would not be able to handle the needs and demands of Disney’s restaurants. (These shortcomings were mutually confirmed by the Data Architecture team.) So unfortunately for the company who made the software, our process actually was: Make → Test → Do Not Use.
So, you go make the software, I’ll figure out how to jump up and down on it, then we’ll use it to make the world a better place.
This is the first blog in a 3-part series. Watch out for the second blog which will discuss “The Role of Testing in Fixing”.
Author: Tom Horsfield
