26 Nov The Role of Testing in Fixing
Okay, so you’ve created a working software system, but then some functions aren’t working properly in production. How is testing useful when it comes to fixing things that are already made? Here’s a powerful, yet simple pattern to leverage.
BAD → Test … Fix … Test → GOOD
When things go bad, first employ test to PINPOINT where the problem is. After applying a fix, then test to PROVE that the system is fixed. Without test, we wouldn’t KNOW anything. We wouldn’t KNOW the extent of the problem, and we wouldn’t KNOW if we were good to go.
Recently our Subaru Forrester, when turning the key, had been starting quite sluggishly. My first thought, no surprise living here in Florida’s heat, was “the battery”. The person at the local auto parts store was kind enough to come out to the parking lot and test our battery using a handheld unit which looked like a multimeter on steroids. The dude pushed quite a few buttons, a lot of progress bars whizzed by, and then his declaration, “It’s bad”. I asked, “Does it tell you any details about the battery? How much charge does it have? How close to death’s door is it?” His reply, “Nope. It just says, ‘bad battery’.”
Okay. Simple can be good. So, we bought a battery at Costco and installed it ourselves. Turned the key. Yikes! A little sluggish. But after that, as good as gold. Yes! Knowing that the battery was bad didn’t rule out a bad alternator, but we did KNOW the battery was bad. So how does this fit with our pattern?
BAD Car had been starting poorly
Test (Pinpoint) Because of testing, we KNEW for sure the battery was bad
Fix Buy and Install a new battery
Test (Prove) Rely on the new battery to start the car several times
GOOD Woot! Car is running with confidence!
What is the moral here? Don’t fret about what the problem might be. Spend a little time, dig in, and get some good, reliable knowledge using reasonable tests. Sure, it might be expensive or a hassle to fix. (Don’t get ahead of yourself just yet.) Test what makes sense to test, and eventually, you’ll pinpoint the problem. As the saying goes, a problem well defined is often half solved.
In the world of software systems, if there are problems in production, you may only need to run one test to confirm the problem is in the non-production environments, but other times you’ll need to run part or all your functional regression tests to identify all the functionality that is broken. If you have System Performance issues, then spike, endurance or load tests need to be designed and run to locate and flush out the problem. Once identified, these issues can be fixed. And wouldn’t you know it, it’s worth running another test to prove we’ve fixed the system.
Go fix those problems before they get worse. And remember, Test – Fix – Test, because test really is your friend. Otherwise, you’re just shooting in the dark.
This is the second blog in a 3-part series on The Role of Testing. The third installment will be, “The Role of Testing in Avoiding Failure”.
Author: Tom Horsfield
