Sponsored By

Evolving Test in the Game Industry – Part 3

This is the final installment of the the Evolving Test in the Game Industry series.

Mike Burghart, Blogger

April 12, 2016

3 Min Read
Game Developer logo in a gray background | Game Developer

I did not intend for this series to have a 3rd part, but, in retrospect, it was needed to clarify a few things. Recently, I had the fortune to sit with an old mentor of mine and have lunch. This gentleman has decades of experience in the video game industry and still derives much of his satisfaction from mentoring and growing others. The lunch reminded me that I’ve had the privilege to work with some of the strongest testing, design and customer centric minds in the industry. For that I am grateful.

I’ve revisited Part 1 and Part 2 of this series and I may have deprioritized a critical part of the testing pipeline. This was not intentional. Functional (or black box) testing is not now nor will it ever be unimportant to creating a great game. Functional testing is critical to the success of any game release as it provides player insight designers and engineers are not privy to. When any tester runs through a feature or build, they bring an objectivity that developers tend to lose. It is difficult to provide an objective evaluation of your own design or code. Please note, you can craft an epic game without white or gray box testing, but not without functional testing. Thank goodness for Testers!

It’s important to remember that one thing testers cannot do is assure quality. Quality begins at the design phase and thrives through maintenance. In other words, it’s everyone’s job and testing should never be about assigning blame. Recap fin.

So how does it all fit together? It took me a considerable amount of time spanning 3 game development studios to get a high enough perspective on the process to venture an answer. That answer is, it depends. I know, that answer sucks, but it’s true.

If I were to again build a test organization, providing the very best support in each stage of the SDLC, it would look something like this:

  1. Tester sits in on meetings and creates the initial risk assessment for the business and technical leads to review, edit and prioritization.

  2. Tester crafts test plans based on the identified risks beginning with the highest priority.

  3. Tester works with TE, SQE or SDET to identify automation opportunities

    1. TE, SQE or SDET take ownership of performance and security testing

  4. Tester crafts automatable test cases.

  5. Tester crafts and executes functional test cases as the feature comes available.

  6. Tester reports, tracks and completes due diligence on any defects.

  7. Tester works with stakeholders to identify trends and root causes.

  8. Tester crafts automated checks for resolved defects and submits them to TE, SQE or SDET for review and addition to the automated regression suite.

Standard disclaimer: this workflow varies by studio and company culture.

QA’s job is not to reshape the world, but to provide information to stakeholders so they may make informed decisions. Our best shot at facilitating a smooth SDLC in an Agile environment is to engage with development from concept through maintenance. A complete approach to testing empowers us to do so. Functional (and user experience) testing are a critical piece of the puzzle.

Please post any questions or comments you may have on this blog post series. I’ll be happy to share experiences I’ve had. Even how to integrate testing into an Agile development lifecycle is fair game.

Read more about:

2016Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like