Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Do we even need QA at the start of a Project?

by Alex Dorans on 12/15/17 11:01:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


It's a mantra that's been spoken across the breadth of QA in bated breath. "If we were involved at the start of this project then <insert tragedy here> wouldn't have occurred". With Captain Hindsight present and approving, everyone agrees QA could have helped and then we forge into a new project without bringing QA into the fold.

Have a think about when your organisation brings a QA representative onboard.

Now, lets ask the question, are QA really needed at the start of the project? Lets think from a development and production point of view. There is nothing to test at the concept/prototyping stage so why bring on a full time QA'er? We can contribute and give ideas, but isn't that what you look for in your Designers? If there is a need to widen the scope of opinion, a meeting or feedback session can be scheduled. Even during prototyping where there is a small arguable need for QA, the solution is that developers can self test! Such an approach will get them into good habits that will bode well for future testing. As a compromise, lets keep the Head of QA in the loop, that should be sufficient.

Just with QA being present in the team, they ooze Quality

Sound familiar? On the surface these arguments sound reasonable but it ignores the role that QA plays beyond bug finding as we are duty bound to promote quality throughout game development process as much as the game itself. We are the first customers, we set the tone of what Quality looks like and act as the oil in the machine. During these early stages, QA will explore and form their own strategy for how they plan to tackle QA on the project. This echos with how coders and artists will work within their discipline to determine how to implement and express the ideas that Design create.

Forming a bond with the team is also very important. Everyone needs to trust and respect each other and having QA parachuted into the process later than everyone else provides not just a shock to the team dynamic (you're bringing in a brand new discipline) but the upward battle for the QA-er to earn the teams respect. Observations within the teams that I've worked within leads me to believe that just with QA being present in the team, they ooze quality and push others to a higher standard. This isn't just due to our skill set, I believe this is due to developers having a regular expectation of their work being functional outside their own local version and having it poked regularly. From the very start, via QA, the team is one step closer to their eventual customer.

Ponder for a moment how absurd it is to have creatives explore their craft and deliberately exclude one discipline.

So far, it can be argued that having QA is a "nice to have" but not a mission critical component of the team. On a practical level, when QA is included jobs like debug command creation are present, bug reporters are committed for development, automation structures are designed with the game in mind and supported by development rather than being tacked on in isolation. QA can make it's biggest impact not by finding bugs but via Issue Prevention and steering development to being sustainable for future testing. When it comes to Games as a Service, this can significantly reduce the testing footprint required.

We should factor in that QA doesn't just check over artists and coders work. In the early stages, the glimpses of what the build system could look like, continuous integration, TDD are ideas that can be planted and scoped in the early days. Without the constraints of upfront testing, QA can look ahead to create Gold Service coverage framework proposals and let Production teams decide what level of risk they are comfortable with. Let's view this exploration and level of planning in the same light as GDDs and Tech Documents.

If you take one thing from this, it's the understanding that QA is not just about bug finding. Embedded testing has brought the tester into the team however Quality is not something that is transient or starts when then first line of code is wrote. Next time when art, code and design get together at the early stages of game development, ponder for a moment how absurd to is to allow creatives to explore their craft and deliberately exclude one discipline.

Related Jobs

Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist
innogames — Hamburg, Germany

Frontend Developer (Haxe) - Video Game: Forge of Empires
innogames — Hamburg, Germany

UI Artist - Forge of Empires
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States


Loading Comments

loader image