Tuesday, November 15, 2011

Play A Role In QA

Well its been five months and I've been busy.  Well not busy depending on how you look at it.  But I thought I'd take the time to talk a bit about QA.  Seems like an odd topic for someone who designs games but I had an itch that needed scratching.

Not many people would ever want to work in QA as one of gaming's so called Umpa Lumpas of the trade.  Often disregarded as a mere tool to find bugs these 'lower class' workers often toil around simple 'see if all my feature works' efforts.  This means testing all the possible mindless tasks that a user would go through.  I can't imagine a worse job for a creative person then putting them to work on a virtual 'to do' list.  I'm not saying that people working in qa are automatons by any means.  The small measure of creativity they control comes from the exotic conditions they can find glitch's in but that level of freedom is quickly stomped when given harsh deadlines for unrewarding en-devours.  At a certain point its impossible for someone to care about how well a machine works when their influence on its creation is so limited.  So producers are left with testers that strive to work in harsh creative conditions on a product that they have limited investment in.  How can we change this?

The strategy could be as simple as let the testers have an outlet for their creative ideas.  Even a small scrum once a month can go a long way towards letting the testers feel more appreciated.  No one, and I mean no one, will spend as much time with the functionality of the client as the testers will.    What I suggest is that quality control play a more integral role in developers schedule's and act as a literal user that can ask 'why the hell did you put that cover so fuckin far away?'  Just the face to face confrontation of an actual user can change how the developer can see something.  One step further is to have a select few testers placed in on meetings where they can hear devs talk about implantation and gather a larger sense of how the development will go.

Once a tester is more implemented within a team the process could go even further to include testers as integral members of the team that act as constant supervisors to the creative devs who actually produce the products.  Devs in turn can talk through decisions with their testing counterparts to better understand why something was unliked.  In essence this change would be treating testers as students and teaching them face to face about decisions as to the 'why' and 'what' that goes into making games.  This would not only make for better games but for a more cohesive team.  More often then not development teams for games will include the same people and this added communication would make writing bugs for a dev more transparent.  This idea is basically asking for more accountability from developers and a higher level of design competence from testers.  If you want your testers to care about the quality part of QA then you need to get them invested in early so they can work together to create a much higher quality product.

To conclude this I believe that a more educated tester can achieve a greater output for the company.  The feedback of someone, even bad feedback, can cause a creator to defend the 'why' of his design.  Once a better understanding of why a feature is put into a game you will know exactly how important it is to the final product.  This is a great way to make better games that are more accountable to a schedule since features are constantly called into question.  And if a feature is staying this dialog will ensure a dev knows exactly what a general audience will think of its performance.