My First Project Blocking Bug
When I first became a tester, the company I worked for had found one of the many ways of building software that encouraged bugs in their thousands of all shapes and sizes. Quality was someone else’s problem. We had overworked developers from a third party, a big centralised test team and little access to product management, aside from overworked proxy business analysts. The solution itself was a disaster technically too, written in a language affectionately know as ‘tickle’, without a unit test, design pattern or discernable architecture in sight. Raising bugs was an every day occurrence, well every hour of every day if we are going to be honest. Most bugs were thrown into the yawning void of HP Quality Center, never to trouble us again. Not this one though, turns out there are bugs and there are bugs with an extra special number of legs.
This company wanted to offshore some of its operations to, ahem, optimise their tax burden as that’s what gambling companies do. Terrible industry, doing terrible things for terrible reasons, happen to be building terrible software. I’ll let you draw your own conclusions. However, as I was newbie tester, I was delighted just to have a job in software to be honest, so I shushed all those little voices and tested as hard as I could. Turns out, I may have tested too hard, as all that stood between the company and their offshoring was a bug. Raised by me. It was known internally as ‘Ash’s Bug.’ Weird how the bug became attached to the person.
Looking back, the bug was beautiful. It worked on newer browsers, but was intermittent on an older set of browsers that were still in use by a chunk of the customer base. It was regarding a timed AJAX call, too many calls too close together and the transaction failed on the front end, but might still be completed on the back end. Which would result in money being taken without a front end confirmation. There was no perfect value for the timed AJAX call interval either, just values that would get you less failures.
Fast forward to today and I would be delighted by such a bug. Trying to explain such a nuanced little beastie as a new tester to ‘The Business’ was terrifying. ‘The Business’ included the CEO, who really wanted to be the CEO of a multinational very soon and enquired as to when the bug would be fixed. I decided against my best Michael Bolton (the tester) impression and explaining the finer details of what influence the tester has on fixing bugs, I promised to work overtime with the developer to come up with a decent fix. We decided that if the front end errored the least we could do was to make sure the transaction failed in the back end. So we didn’t fix the bug as such, just made it the least disastrous it could be.
Turns out the shared trauma between the developer in question and myself led to a few stealth improvements, earlier builds for earlier feedback without the threat of an avalanche of bugs for example. We just had to make sure no one knew we were collaborating. Every small act of trying to build software better is a rebellion, or it sure feels like it sometimes.
As for the offshoring, it all went ahead. An early start, downtime and a data migration as it was the olden days. As the quality of the software was dreadful, we had to nurse the system along in its new offshore home, with various disastrous incidents in the first few days until it all settled. Turns out that the bugs we knew about were not as scary as the ones we didn’t. A good lesson for me to see in action I think. I sleep soundly now knowing that there are more bugs out there than I could dream of. And I love them all equally now, known or unknown.