Game QA. What do they use?
polycounter lvl 13
Hey guys, so I've been reading up about Quality Assurance, and have had testing experience (reporting bugs etc), but only from a users standpoint. I'm just wondering if there's any software used for testing a game, or for the QA process other than playing the game. (stress testing? runtime diagnostics?)
Just wanna know more than whats on http://en.wikipedia.org/wiki/Game_testing which i'm still in the midst of reading.
Also, first hand experiences are welcome to be shared!:)
Just wanna know more than whats on http://en.wikipedia.org/wiki/Game_testing which i'm still in the midst of reading.
Also, first hand experiences are welcome to be shared!:)
Replies
Any diagnostics is done by programmers not qa. Qa pretty much plays the games and tells everyone else when its broken.
thanks for the answers so far guys!
and yes there is a dictionary of that sort.
msdn.microsoft.com or google search msdn.
That, and verbal communication.
QA: I've noticed there's s--
Me, having worked 14 or so hours daily for the past 9 days straight: No.
QA: Well, there's a--
Me: I don't think so.
QA: But--
Me: I have 35 class A bugs assigned to me. Put yours in the database and assign it to my lead like we're supposed to do, and he'll prioritise and assign it to whomever is better suited for it. [Muttering under my breath:] And it better not be me....
QA: Oh. Okay.
Me: [Walks over 2 minutes later with a cupcake and apologises for being a moody bitch]
Okay, so this isn't exactly how it goes down when crunch gets insane, but pretty close.. :P
Nitewalkr - Hey thx for the link! Looks like a lot to go through though, any idea where I could start?
East - I'd forgive you
Unless you are starting your own company or something you would get taught all this on the job.
Because the way that is taught might not be the most efficient and can be improved upon by looking at how other people do it.
Crasong: Smoketests are a commonly used system in software development for ensuring that the basic functionality of software is there BEFORE you send the code to others for testing. Google: http://msdn.microsoft.com/en-us/library/ms182613(VS.80).aspx
Asset testing is used to perform checks on the assets AFTER they come from your DCC via the exporter. The exporters should prevent any errors in the assets by refusing to let bad assets get out of the authoring package, but this won't always happen. Issues found with the asset testers SHOULD be fed back to the tools programmers to update the exporters, thus catching asset issues earlier in the project.
Asset testers are also used to make sure that the assets are in sync with the code - sometimes an update in code may require additional information to be encoded into the source art/audio, and perhaps there are still some assets that exist without this information. These assets worked properly before the code update, so are not bad assets per se, but they are now out of sync with the code. The asset tester should be able to identify these assets.
Wait what? I don't even...
Wow there's so much I don't understand! In the higher levels of QA, would i need to understand the intricacies of this part?
I understand and like the Issue and Bug report creation in JIRA so far.
It's cool that you're trying to get as much info as possible on the subject, but really there isn't a great deal to it.
It's understanding the routine of testing (this will vary from studio to studio), creating solid test plans, understanding the bug priority ratings (how severe the bug is) and keeping track of already listed bugs (nothing worse than receiveing the same bug five times and from the same person!).
Learning the bug tracking software is the easy part. At my former studio we've used TestTrack, Mantis and Hansoft. All of which are simple to use and are easy to learn (wouldn't need more than a day to get the gist of everything).
The biggest thing is making sure all your bugs are clearly written, screenshots/videos are provided (if neccessary), the bugs are being produced on the latest build of the game (not from a four or five builds ago) and are assigned to the right people.
As lead, you'll most likely be doing more of the managerial stuff and the scheduling (but once again, this varies from studio to studio as well as staff numbers and project scope). So it's definitely vital you understand the software you're using and understanding how to get the most out of your QA team.
Best of luck.
http://gambit.mit.edu/
They've got a summer program where they send people from Singapore to MIT in Boston to work on game projects. I chanced out with the tests and interviews, and got the role of QA lead on one of 6 teams. And QA is entirely new to me, but it's something I've always wanted to try. (some soul searching in my future career here)
All in all I'm just in love with the game dev process, working on a team will always be my number 1 motivation. Thx for the insight!
P.S I should be down in Boston from early June till early August.
I usually go bypass through the VisualStudio.net to find something that I dont understand. Mostly it is used to understand the libraries of C/C++ and C# in most cases.
But their search engine is to help you resolve the understanding issue. like if you dont know whats BSOD you type it there and it will give you the links to go forth and see how many people figured out before you that it means "Blue Screen of Death"<.<
And other terms that are used in the Software industry in general. and somewhat in game industry.
If you state the problem in PM or here I'd be happy to help you out with it.
Nitewalkr - Then I'll get to reading whatever comes to mind ^^ thx a bunch!
Of course if you're in QA you'll also need to know the version control software. Such as Perforce, alienbrain, sourcesafe, subversion.
My advice is to not throw around buzzwords in your bug reports unless you really, really, know what you're doing. Because the person who gets your bug won't be impressed.
Nothing is more frustrating than getting bugs back all the way to modelers and then having the asset skinned, exported, etc. again, when all it would have taken was the modelers (or whoever caused the bug) being more careful and checking their assets properly - this is especially important if you're out to catch clipping bugs or other visual stuff that's hard to check in an exporter.
Generally I'd wish modelers and animators would be given more time to properly review assets before passing them on to the next step in the pipeline. But in many shops that just won't happen due to time constraints and it all ends up with QA. Funny enough, this way it takes even more time and admin overhead to fix than doing it proper right away.
It's not just this, it's using specific terminology but using it incorrectly in a bug report that can cause issues. Using plain English is better.
Anyhoo, your creating a guide to the issue probably without being able to verbally communicate (it would take forever if you had to talk through each bug) so as above, simplified details and concise information! Teach your team methodical observation and reviewing skills and never get stuck in a pattern, change up the areas and focus so complacency is never a problem.
I doubt I'll be incompetent, but I'm by no means an experienced pro either, I'm still a student in the learning process. Although I will be working with other students as well, and that this is a student oriented program I'm in, the projects we will be working on would be real.
QA is a new avenue that I want to explore, and aside from playing and creating reports, I am not aware of what tools are used in the QA process and how they work, hence the question that I posted here in this thread.
Your advice is invaluable to me all the same, and you have my thanks!
(Just wanted to clarify that the people I will be working for and with are aware of my inexperience =x)
"My advice is to not throw around buzzwords in your bug reports unless you really, really, know what you're doing. Because the person who gets your bug won't be impressed."
This is VERY true. I have actually gone to the length of writing a tutorial for the testing team on what terminology to actually use. It's REALLY annoying to get a bug that says textures are missing when it's actually neck clipping. I shouldn't have to spend time translating 'QA speak' to 'dev speak.'
Honestly though, all of the software I've used, both as QA and as a dev, are super easy to learn. The most important thing is that you have common sense, really, and can apply this to what you're doing. A bug is a bug is a bug...doesn't matter what software they're entered in.
...unless it's Jira....
Do share:) my friends says his place uses JIRA in house.
http://en.wikipedia.org/wiki/Revision_control
You could think of it being like autobak for 3dsmax but it also links comments to your files. Or a way of saving "undo" versions across a project.
Hmm, so I assume it's what we use Tortoise SVN for here at work?
yes, except from an art point of view you'd use it for binaries as well as source files (eg: for texture files)
Actually, right there is another tip for QA: lists are awesome.
- They're easy to write
- They're easy to read
- They break things down into steps
- And have immediately clear structure
Most writing would be more effective in list format than paragraphs.They *should* teach you everything you need to know there. When I was in QA, I had a week long training session to get the basics, and then had people watching my back for another week afterwards.
This.
I know this ain't game art related, but it's definitely informative! Everyone's part of the greater good right?