QAuDHD #5 - Sliiide To The Left
The Neurospicy Bit
There's an interesting stereotype around autistic people that we don't like/can't handle change. And while that will be true for some or in some situations (we do tend to like routine), my experience and my understanding from sessions with my therapist is that we are also quite often the instigators of change.
This is because, if we feel like something is wrong, could be improved or should be reworked, we're often the ones to raise it; sometimes without much diplomacy (which can understandably rub people up the wrong way), but often with viable solutions already worked out.
Since our brains literally function in a different way, it often gives us a unique perspective (check out Hannah Gatsby’s outside of the box thinking from her show, Douglas), and in my experience allows for a view on things that goes from the minutia all the way up to the big picture.
So why all this talk of change? Well believe it or not, there is a method to my madness!
There's an interesting stereotype around autistic people that we don't like/can't handle change.
I have discussed the effect that I hope automation and AI will have on the games quality discipline in the coming years already, so if you want to know more about that, go back and read issue #2. But I wanted to expand a little on one of the ways this is already manifesting as the industry begins to adopt the latest buzz-word(s): “shift left”!
The Actual Topic
What is “shift left”? In short, it's a development approach which sees quality teams get involved earlier in the process (i.e. further to the left of a typical production timeline). This often means validating designs and implementations before anyone writes any code (e.g. testing menu wireframes or even critiquing the proposed onboarding process), and will include ensuring that designs are fit for purpose (i.e. do they meet the needs/expectations of the target player base).
The idea is to weed out problems with designs themselves before too much implementation work is done, in order to avoid a situation where work has to be redone - often by multiple departments and generally at a time when they’re scheduled to be doing something else. Another good example of this which is already fairly common practice is testing levels in greybox to ensure that they meet the design brief before anyone starts adding art, set dressing, cutscenes etc. (all things which would have to be redone if a problem with the underlying level itself is found later on).
In software development, it is estimated that around half of the bugs on a project are introduced before a single line of code is written on any given feature, and the cost of fixing bugs later on in the process is up to 30x higher than at the start.
BUT, while I’m a big advocate of QA teams getting more involved early on (if nothing else, that’s a truer definition of Quality Assurance, as opposed to Quality Control, which is what happens once something has been designed and you are making sure it functions correctly and meets any expected standards, e.g. 1st Party certification requirements), I do have an issue with the word “shift”.
It implies moving the whole process earlier and subsequently abandoning that QC part, potentially also reducing the effectiveness of post-launch support. So I prefer to think of it as spreading left, whereby games quality teams continue to do the vital work most of them are already doing to verify that builds are stable, features function as expected, crashes are rare etc. as well as trying to catch as much as they can earlier on.
...half of the bugs on a project are introduced before a single line of code is written...
This might mean having some team members specialise in one area or another (e.g. CQA are wired to test against best practices and set standards, so they’re more suited to the right-hand end), or it could mean rotating the team around.
I always insist that my teams are present for design meetings, feature kick-offs and code hand-overs so that we can “pre-test” things (i.e. point out potential gaps in the design or intended implementation, or at least say things like “the first thing I’m going to do is try to break it by…”). At the very least, it allows us to plan testing more effectively and reduces the immediate need for feature documentation (which is the Holy Grail of testing, and seemingly just as rare).
There! Another topic covered in 500 words!
