AQA Character Reference (English version)
AQA is a cross-functional field. It’s both developer and QA rolled into one. Anyone suited for the role will need basic knowledge of both coding and testing, and at least some experience in one if not both.
For QA, 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. The kinds of tests that AQA will write and perform will differ, sometimes significantly, from the what you would expect from a QA.
For development, AQA does require a good proficiency in programming. 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 (I have seen some very bad AQA code that you wouldn't want anywhere near a client - but the tests worked, and that’s what mattered), but it will be a lot of it.
Don't expect an AQA to be up to date on the latest trends in either field. They should know at a broad level what a test plan is and how to maintain it, but not necessarily how to write one for an entire system. Equally they should have a basic grasp of build and deploy systems, but don't expect them to make the best administrator of said systems. They should have a passion for learning new things, but their attention will be split between the two fields. They won't make the best QA or the best Developer, because they aren't, they are AQA.
AQA is an ever evolving field. They need to be excited to learn new things. AQA is a fairly new field, the literature is very light and difficult to digest. No one really knows where the field is going or how it will get there, and we certainly don't have any silver bullets. An AQA needs to be willing to learn new things - tools, processes, etc, - and adapt accordingly. They should also be creative in inventing their own way of doing things when necessary - and it will be necessary.
Effective communication will be important for an AQA. They 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 management or even the team where they need to prove that automation - as they approach it - works and is worth the effort. ‘As they approach it’ is key here - there are no silver bullets or singular best way of automating your project, how one AQA does it may be different from another. That’s not a bad thing, but it does mean they need to prove it works.
Finally, a word of caution. An AQA needs to understand and respect both Developers and QA. That should go without saying, but I’ve seen QA people that believe AQA is a way to overwhelm developers with bug reports as some sort of revenge. I’ve also seen developers that feel AQA is a way to rid themselves of QA. Realistically if you have these attitudes on your team, you should review your processes and team structure, but in any case these attitudes don't make for a good AQA.