• Register

A beast is roaming the ship. A creature known from long-forgotten fables and ancient myths. It could prowl around in any shadow and lurk behind any corner. We must plan our every move. We must survive the infection. We must get off the ship. We must escape Phantaruk.

Post feature Report RSS Iterative Q/A

Testing a game and its elementary systems is a very important episode in whole production. It allows you to find bugs that might create a bad image of your project – community’s opinion is important and disrepute can destroy your dreams about marketing and selling success. What’s more, engaging your team (and not only them) into Q/A (Quality Assurance) makes everyone updated with whole project’s progress, especially when you have 20 or more people under your command.

Posted by on

A few years ago, I participated in a very interesting project called "Drakland: Tales". It was a RTS game project being made by ca. 20 people. Unfortunately, builds of the game (versions that you can download, run and play) appeared irregularly and rarely. Because of the fact that no one could see their new assets (e.g. 3D models) in-game regularly, they were unmotivated.

My point is that well organized Q/A gives profit not only to technical side of the video game. If we are smart, we can gain extra portion of motivation among our co-workers and, what is more important, set
deadlines. That’s right – in this case, deadlines are our alliance, especially when you are making your project after hours.


Making the build in regular iterations have the following benefits:


a) Everyone is up-to-date with what is created and what appears in the project. Preparing so-called changelogs, lists of changes, systemizes programmers’ knowledge of what they have to do and what needs to be fixed. Also, testers (or/and co-workers) will know what is repaired and what must be checked first.

b) The game is more efficient. Iterative Q/A gives us limited time for testing specific items, fix already reported bugs and then verify them by testers. To illustrate what I’m saying, I prepared a image below:


c) Deadlines give you precise tasks. It allows you to measure your own efficiency easily and, after a few builds, you know exactly how much you can do in specific time. For example, you have to add some features in version 0.5.8: X, Y and Z. A day before deadline it turns out that you are not able to finish Z. Then you know you will have to add this feature before next build.

We use this system in Phantaruk. Every week we release a new build marked by numbers. Even today we upload version 0.0.2 with some bugs fixed and new changes added. People with access to an early version of the game can download and test it for the next week. With this solution we can test each small detail of mechanics included in Phantaruk.

Are iterative tests a good idea? Maybe you have a better solution?

Our facebook: www.facebook.com/phantaruk

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: