Ever more producers

Haaalllelujah! Haaaallllllelujah! Hallelujah! Hallelujah! Halllllleeeeluuujah! See you on the inside my bretheren.

I don't think I can be bothered now.

I'd like to thank everyone that made this possible. It was a team effort and in the end the journey was was what we'll talk about for ever after. I'd like to thank Clint amoungst others. And of course the CAN. It was pretty sweet. Oh, I think I'm going to do a *sniff* Gwinnie....... I LOVE YOU ALL!

 

what about me...??

Hey don't leave me!! What about me?? I'm totally legit!! Baboon, noooooooooo~~~

 

Oh shit, they're breached the front gate! Retreat to the inner stronghold!

(The Really Private Forums)

 

Retreated.

 

may the n00bs unite

C'mmoooon n00bs, lets get them!!!

 

CHARGE!!!

Oh wait a second I'm now in.

Raise the drawbridge and man the battlements. Must stop all new invaders.

 

What the hell?! THEY LET YOU IN?! Damn.. it's all gonna be all down hill from here. At least I still have my can. So sweet.

 

What about Associate Producer Jr?

Lot of people don't think that this type of job could existed. From my point of view, learning early how to manage any project will give the industry better manager in the future. In the web for example, They already hired young/unexperimented project manager.

 

Q A Clan aint nutun to fuck wit

Everyone knows QA aren't game developers. Which is why I haven't been accepted to "the other side". Although, I bet the other side isn't as great as I make it up to be, more work than it should be and less perks than I realize. Kind of like this industry actually.

However, being a competent QA "specialist" means I have the opportunity to learn what a producer does. Simply because producers seem to spend most of their time justifying to execs why their team should continue to exist; instead of actually removing blockers, monitoring team health, and bridging the gap between the designers blue sky and the programmers cold reality.

Producers are like anyone in this industry, you've had a few terrible ones, you've have a few good ones. Well, if your lucky anyways...

 

Good QA is priceless. I have seen some good testers find bugs in my code which I didn't even think existed. Ofcourse that also made a bit too dependant on them which wasn't a great thing in the long run. I am unlearning that bad habit now - heh.

 

If a team of programmers are set up properly (read for perfectly) then QA shouldn't even be necessary. I heard Google programmers QA eachothers work when reviewing their deliverables.

However, if you have an inherently buggy product, or don't have the time to turn around and build a test driven development framework, then a competent QA team can make the difference to turn your product around.

Unless of course you treat them and pay them shit, in which case you'll have a revolving door of people off the street or wannabe game designers fresh out of school who are all quickly burnt out. Thats where you get the classic QA bugs that just make you facepalm and yell for your producer to start afiring.

 

Say what now?

 

Sure! If you have a product with processes in place to create a test case for each deliverable you create, then you've essentially coded in QA. Wikipedia "Test Driven Development", I'd link directly but dont have enough posts to do so.

Basically, if every single deliverable has an automated test that checks if each deliverable passes/fails, so you'll catch all your bugs before it even gets to the QA pass. It means that you won't check-in any knock-ons because every part of the game has been tested.

 

That just sounds like all kinds of wrong.

 

Caveat: This is classically for web development, and is one step towards having a continuous deployment development model.

For hardcore "AAA" games, TDD might not work so well, due to the scale of the product. However, it's been proven to work- at least in the web world.

 

You mean, due to the complexity of the product. I mean, many teams now have some form of automated player testing, but there's no way you could cover all of that. Game QA isn't going away, or getting smaller. If anything, the opposite.

Our toolchains on the other hand, are well suited to automated testing.

 

Even more with Multiplayer features and TRC needs...

 

You can't effectively test your own stuff anyway, you have too many preconceptions about how the user will use it. Good QA finds the stuff you never even imagined would be an issue.

 

I'd like to try test driven development, I am curious to see how much time it will take up compared with the savings at the end.

I agree with your general point, but I'd like to clarify something, in a pure Agile setup, I believe you are meant to have test from day 1 (to go along with having a build at all times).

This is the point where you could remove QA from the test cycle, and have programmers review and test their other sprint members code. It would be more productive to do this at the start as the build is not really in a game state for QA to test.

You still couldn't remove QA from say the last 25% of the project, but they would have a much smoother ride if the above method had been implemented.

I've probably just made a point for the sake of it, and sent you all to sleep.

B

 

Again, the idea of Agile is that tasks are broken down in to managable chunks, so with this in mind, test cases should work fine. The other tasks have also been tested, so they should be compatible.

If there is a problem when you come to assemble the tasks together, a test will fail and you can see where the problem is.

(again, you can't totally remove QA.)