I headed out to Amsterdam to attend this years' Game Quality Forum conference. We had more content from automation engineers, build engineers, developers, automation framework founders and game engine experts; as well as content from DEI experts and employee resource group organisers.

Now in it's third year, Qualicon again brought us a treasure trove of game testing and quality insights in this year's conference. Describing itself as created by game quality professionals, for game quality professionals, it's focused entirely on the QA discipline.

In this article I review the syllabus as a standalone published work, how effectively it teaches game testing skills and how closely it matches the pragmatic day-to-day work in modern game companies. Finally, I'll recommend whether it would strengthen a CV, regardless of the content inside.

The reason for this article is because it’s easy (and unfortunately quite common) for the game studio leadership to not understand the scope of responsibilities of the test team and their goal as a discipline, confusing QA with testing.

The scope, type and risk of code bug fixes varies wildly, from one-liner fixes through to complete code system restructures. With thousands of bugs being fixed in a game project, it's critical that each and every tester is able to assess the scope and risk of bug fixes and take the appropriate action.

In this article I’ll share some stories of when myself or other testers have spent a lot of time chasing ghosts, often with no productive outcome at all.

No legitimate bug. It was pure wasted time. Through being aware of these examples you can be better equipped to identify when this is happening in your own teams and take action sooner to prevent frustration and wasted time.

Many test planning sins can be easily hidden by over-allocating or misusing tester resources. In this article I’ll highlight the problem that it’s easy to hide ineffective test planning and what you can do to identify it.

Quality at source has been a buzz phrase since I've been in the industry. Articles, talks, job postings and social media comments are awash with vague recommendations that project efficiency is tied to achieving better ‘quality at source’. In this article I'll give a definition of this term and provide examples of where I've been able to contribute to quality at source

In this article, I'll list the benefits of improving the technicality of a game project QA team and how doing so helps bridge the gap between dev and test by ‘meeting your developer half way’.

One trend has become apparent, QA analysts who are more technically competent in the game area they are testing, are able to support, understand and communicate more effectively with feature authors.

The scope of work problem identifies that the extent of testing, and therefore work, is self-defined by the QA analyst creating each test plan on the project. 

As a result, it's difficult to determine if the scope of testing has been logically deduced from project factors or simply limited by the experience, attitude and drive of the individual planning each feature. 

The proof of accountability problem within testing describes the difficulty in making QA testers and QA analysts accountable for the work they produce and how this impacts the discipline’s performance across the industry. If we’re unable to accurately and fairly assign accountability, poor quality work goes unchecked and great work goes unrewarded.