Read up on the company and play their games. Show them that you don't just want to work for "a studio" -- you want to work for them... Whether that's true or not.

Make sure you have answers for the following questions:
Have you ever worked as part of a team?
How did you find working in a team?
Has there anybody you have ever worked with and not got along with?
What did you do in this situation?
What is your opinion on repetative tasks?
Have you ever worked to deadlines?
Why do you want to work for us?
What do you like about our company?
Why does working in Testing/QA interest you?

Across these questions you will need to get across that you:
Have a passion for games
Can work in a structured team
You have all of the qualities the job ad asks for (look specifically for key words like motivated, self-starter,teamwork, communication, etc)
You will fit in with the company (look on the company website - see if they have certain "Missions" and see if it mentions general office atmosphere)
You're reliable
You accept that repetitive tasks are part of every job
You are generally a nice/friendly person
You are interested in the job role

On the last point (interested in job role) - don't be too pushy! Don't assume you are going to be the next best game designer in under 3 years. Just shpw that you are motivated to work your way up the ranks and that you have personal goals

If you don't mind me asking, what company is the job with?

No need to show "passion" for games -- just be able to demonstrate knowledge of games (that's proof of passion). And like the other poster said, be knowledgeable about the games the target company has developed or published.
And read http://www.sloperama.com/advice/lesson5.htm

On a side note, here are a few questions I've asked when I conducted my latest series of interviews:

- How would you proceed to test your favorite game?

- What kind of informations should always be included in a bug report according to you?

- A major bug pops-up and, for some reason, you are clearly unable to reproduce it. What do you do?

- A programmer on the team overhears you speaking of a specific bug. He immediately volunteers to fix the issue. What do you do?

- A bug that you can reproduce very easily comes back labeled as 'cannot reproduce'. What will you do?

- When you confront a developer with a bug, he tells you that the feature is performing as intended and that the behavior you are depicting is ideal. What will you do?

- When is, according to you, a bug worth to be 'closed'


These are only examples. As you can see, most questions you can expect from an interview cannot be answered by one or few words. It does not matter to them that you've never been in the position you are applying for, they will be expecting you to have informed yourself about the dos and donts.
If you managed to gather sufficient information about the exact job you're applying for and come with the right mindset, answering these questions should be remarkably easy.

There are no straight good answers, but there certainly are bad answers. The worse answer is no answer, or pretending you have answered by dodging the question to a field you feel more familiar with. Most interviewers will definately feel that.

Oh, and yeah, read Tom's lessons. They're a very good warmup :)