Now if you've ever done any ice fishing, you might be familiar with the notion of "tip ups". Tip ups are fish traps. To set a tip up, you cut a hole into the ice and fasten the tip up at the surface, leaving a spring loaded red flag exposed and a short line and lure dangling below the ice surface, waiting for fish. As schools of fish, northern pike for example, migrate below the ice surface, they see the dangling bait and try to eat it, trapping themselves on the hidden hooks. Once this happens, the fish pull the lines, releasing the spring loaded flags that now pop up, alerting the fisherman that he's caught a fish. When fishing for quantity, especially during migratory seasons, fishermen will strategically place many tip ups along the routes they know fish to travel under the ice. With the traps set, they can simply sit back and wait and drink and freeze and wait some more until that first flag pops up and they can run over and pull a fish out of the frozen water. That's only the start of it though. Because many fish travel in schools, provided you have quite a few tip ups in place, they'll all start popping up one after the other and you'll find yourself frantically running about on the ice trying to pull up as many as possible in a fishing frenzy.
I find this experience to be very similar to what we do when creating and maintaining suites of automated tests. In test automation, the ice surface is our code base. It is often very vast and unknown to the tester. Your average tester only sees the surface of the ice, so it's often difficult to know and understand what's going on below. What if there are cracks and fissures forming? What if there's a whale below us that will break through the ice and eat us? What if there are a thousand northern pike swimming below and we're going hungry because we don't know they're there? As with ice, so it is with code - we need to set traps to catch as many fish lurking below as we can, only in the code base, it's bugs we're trying to catch, and we don't want to eat them. We want to squash them. Our tests are our tip ups and commits are our schools of fish. Commits are changes to the code base and with each new commit comes a new wave of potential bugs, lurking below the surface of our ice. Like our fishermen cousines, we testers have placed our tests strategically, knowing from experience where bugs like to hide and the routes upon which they tend to migrate. With our traps in place, we sit back and watch. And sure enough, it happens every single day. Those red flags (literally red lights on our build pipeline) pop up to let us know we've caught something. I throw on my hat and gloves, slide down a fireman pole, put on my proton pack and fearlessly pull those menacing creatures from the depths. Now, sometimes you get seaweed or a dead turtle, but more often than not you'll get the nasty looking spawn of hell that seconds before was ready to corrupt your database, send all your users viagra emails, and steal all your grandma's money because she still clicks 'OK' on every popup that comes into view. My job is to prevent that from happening. And it works, because I really love to fish.
