Planning is everything: Lessons from QA that help you escape chaos

Throughout my career in Quality Assurance, the companies I have worked for have placed a lot of emphasis on processes. We had time to focus on doing the right things the right way, documenting every feature. Despite having a strong focus on processes, tools, tracking and metrics, chaos seemed to creep in and turn into late changes, critical bugs and delayed deliveries.

While I’m relatively new within the gaming industry, the same seems to apply to the game industry. Why is it that regardless of the industry and despite processes and good intentions, so many projects lead to chaos? Why can’t we learn from mistakes? Gaming as an industry likes to steer away from processes more than anything. However, with our complexities and fast pace, we are especially vulnerable to chaos – that we feel in QA.

The good news is that the gaming industry can definitely look outside its own box for learnings and best practices.

In gaming, we often confuse testing and QA. Testing is part of QA, but assuring quality is much more than just playing the game; it involves planning, documenting, and reviewing practices and processes, and your whole team has a part in it. Also, I’d like to point out that testing a game is in my experience the hardest thing to test. While gaming is different, at the end of the day, the loops, functions, and variables we code follow the exact same principles as they do in other industries. Your audiences might differ, but every service has an end user that you want to satisfy – players are the closest thing to a boss we need to keep happy.

My years in QA have helped me identify areas that we in gaming could improve on. This blog series will explore improvement areas that I hope will become a reality in game testing and development in the future. For some of these Metacore has made great efforts to improve, but we’re also on a journey to better plan and test.

Enough ado – let’s dive in.

Planning and documentation done right

The world is spinning faster, and so is software development. That doesn’t mean that we should rush things, cut corners and fall into a false conception of being agile and flexible. While the world now moves with extra speed, the way development is run has not changed that much, and the importance of planning properly still holds true.

This applies – perhaps more than anywhere – in the fast-paced world of mobile games. When the QA team has a very limited time window to test that things are working as expected, the first thing they need to know is how something is supposed to work. The same applies to artists, designers, and programmers: they need to know what is expected of them to build things correctly. This requires proper feature requirements and design specifications.

The highest priority goes to requirement definition, planning, and adequately documenting what you are supposed to implement for your end user.

Agree on what to do, and do what you agreed on

As a principle, planning is something relatively simple that everyone can do their own. All of us should plan our work, and then execute our plan. Taking that up a notch, our plans should be aligned across the wider team.

As simple as it sounds, when working together on a common plan, we should follow this rule: agree on what to do, and do what you’ve agreed on. If everyone is given common guidance, your producers will most likely end up with a better grand plan for your releases. The same logic applies to documentation. To get the most out of both, you should have common tools and templates in place to ensure some standard set of resources is available for everyone.

Tools enable planning and documentation, but tools don’t make you happy – what you do with the tools is what really counts. Keep in mind that Jira, Asana, or Notion will not solve everything: you still need to have plans for what you do and what you document. You also need to make sure that people use them consistently. Otherwise, you will be as lost in the jungle as you were without the tool.

Locking down common processes

How do you ensure that common processes are developed, put to use and people actually commit to them?

Start by considering what steps your development process consists of. Then think about entry and exit criteria for each part: what does your game designer need in order to design a feature? Is it a feature description, art assets, or perhaps a prototype build?

Next, think about what this means in terms of the timeline. What is the critical path, how do you estimate each part, and how do you track progress? Only after you’ve got all of this figured out should you start considering tool options to support this. You will never find a tool that works for everyone, but with enough research, you can identify common denominators and use them as leverage.

Regarding documentation, a good practice is to have templates for everything: high-level feature requirements, design documents, user journey flow charts, and so on. You don’t need to write a thesis for a feature, but you need to document at least the bare essentials. A review process for documents doesn’t hurt either. Finding bugs before anyone writes a single line of code are the cheapest bugs you will ever fix!

With shared plans and good documentation, you’re off to a good start

Planning and documentation won’t make your problems disappear, but they will help you solve a bunch of important ones: bugs, excessive meetings, or endless “bug-or-feature” discussions. Shared plans and good documentation are both means of communication, and if having these can save people from a lengthy daily status meeting, you will likely have happier people to work with.

Henry Lunabba is currently a Project Lead at Metacore. He’s spent almost half of his career in quality assurance (QA for short), the other half in project, service, and people management—and now, in games. In this blog series, he will guide us through the lessons he has learned about managing (and sometimes, just surviving) chaos when developing new systems and launching new products.