"As a small QA team of one, I manage the entire QA process from planning to execution."
Hi everyone!
I’m the newest member of the team, Nina (she/her). I joined the BMG team in January, and have been doing my best to “hit the ground running”.
THE LOWDOWN ON NINA
A little about me; as a child and teen I wanted to be a comic book artist! My passion for design turned into a passion for fashion design, and I went into adulthood with the intention to study Japanese and fashion design. This quickly spiraled into a passion for social anthropology (specifically food anthropology and cyborg anthropology). After completing study in 2020, I got an opportunity to do some game testing, and a few years later, I’m here now!
PLAYTIME
As a child I played a LOT of Pokemon. I was fortunate enough to receive a GameBoy Colour and a copy of Pokemon Silver, and I was obsessed. As I got older, it was PS2 games, whatever my dad had purchased (mostly SSX3!). While I played games a good amount of my spare time (don’t ask how many thousands of hours I have on Sims), I never considered myself to be a gamer. In fact, until a few years ago my Steam account only had 2-3 games! (I favoured consoles for the games I did play). Getting into this industry as a career has been what really allowed me to expand my game-based interests.
A DAY IN THE LIFE OF QA
It’s hard to show off my work, since the bulk of it takes place in spreadsheets, HacknPlan and various other documents, but what I can do is tell you what my day generally looks like. The first thing I do is download the latest build, and do a smoke test. A smoke test involves going through key areas of the game quickly, to ensure that the build is going to work for further testing. For example, if that day I am going to test save states, and the smoke test finds that saves aren’t functioning, I know I cannot execute those tests on that build! If any of these major issues are found (often “blockers” - issues that block testing/progression in the game), I immediately notify the team and provide a bug ticket.
After I have an appropriate build to test on, I go through any tickets that have been sent back to me from the team. These can be issues which have had fixes implemented, or issues that the team cannot reproduce. I retest all these issues to confirm if the issues are fixed, and perform tests to ensure related areas are not impacted by the bug fix.
From here I move on to either writing test cases or executing test cases. As a small QA team of one, I manage the entire QA process from planning to execution. Test cases involve testing a specific scenario, such as placing a road from one tile to a tile one level above, and ensuring the outcome meets expectations. Understanding what these expectations are is very important, so I can spend another part of my day reading through documentation from others in the team, or asking questions about functionality. When a test case fails, I produce a bug ticket.
MEMES AND CHAOS
As a natural result of my work, I find a lot of strange bugs and have a lot of chaotic ideas for posts and memes. I find this helps break up the day, and can provide a bit of entertainment for us all! Here is a sample of some of my fine work (pictured right):
COMING... EVENTUALLY
Finally, a lot of my time lately has been spent planning playtests! While I cannot say much at this stage, keep an eye on our Discord in the coming months.
See you in my next dev blog 👋
- Nina
