Salutations! Welcome to this month’s installment of the QA Blog: Bugs, Bugs and Beyond! [Working Title]. Today, we present a look at the QA process itself via the lifecycle of the bug (to give it its proper Latin name, Qaticus Mebur Bugis).
The QA process begins when a bug is discovered:
As you can see here, the Ping indicator is supposed to be accompanied by a golden decal. In the bug pictured above, the decal wasn’t displaying at all.
Right now, we have up to four sources of bug discovery: the internal QA team, the external QA team, the development team, and the Defense Council. We have many eyes looking at the game at any one time, and two full teams dedicated to finding issues.
The initial bug report is important, but it’s only the starting point. When a bug is found, it must be verified. This means checking that the steps required to trigger it are valid and that the bug itself can be reliably reproduced. Being able to reproduce a bug is vital, as will be explained in the next step. If a bug is discovered, it will be verified twice – once by the external team and again by the internal team. We gather whatever information we need to make this verification happen, including asking the reporter for additional documentation, or experimenting on our own.
This stage can take minutes. Or hours. Or even months. It can involve just a single playthrough, or maybe dozens. Whatever it takes, it gets done.
Bugs are also prioritized at this stage. Not all bugs are created equally! There are many factors that ultimately decide how bugs are prioritized, and those can change from month to month. Generally speaking, though, any bugs that crash, interrupt or damage the normal operation of the game are given higher priority.
Finally, an internal bug report is generated and immediately sent to one of the main developers.
This is the stage where the bugs meet their demise. When the developers aren’t working on new content for the game, they spend their time addressing bug reports. Some bugs are simple fixes which can be resolved in minutes, whilst others can be very complex and require the assistance of multiple departments.
It’s important at this stage that the time of the main developers is not wasted. A coder, for example, cannot afford to spend an afternoon trying to replicate a particular issue – his or her time is better spent actually coding. This is why verification is vital, and why sometimes bugs are checked over numerous times by numerous people before they ever reach any of the main developers.
When a bug is resolved, the internal QA team is notified, and they repeat the verification process, ensuring the bug is fixed. They send it to the external QA team, and when both teams sign off on the bug fix, it is resolved.
After the Ping indicator bug was eliminated, we verified that the decal was displaying properly in game.
In this stage, we consider the bug fixed and the matter resolved.
We keep records of all the bugs that are handled by the main developers, as sometimes bugs can reappear at various stages of development. Keeping track of them will generally help expedite the process in the future.
So that’s it. The complete lifecycle of the Etherian native bug, the humble Qaticus Mebur Bugis. Until next time!
Leave a comment to get your hands on the Dungeon Defenders II pre-alpha! You have a full week to leave a comment. We’ll pick a random poster and reveal the winner next Friday. Don’t have a forum account? It takes less than a minute to join!
Also, the random winner of our Hero Deck blog is going to be chosen on Tuesday, so there’s still time to enter!