Well it really depends on what questions they ask you. Here are a few of the questions I was asked when I landed my old QA job.
1. What area of a game do you think would be most difficult to test?
2. What area of a game do you feel would be easiest to test?
3. What TYPE of game do you feel would be easy/difficult to test?
4. What do you think would be your strongest/weakest areas of test?
There are a few things you will need to communicate to them as well. Things like how you would run a particular type of test.
I'm not sure how much it will help you in your interview but here are my hints to better testing.
General Notes:
Remember, it is a job. Treat it like one. If you are having a great multiplayer game and you run into a bug, stop and bug it. If this makes you lose the match or fail a mission, oh well...it is your job. There is a big difference between "testing" and "playing". Testing is a lot of fun and very rewarding, but you have to be willing to "beat your head against a brick wall".
It is also important to note that no matter how minor it is, a bug should be reported. As a tester it is not your job to decide how important a bug it. That is a producer's job.
DO NOT ignore bugs that fall outside of your area. If you are mission tester and you see an art bug, stop and bug it.
It is also important to see when a bug is "general". This means if you see a problem with a mail box, it is going to be present with every occurrence of that mail box model in the game. It only needs to be bugged once, not every place the mail box appears. This goes with gameplay bugs too, if my character's arm bends un-naturally when I play a certain animation while holding a two handed sword, it will likely be the case with ANY two handed sword. Not just the one you happen to have seen it with.
Another pointer is to make sure you spend just as much care inputting a bug as you do finding and narrowing it down. A poorly written bug is something that can cause a lot more work for both you and developer, so make sure to double and triple check your work. I like to use the PAL system when I can. This means "Problem - Action - Location". For instance if I have a bug that is "I get stuck when I jump in this trash bin!" I would write it, "The player becomes soft crashed (problem) when jumping into (action) the trash can model "blue_trash_can" in the red light district (location)". It is very important that you do not limit yourself either. Use as much information possible to make sure the bug is clearly communicated. But don't be redundant either. Oh, and always try to include a screen shot or video. They are always helpful...but don't rely on them. Always write your bugs as if you do not have a screen shot. Consider the SS or video icing on the cake.
Missions/Activity/Diversion Testing:
It is usually a
![G o o d [Good]](/emoticons/g_o_o_d.gif)
idea to break each component of a mission down and then do whatever you can with it. For instance there could be a mission where a monkey steals a banana and you must get it back and return it to the store. In this mission you have the player, the monkey, the store and the banana. From here you try to mix and match events and statuses. First take the player. The player can be killed, so lets kill the player character before the monkey gets the banana, after the monkey gets the banana, after the monkey eats the banana, after the player gets the banana back, etc. So when starting to test a mission, write down on a note pad all the players in a mission, and try and do all kinds of crazy things to each of them. It may boring and methodical at times, but you must also be creative with what you do to them.
Animations:
Talk about boring! Basically you need to try every animation with every variation possible. So if you are testing a game where you can have lots of weapons, you need to test jumping in place with every weapon type, jumping forward with every weapon type, jumping backward with every weapon type, standing still with every weapon type, ETC. Remember that unless they vary greatly in size or shape, most similar weapons will react the same. So "Cleaver A" is going to act the same as "Cleaver B".
Art:
Look for all types if visual anomalies. z-fighting: is when there is two polygons are fighting for the same z plane. This causes the area to flicker back and forth between the two. Seams: small gashes where two pieces of geometry to not meet flush causing a gap. Misshapen collision: ever stand on an object and the player character appears to be floating? That means the collision does not accurately reflect the visual model. Some objects are missing collision entirely causing the PC to clip (pass through) through them. There are a bunch of other art bug types, but it would take me all night to list them.
Standards: All hardware companies have a list of standards that a piece of software must ad hear to in order to be released. Things like; if the game supports a paused state, the game must pause when the controller is disconnected. You want to make yourself SUPER important to the QA department? Memorize the TCR standards.
It is getting rather late here, so I'm sure there is plenty I am forgetting. But this information should get you on your way to impressing those who will be interviewing you. Enjoy!
PS: Here is a link to a Special Interest Group for QA. http://www.qasig.org/index.html