Where does our pre-occupation of desiring programming experience in our a QA testers come from? There has been a rising trend in jobs for embedded / development testers where employers are asking for such experience. This is normally listed in the desirable / extras section of the job specification but does it imply that to succeed as a QA'er we have to become developers? Whilst there are roles within QA that require the skill of programming I'd like to explore why we desire this skillset in our gameplay / functionality testers.
I'm considered lucky in that I have the same access to the code base as any other developer on my team. For me, a non-programmer, having code access is valuable as I can see the scope of a change-list which allows me to target the scope of my testing effectively. Is it just a data change to a config? I check rather than test. When it comes to text errors, it's more efficient that I submit the fix myself rather than creating a bug report. None of this required me to know a particular language inside out.
Are we discouraging strong core gameplay testers by having soft requirements of being able to program?
One of the justifications surrounds QA'ers leveraging programming skills in order to make some "QA tools" and "be a better tester". To make a comparison, if the Art or Design teams need a tool they will request it as part of production. Why doesn't QA do the same? Traditionally these requests are either not prioritized or scoped as part of production. This is potentially a by-product of not including QA at the very beginning of projects. As such, I believe QA teams have attempted to become self reliant in this matter.
Is QA making their own tools actually a waste of QA resource?. QA should be able to describe exactly how they want to test something and have the developer make the tool as part of development. A developer should be able to make it to a higher standard and in less time. It's not that hard to get this achieved as speaking up and being proactive when Acceptance Criteria are being crafted can embed the tools creation into the process.
Reporting of bugs / quality issues in the form of bug reports is just the admin component of it.
What are QA missing out on by focusing on programming ability? I'd argue that the average QA'er is better placed to conduct various forms of UX testing and deep critical analysis of a product as they are have the broadest working knowledge of the product, come from a quality background and have strong reporting skills. This is a service very much in demand as most companies are inclined to hire external consultants to perform this task. These are potential skill sets we're missing out on because we feel that learning a programming language is more tangible and acceptable way to influence quality.
Does the fixation with programming ability mean we are losing out on some good candidates? Not just at the CV review stage, are we discouraging strong core gameplay testers by having soft requirements of being able to program? When I ask candidates "What their proudest moments in QA are" they tend revolve around big bugs that they found via destructive testing or when they have influenced a decision / process or feature. Why are these areas not being added to jobs specifications?
For the programmers reading, you've all had that moment of "How in the world did QA find this?", for us, this is what we do.
We need to think back to the core of what QA is and the value we represent. It's being the link between the customer and developer, holding the sum of the game knowledge to assesses the landscape ensuring a rewarding, fulfilling and seamless experience. Reporting of bugs / quality issues in the form of bug reports is just the admin component of it.
We need to be pushing Gameplay QA'ers to be destructive and critical thinkers, not just functional testers and tinkerers of code. QA'ers with excellent critical analysis capabilities and can see the issues at the design doc stage and expose weaknesses. For the programmers reading, you've all had that moment of "How in the world did QA find this?", for us, this is what we do. We expose the feature / product to multiple angles of attack, wearing different hats of the type of people who will interact with the product.
Let's not burden gameplay QA testing talent with the soft expectation to be able to code. Let's embrace the quality enhancements that Gameplay Testers provide rather than adding soft programming requirements and start to think of other quality driven skill sets we might want to populate into our QA teams.