Hey, guys.
Rookie QA tester from Sweden over here. Got a QA interview coming up for a game company I’d really like to join, and want to give it my best. I’m still learning about QA so some questions that they regularly ask on the interviews (did some research) are a bit tricky to me. I would be happy to see what you guys would have answered (and why) - not to brainlessly copy your answers, but to see the thought process behind it. I’m probably not getting the job anyway (still a student), but I still want to nail down these questions and learn new things even if I eventually end up being rejected.
EDIT: Removing the questions. I didn’t want to have them visible for too long, in case they may have been personalized for my friend who sent me the questions over. Thank you for the answers down below, pretty helpful.
1 Like
Questions (1), (2), and (4) are purely context-driven. The info given is at least shallow.
The phrases “has been changed or updated”, “timing is everything on this release”, “an agile project” can mean a million different things.
I would suggest coming up with a story narrowing the meaning of these phrases and only answering. There are no facts outside of a story, and the questions just came up with facts.
This question worries me, as testers SHOULDN’T be responsible for this.
We can advise, but we aren’t gate keepers. That is what the project manager is for, as they oversee the entire project. This assumes a waterfall project, where if it’s an agile team, then the entire team would decide this, no singular person.
Personally, I’d rather delay the release then cut corners, as if it is that regimented an organisation, it is likely they have a blame culture and finger pointing, and when it comes back to testing missing things by cutting corners, that is who will be blamed.
3 Likes
Games companies are a good place to work if you dont like sleeping, and you dont like having software that was designed to be testable in the first place. (See my answer to question 4 for more detail.) But If I was in an interview, and I got 4 questions, I’d be sure to provide answers I am confident with sharing.
Q1 : Core Functionality 20% ; New Functionality 50% ; Broad functionality 30%. No point in testing core functionality if higher level tests in the “All” segment should be designed to catch core issues anyway.
Q2 : Verify all bugs that the devs say they have fixed ; then do the release checks , then fill out a report. In that order. Why? Since the bugs you are verifying were high enough priority to fix, they are of value to the TEAM, and to the mission, else the devs would not have attempted to fix them, not fixing them jeopardizes the mission goal. Start the release checks, likely you will spot a thing that got missed in the mad rush that you find yourself in at 5pm on a Friday. That thing is your reason for raising a red flag. File a test report, without doing a full regression test run and make a note about why the report is so blank.
Q3 : This is a trick question that assumes that you don’t have process pain in your teams. Tasks that had no testing identified will probably not be listed, for example.
Q4 : You will become a QA lead at some future point, so a good answer is needed. The right answer is however very context dependent. I would start by making the whole team responsible for quality as my primary message. I would be asking my team to include a small quality related deliverable (not a bugfix, but a quality-improving ticket/task) as a goal in every sprint-goal.
(coda) Software maintainability is increasingly identified as a cost to a project, so anything you do that improves troubleshooting, reliability and overall code maintainability and most of all security (code and penetration security) are quality improvements. To this end many modern teams are trying to cut technical debt, this is largely never true in computer games however - so these teams could forever be in tech debt pain.