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

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.

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.

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.