Role of the Game Tester...

                The role of the game tester is arguably the most important role in the entire project, most often the most overlooked, seldom taken seriously and an overall misunderstood area of need in game creation.  Typically, we have 2 types of testers, Whitebox/Clearbox and Blackbox/Opaquebox.  Commonly referred to as black and white, it makes more sense to call them clear and opaque. 

                Opaquebox testing implies that the tester approaches testing similar to a user, installer and administrator.  They don’t know what is going on under the hood.  They don’t care about what language it was written in, and will typically test things in a similar fashion to how a user might use the application. 

                Clearbox testing implies that the tester can see inside.  They can look over the code for weaknesses and possible issues.  Often they write code that ties into this, and tests portions of the application that might not be perceivable to the outside world, but certainly points of problems.

                Often, “Real” developers (Please smell the snark) perceive Clearbox testers as beneath them, and that they are limited in understanding, and really are just glorified users who can do a little code.  The misperception is that an SDET, (Software Development Engineer in Test/Clearbox tester) knows only enough code to hook in and try to push buttons, but that they lack the ability to do anything themselves.  Otherwise we would become developers.

                This misperception needs to be stamped out fast.  It hinders companies left and right, damaging their names in ways they don’t know.  A professional SDET, should know everything it would take to build the application, and have at least 3 different approaches to duplicating it.  A professional SDET can usually look at code knowing they need to look for certain things, because it is easier to accidentally program those weaknesses into projects of the particular type.

                But opaque box testers also get a bad rap.  And this stems from a larger problem, money.  Somewhere in the company, an investor is authorizing resources in the form of money, time and people, to get a profitable application out the door.  Now, there is often very important time sensitive reasons, often tying to competitor releases, end of quarter publications on the company stock or even market trends and research indicating a particular optimal time frame. 

                What the company, as a whole, needs to recognize is that the testers are your last line of defense for keeping clients/customers.  Every time a client uses your application and it loses data, it crashes, it reacts in unexpected ways, or even just moves slowly, it makes them think negatively of you.  Your shaping their next purchase with every update, release and product that goes out the door. 

                Its entirely possible that the competitors products are worse, but they are usually a dime a dozen.  You are not the only company that offers your service.  With all the issues that happened with Windows Vista, even just from a job perspective, when a tester looks for a job, and on their resume it says they tested Windows Vista, the employer might review that and pull up everything bad they recall about the product.

                From both business and the tester’s perspectives, it is vital to consider the weight placed on the testers.  The responsibility they have to the products.    Everyone in the team needs to understand that a tester brings up the bugs because they should not be in the product.  These hurt the product, the company’s image, the chances of keeping clients, and more.

                Testers need to make sure that other people in the projects understand this.  How important your job is.  In relations to small teams creating games, testing is usually just considered beta testing.  Often, the start up teams view this as an opportunity to show off their game before they feel ready to charge for it, and neglect to leave means to be contacted about bugs.  Always keep that in mind, that a beta test is a group of dedicated users who are willing to try the game or application out in advance, even though it might still cause errors, in hopes that when it is released, it will work properly.

                Companies should start making a change.  Follow in Google’s footsteps here.  Announce a time that the beta should be available.  Base it on a month, not down to the day.  Next, push to have the beta ready the month prior, but with some slip time.  Next wait until you’ve gotten some feedback from the users before estimating the next release.  If there is a huge outcry for things to be fixed, you certainly can’t release it that way.

                The test role is a very serious role.  It can’t be taken lightly.  If anywhere in your company, this is the one place to give a lot of power to.