Many companies sequester their QA in a different building or on a different floor, but at CIG we put our QA right there in with the teams. Talk to us about the QA structure.

So like you say, we do have those main QA teams, like Jack's team, like George's team, that are the main gameplay-focused QA guys, and they run through together as a team of QA. Granted, they still do contact developers and work with them that way, but they're more of a QA team. So we've got those main QA teams in the UK and also in Austin, Texas. We have a few testers who work as part of main teams like that, as well as the core and the gameplay teams. We also have a vehicles and FPS team, which I led for a short amount of time. It was really fun to delve into the ships and the shooters kind of stuff, basically. And then we also have the tech team who deal with everything editor-based. So all of the tools that our developers use that also need to work. So not just the game-playing aspect of things, also the game-making aspect of testing too. But yes, like George here, we have multiple embedded testers who basically are part of their teams directly. So George is part of the network team. We have people in the UI team, audio team. And basically they get to be the person who is the point of contact who knows everything about that particular area. When it comes to QA, we are generalists. We try and do our best to provide info across the entire game. But obviously we can't remember everything. There's a lot of stuff in terms of logging, debug. I can't even get started on crashes. There's so much with crashes. We have a crash guide that is literally an hour read on its own, just all different sections. So yeah, it can get quite complex. And having those embedded guys who are literally there to know the exact ins and outs of everything to do with that particular team is so, so useful, for general QA and for the developers themselves. It is a really, really good kind of symbiotic relationship, I guess, that we have going on. George, do you want to talk a little bit about your transition over to embedded?

Yeah, so it was kind of like a weird culture shock in a way. So before joining games, I worked in retail for almost 10 years, did my degree and then started in QA. Moved through a few different departments: before, I was on live release, so what gameplay is now, so we'd test the features before they go live. Then I moved on to the core team, which Jack is on now. Then I moved over to tech, then I moved over to the resource team with Sam for a good couple of months, and then I ended up moving on to the embedded team. So it was quite a weird culture shock, because the first thing that I thought of going into an embedded team was, I need to make sure everything's good. So if I see a texture bug, I need to bug it up, which, that is the premise, but usually when you're on an embedded team, you just focus on the stuff that your team does, because that's why you're there. You're running around trying to bug all of these things up, and it's like, no, just take a minute, calm down, bug your network stuff up, and then relay that to the devs. And that's kind of the way the team works. I think the biggest thing is that when you're a generalist QA, you're not really talking to devs on a day-to-day basis, really, because you're more relating to your seniors or your leads. Whereas going on to an embedded team, you're talking to your lead, who's obviously an engineer or developer, plus your seniors and the junior programmers and all of that on a day-to-day basis. And when Sam was saying before, it's like a catch-22. So when people say, oh, devs must hate QA because they're always finding these bugs and can't they just stop so we can do other things. But at the end of the day, it goes hand in hand. So I'll go to my lead or my senior and be like, oh, I'm not too sure how to use this specific tool or command or something. And then they'll come back and be like, oh, it does this, it means X, Y, Z. And kind of the same vice versa as well. So if devs are in-game and they're not too sure of a specific thing, because a lot of the things in-game do change quite rapidly as well, because the game is huge, then it comes to us: I'm not sure how I do X, Y, Z. So then we'd go and help them do what they need to do in order to check their fixes have taken, basically.

I think we've somewhat touched on the aspects of it from the day-to-day stuff. But yeah, like George says, it's the different dynamics of we have QA teams and then we have our embedded guys. And then we have the Squadron team, which is kind of a hybrid between embedded and also being its own small team of QA, and those guys did great work as well.