It’s been a few weeks since I’ve been doing this QA gig and it’s not as terrible as I thought it would be. Okay, the work is still quite grunty and below what I was previously making, but it does have its moments where it’s okay.

The main thing we’re supposed to do is log bugs. When I first applied and got asked on the interview questionnaire to define what a bug was, I think I actually wrote something technical about how something does not operate to specifications or something, but to be honest it’s more like “any kind of weird shit that randomly pops up” since literally it could be anything that’s not working properly.

The life cycle of a bug.

There’s a process (also known as a life cycle) that you go through to log bugs: basically you find it, figure out how to reproduce it (usually if you’re going through a certain process you just repeat it and see if it happens again), then you describe the problem and how it should be fixed, and it gets sent off to someone else (in Triage) to deal with. Triage is basically responsible for checking the issue and sending the bugs to the right place. After it does its rounds getting fixed or whatever, you get it back and have to verify that it has actually been fixed. If it has, you close the bug. If it hasn’t, you go around again.

Then, after that’s all done, you rinse and repeat as you find more bugs. Fun times.

Of course, it’s not challenging in the conventional sense of the work, but I actually quite like this sort of thing, because there’s a lot of pedantry and memorizing.And, with any game of “spot the difference”, there’s some satisfaction when you catch something that’s already supposed to be vetted.

Also the life cycle of a bug.