AQA Character Reference (D&D Version)
In the current edition, AQA is a prestige class. Hopefully in later editions AQA will become a base class and you can bring one directly into your party. For now however, you’ll have to level into it.
There is a debate in the AQA community: who makes a better AQA, a Developer or a QA? “AQA writes code!”, they argue, “Clearly they need to be a Developer!” “No, they write tests!” someone will shout, “They must have the domain knowledge of QA!” Who’s right?
The answer is: yes? It depends on your parties needs and resources. Ultimately AQA is a hybrid class. It’s both Developer and QA and they need to be able to do both.
Obviously if you’re already short on QA, perhaps splitting their attention isn't the best idea. Equally if you have adventures that require deep domain expertise to navigate, perhaps a QA is better suited. This is a debate that should be had with the party to see where their needs lie.
An AQA is both Developer and QA - but it performs both of those tasks differently. The code they write isn't production code and is ideally only used by the ones that wrote it. Equally, the tests they write don't have the same depth or dimension of the ones a regular QA will write - they will likely be in a different format and tracked separately.
An AQA is fairly light on the actual testing. QA as a skillset is primarily focused around validation: good product design and exploratory testing. AQA only really requires that at a surface level - understanding of test plans, bug advocacy, and other general QA processes.
An AQA does require a good proficiency in programming however - they’re going to write a fair amount of code. It’s not going to be the best code, or the most efficient or exciting code, but it will be a lot of it, and in my experience it’s easier to teach someone the basics of QA then it is to expect them to learn the deep dark depths of Java.
STR - 11
Strength is the weakest stat for an AQA. With well-written test code, the bugs found should speak for themselves. An AQA shouldn't need to persecute them too rigorously.
DEX - 13
Admirable. An AQA should be flexible in performing different types of testing, within reason, as often only one or two AQA are tasked with taking on the whole system - from integration to end-to-end and performance.
CON - 11
Low, but enough. The code can be frustrating, but often not as keyboard smashing as production code. They should be able to keep with the task, but there's often a variety of things to do if they need a break from one aspect.
INT - 14
Being part Developer, they need the raw intelligence required to write good code and the ability to comprehend many different languages and tools. They may not be up to date on all the latest releases and buzz-worthy technological advancements, but they know enough to get the job done.
WIS - 14
Being part QA, some wisdom in understanding where to find bugs, how to write test cases, and if found how to verify their existence is a vital asset. They may not be able to plumb the depths of the system looking of obscure irregularities, but they can curate their way through the base system and spot things out of place.
CHA - 13
Being cross-functional means being able to communicate effectively with a variety of different people. From talking code and build/deploy systems with Developers, the latest bug reports with QA, and discussing the clients needs with Project Managers, a little voice can make the job easier for everyone.
As a hybrid class, AQA are fairly balanced. They don't have a solid 16 (or 18) in any one stat, but instead are able to approach tasks from a variety of angles until they find one that works.
Versatile Performance: AQA is going to require a lot of consensus and agreement and bridge building. Especially at first, there’s going to be a buy-in period from Managers or even the party where they need to prove that automation - as they approach it - works and is worth the effort.
Quick Witted: AQA is a quick-moving profession. Being an AQA is a moving target: the literature available is very light and a bit obtuse, few know where the field is going or how it will get there. An AQA will need to be willing to learn new things - tools, processes, etc - and adapt accordingly. They should also be ready to be creative and invent their own way of doing things when necessary - and it will be necessary.
Basic Harmony: There’s a strong need to balance Developers and QA, both in general and in AQA. An AQA knows how to respect both roles and recognize them as equal party members. An AQA that wishes to replace QA or alternately to humiliate Developers with bug reports will not work well in a party.