The Difference between QA and Playtesting in Games

It has only come to light recently in my discussions with other developers, as well as tutors at my University, that when I say I playtested Food Time Battle in Space for six months, or that I’ve been playtesting Space Game for three months now, that I’m just plain wrong. 

If we look back at the development of FTBS, it took me roughly about a month to work out all the kinks, and make sure that the game is playable and enjoyable. Due to the game being so tightly designed yet very asymmetric (I only had 12 cards to work with for each player to create and balance that asymmetry) it then took me five months to balance the game. To break that down more simply, development on FTBS was split into:

• 1 Month Playtesting
• 5 Months Quality Assurance (QA)

This blog post is going to briefly cover the key difference between the two, as well as discuss what your aims should likely be whilst in these two different phases of development.

Playtesting
I am going to discuss this more in a different blog post, but there are two widely used processes for creating games. There is SCRUM, which is a form of rapid iterative processing. You essentially plan your game, build it, test it, review it and repeat. There is also the Waterfall technique, which consists of doing this method, but only once, which consists of a much bigger and longer planning stage compared to the rest of development. I personally prefer using the SCRUM method. The reason why I make this distinctive remark is because it is important to have the right mindset when going into playtesting. Your aims for playtesting should be:

• Test core mechanics
• Find the fun
• Nail the flow of the game

And you accomplish these things through the SCRUM method, swiftly planning, building, and testing, before evaluating feedback. Everything else comes under QA. As soon as my playtesters found FTBS enjoyable, and you could get from the start of the game to the end of the game without it breaking, then playtesting was finished. 

Quality Assurance 
I’ve yet to find an efficient way to structure QA, but when I do I will let you know (consider signing up to the mailing list hint hint). What I will say though is that at some point down the line you will have to say to yourself, and your testers, that enough is enough, and that the game is done. I have been in a situation before where I was hoping that the playtesters, or even the game, would make that decision for me. To refer to FTBS again, I had a spreadsheet of the four different restaurants, and my aim was to make it so they all had the exact same win rate. That was never going to happen. You can play your game constantly, on repeat, forever, and you will always find things to change. I mean, just look at any other game you’ve played, I am sure that are some aspects of every game that you have playtime in that you would consider changing, and those games have been in QA for months just like your game. Despite this, here are a few things to consider when going through QA:

• Do players feel like the game is balanced (big distinction between the game being balanced and feeling balanced). 
• Have you done a bunch of blind playtests, testing the rulebook to make sure there are no errors and that there is an overwhelming success rate when it comes to understanding your game. 
• Is the artwork being well received? Once you start the QA process, I would reckon that you wouldn’t have the entirety of your artwork in from your artist. Use your testers during the QA process to pass on feedback to your artist. 

The Difference Between QA and Playtesting
The core difference has to be that the end of playtesting is very distinctive. You have a beginning point, your first iteration of your game, and you have an ending point, when players continuously enjoy playing your game and it works. With QA, there is almost never an end in sight. Playtesting is very much for vetting the value of an idea, whilst QA is focused on determining the best way to deliver that idea. Both QA and playtesting are essential to game development, but I would say that if you go into the development of your game with different mindsets for each stage of production, it can save your sanity slightly when you hit month five of “playtesting”.

​