Enhancing your game with QA, part 2: Growing in-house
Developing a team of quality assurance inside your studio is at the same time promising and challenging. So what are you waiting for? Let’s gain those profits and beat the challenges!
In the first part of this series, we’ve established general principles to build a well-working relationship with QA. I have also explained the informational value of those guys. So now you know the advantage of introducing them in the planning and early design phase, including better risk awareness. I have also mentioned the general development of all teams in the project. All those rules apply to the in-house developed team — which we’re covering today — but in this specific case, a few things require going in depth.
Let’s start with the communication. As a project lead or producer, you’re constantly in touch with other teams when making and executing all plans. Meanwhile, QA keeps tabs on the game to ensure that all its parts are working and stable. Thus, there is a noticeable symmetry between the producer’s and lead QA’s work. You should be the first go-to person for your QA. So talk often. Invite a QA representative to lead meetings. Sync your information at least twice daily and more often during busy periods. While your devs are a source of all updates, QA verifies the validity of all information flowing around. Be aware of those two dimensions and your project management will get a significant boost!
Additionally, remember to use as few communication tools as possible. There is a load of various software, each with different characteristics for different uses. But let nothing tempt you to introduce additional tools to cover all single, minor cases. Just imagine — a task is discussed on a daily meeting, detailed via e-mail, discussed on Slack, micromanaged on Trello, bug tracked on TestTrack, macromanaged on a Kanban board in another tool, then someone shares important info on Hangouts while eating their lunch… looks like serious trouble. Sure, the tools you use should serve all processes but keep in mind that the more you add, the bigger is the risk of important info scattering around and being omitted.
And, of course, don’t forget about defining all steps of workflow to be followed by all devs. Describe them clearly and precisely — there is nothing worse than figuring out what is the real meaning of a task status.
Ok, so we know a lot about communication, let’s jump to the technical stuff! As I said earlier, information is the key value provided by QA. Information, to be useful, must be comprehensive, clear and precise. Remember to provide its source and task your programmers to make debug tools that QA will use. It will significantly save devs’ time on digging into causes of issues. If something wrong happens in the game when the player character is on level 43 in a Vampire Castle, provide a tool that enables quick modifications of the stats and teleports the player to a given location. And so on, you catch the drill. If your pipeline and structure allow it, consider letting QA work on the game via the engine, not only standalone cooked builds. This allows testers to investigate all issues on a very detailed level. An artist will fix a bug of an invisible land texture faster when they already know what’s wrong — is it not present in the project at all, present but unloaded or maybe its display is corrupted by another defect.
Both tools and engine access require additional training for QA but believe me — it saves a GREAT amount of time in the long run. So will the transparent system of version control supported by clearly described changes. It might happen that one change will cause collateral damage to a major part of the project. In this case, it’s crucial to be able to easily track the cause and restore the project to the stable state. Also, remember to take care of consistent naming. It will allow to avoid confusion in all communication, not only changelogs and the same things should be called the same all the time. Don’t waste time every day on solving a difference between a window, a pop-up and a prompt.
Now a thing which is a bit controversial. I know that there are fans of this solution and by others it’s criticized, but it might save your life someday. What I’m talking about is code lockdown. The closer you are getting to a community event or a release, the more clean and stable build you want to have. Introducing a lot of changes to the game right before its publication causes a risk that it may break with only a few hours to go. One of the solutions to lower this risk is to schedule a time after which no changes get submitted to the projects, except really critical ones, until the build gets sent or released. This way, QA is actually working on a final or nearly final build for a longer time, granting far better test coverage.
Sure, the lockdown has its cons. Some may say it breaks the established pace of working on the project because content changes are put on hold. If they are processed on other, non-release branches, things may get messy when they are merged after the lockdown is removed, requiring additional maintenance and tests. The solution is not perfect and it depends on your pipeline and the state of the project itself. Generally, though, would you rather allow your QA to work in the safer environment and thoroughly test a build to be released or to risk the game breaking entirely a few hours before it gets on a plane going to a major gaming expo? It’s your call.
But above all, remember that along with all devs you form one team with your QA. Getting used to a bunch of guys who point out issues in others’ work might be a challenge for all people dedicated to their job. However, if you plan to develop an internal QA team, building a healthy relationship is crucial.
This also applies to outsourced QA despite different dynamics of comms. If you’re curious how to work it out with external testers — see you in the next episode ;)
Don’t forget to tap and hold 👏 and to follow DaftMobile Blog (just press “Follow” button below)! You can also find us on Facebook and Twitter.
