All of last week’s chickens have come home to roost. The letter I sent got responses, the work I was doing has come around back to me, and all of my crafting in Final Fantasy 14 has culminated in my plans for tonight. I’ll write more about how all that goes later this week, I’m sure, but suffice it to say that I’ve been very productive and, after lots of effort, I’m finally ready to actually make the gear itself. I’m also going to hold off on writing more about my letter responses and my subsequent therapy session for a bit longer, until I’ve had the time to process it all a little while longer. Instead, today I’m going to talk about the absolute nightmare that is this one bug I found at work. Thankfully, I found it and, since it’s my job to do that, things are going well for me in terms of my career. This will not pose any problems for me in that direction and will more likely be a feather in my cap than a hindrance since I found a horrible problem in an unorthodox way that would surely have eventually happened in the field but might otherwise have never occured in a testing environment. It’s just going to be a lot of work for me and I can’t even take satisfaction in foreseeing a thorny issue since I just sort of bumbled into this. I mean, I absolutely made the decisions that resulted in me learning that it’s possible to burn out an essential component of this product in a way that is safe but only because it renders the entire thing unuseable, but I didn’t think it was going to go poorly. I was actually looking for something unrelated that I still haven’t pinned down, but such is the life of a tester. You do a lot of inexplicable or unlikely things and stumble into bugs you never could have anticipated.

Adding to the weight of this issue is that, to eventually test it, I’m going to need to do quite a bit of tinkering to fix the essentially bricked testing units. It’s all gummed up (not literally) and I’m going to either need a lot of luck or probably a great deal of force to get it unstuck, remove the burned-out component, and then even more luck to get the new one in place. I’m operating in a location that I can’t both look at and work on, due to the unfortunate limitations on how normal arms bend, but I’m pretty good at doing that since I’ve got very good spacial awareness when it comes to my body and the things I’m interacting with. I don’t mind doing this kind of work most of the time. I enjoy getting my hands on physical objects rather than spending my whole day poking at touchscreens or interacting with software, but I’m not excited about sitting on the floor in all the dust and the grime and grease to get at all this stuff just so I can finally start testing agian. I mean, there’s other ways to get at the burned-out components, but it would require a much more laborious disassembling of the entire thing and would turn this two-to-four hour task into a two-day undertaking. Better to just get dirty, sweaty, and done than waste an entire pair of days. Especially when all I’ve got left in my work week is a pair of days.

The problem with all of this is that I want to test the software that uses this component for a while longer than I have. Sure, the behavior that burned the component out in the first place has been fixed (and was easy to prove was fixed, thanks to the nature of the issue), but now I actually want to find out what happens when I leave one of these errors going for a long period of time. It shouldn’t burn the component out this time, but it also shouldn’t have done that the first time, either. I’d really like to know that I’m not just going to be burning out more components before I swap out the destroyed ones so I don’t have to put all this effort in again. I’d also prefer to avoid destroying these components since we’ve got a limited number of them on-hand and ordering more would be a pain. A justifiable pain, of course, and one no one would think twice about, but it feels very wasteful to me to risk destroying more components when I could put in some time before swapping things out to find out if I’m risking the new stuff for no good reason. I understand that I am, perhaps, one of the only people concerned with reducing waste and not destroying things more than necessary (which is funny to write out considering how often I advocate for destructive testing and how often I’m denied because it would be wasteful or my manager doesn’t agree with me about the need to run that test) and that such costs are a blip on the radar of a 9-figure revenue company, but I also don’t want to have to swap all this crap out again. It’s a pain in the butt.

A pain in the butt that is, nevertheless, my job. Still, there’s no reason to make my life more difficult than it needs to be and being able to anticipate and work around potential negative outcomes is a skill of mine that apparently not a lot of poeple have. Better to run the tests where swapping out a destroyed component takes a minute or two than to need to spend two hours and chew up my poor hands to do it. That’s the purpose of a test jig, after all. Make it easy to test most things in a way that proves most problems won’t occur even if I can’t actually test things under real-world circumstances. Most problems don’t need real-world circumstances to reproduce, any way. Usually once you figure out what went wrong, you can figure out how to reproduce it on a test jig (which is usually the second step of my bug-reporting process: write up the problem as I’ve observed it on my proper testing units and then attempt to reproduce it under much more controlled circumstances on a test jig to prove or disprove my theories about what’ going wrong). It also usually lets you operate at a scale or volume you can’t work at using real-world units. I mean, I’ve got three “true” units, only one of which is actually using current parts, and one of those three hasn’t been functional in over a year. My test jig, though, has the maximum number I can incorporate into a single system, allowing me to do a lot of testing I just couldn’t do with real-units. None of it is terribly complicated, but there is a lot of this information that I’m realizing would probably take an entire blog post series to write about. Maybe I’ll do that someday: write a week’s worth of posts about testing and how that all works. It’s not as simple as it sounds, even if it isn’t super complicated, but then again, I’ve also get almost twelve years of experience doing this kind of stuff so maybe that’s my expert bias showing. I’m sure I’ll figure it out while writing this future blog post series.