One thing I’m known for amongst many of my oldest friends is being willing to repeatedly tackle a problem. I will bang my head against a wall until it caves or I do. I’m not one to feel particularly bad about failing at something, nor do I tend to spend a lot of time caught up in self-recrimination. I’ll take a moment to assess what happened and what I could try differently and then get right back to it. I’ve got my limits, of course. I won’t keep tackling a problem I know I can’t solve and I’ll eventually give up for at least a while to rest if I’m feeling particuarly worn out by my efforts, but my limits for this kind of repetition and effort are much more expansive than most people I run into. This is one of the qualities that has made me a good software tester. Unlike a lot of my peers who will write up what they saw and move on if they can’t reproduce the issue quickly, I will (when the situation calls for it) dig in and keep messing with things until I either figure it out or I feel like I’ve done my due diligence. This is an ever-moving goal, unfortunately, but it’s still something I and my coworkers have come to count on. If there’s ever a tricky little bug with a lot of finicky details and no clear cause, I will usually be sent in to figure it out because I will just keep trying stuff without letting it wear me down. It’s worked so well in the past that everyone on my team knows me for this quality at this point, for better or for worse. They can always count on me to do whatever needs doing in as exacting detail as it needs (if not maybe a little too exacting sometimes).

Unfortunately, this quality being applicable in a professional context, especially one that has grown to rely on it, is a pretty significant source of frustration for me. For instance, I’m currently working on chasing down a problem that has now claimed fourty-five of my working hours (which I know thanks to detailed time-logging we do for a tax break!) and everyone has mostly just left it to me to work on since they know I’ll keep at it until it gets figured out and they’ve all exhausted all of their ideas while I still keep coming up with something new to try. This absolutely sucks for me because it is exhausting to just be doing the same thing over and over again, the problem is even more finicky and random than anyone thought, and it is all contingent on a huge combination of factors being present that we explicitly forbid customers from creating in their systems if they want their systems to work. I’m pretty sure the only other person in existence who gives a shit about this incredibly specific and unlikely-to-occur issue is the software developer who wrote the software I’m testing and that’s only because he’s a perfectionist (in the worst sense of the word). At this point, the only reason I care about it is because I’m being paid to care about it and I am so tired of it that I’d rather do just about anything else than continue to endlessly (and frequently mindlessly) pick at it.

But that’s what happens when you find a potentially ruinous bug, even if it’s not something likely to happen. You have to figure out exactly why it happens so it can be fixed or have guardrails put around it. Something this potentially bad can’t be left alone, even if it might only happen because of conditions that only exist in a lab, especially if the means of fixing or undoing it are also only easy to do because the issue showed up in a lab at the hands of people who know the system better than any user likely ever will. The nature of the job requires you to spend the time it takes to figure out the shape of the thing so the people who can fix it or build around it can prevent it from happening in the field rather than just relying on unenforceable guidelines in the user manual. It’s exhausting and frustrating and draining, but that’s why I get paid overtime. This is exactly the reason my job is an hourly position, so that I can work on this one damn problem for as long as it takes to figure out enough that a software developer can pin it down and excise it or at least hide it under a layer of paint.

Anyway, I’ve spent five whole days of work banging my head against this one thing and have routinely found that the shape of it is not what I’ve thought it was pretty much every single day, sometimes twice a day. The problem with a variable frequency issue is that sometimes a thing that happens one-in-three times doesn’t happen ten times in a row or actually does happen ten times in a row. So, when each attempt takes ten minutes and you’re working off a pretty solid pattern over the last few hours of work, it makes sense to draw conclusions and then test those conclusions. Every single time I’ve thought I had a new variable figured out, I have found at least one instance where that variable wasn’t actually relevant. Every time I thought I found a new rule, I’d come back the next day and spend the whole day discovering how irrelevant that rule actually was. After, of course, spending an hour or two talking to the software developer about what to try next based on what I learned the day before and then never getting to any of that because it is suddenly not applicable thanks to the very first test I did after that conversation. I’m just so tired of this but I can’t exactly stop and do something else since this is literally my job and there’s nothing else that’s higher priority right now. Hopefully I’m getting closer every day, at least. That’s all I can do, just hope I’m getting it figured out one tiny variable at a time…