0
\$\begingroup\$

I've been interesed in a career in Video Game QA for a long time now. I've participated in roughly a dozen+ public/closed betas for different games, everything from FPS, MMO, MOBA and RTS, as well as a lot of early access Indie Games recently.

I'm not some 12 year old kid who thinks playing video games every day will be fun. I know it's tedius work with strict deadlines and a lot of pressure. I enjoy the analytical side of the process and I would like to make this passion a career.

I currently have a few upcoming closed beta weekends scheduled that I'm going to be participating in.

What are some ways I can use these to really improve as a tester?

Anyone in this line of work that would be willing to share some pointers for what type of experience people hiring for a QA job would be looking for, besides the obvious; analytical, attention to detail, communication, etc

Additional information: Feel like I should also mention that I have a lot of programming experience as well. I'm currently a Software Engineering major in my final year, but what I'm really interesting in is QA.

Thank you

EDIT:: I'd like to get this back opened so let me see if I can word this more appropriately.

What are some professional Game Functionality/UX Testing methodologies that I could apply to an upcoming Closed Beta Weekend event for WildStars or Elder Scrolls Online.

I'm looking for information that I could use to provide a thourough evaluation of game aspects that I could then include in a Resume or Testing Profile/Portfolio to show a potential employer "This is how I planned my session out, this is how I executed it and this is what I found."

I hope this is less open ended then my original post.

\$\endgroup\$
5
  • \$\begingroup\$ Did you actually look for testing jobs and get rejected? You sound capable. Why not send your resume? If you want to learn about QA, it's not something that can be covered in an answer. There is lots of information online. In the end, a lot of testing is done hands on by playing the game many time and trying out everything possible. In addition some testing is done programmatically. \$\endgroup\$
    – AturSams
    Commented Feb 27, 2014 at 20:22
  • \$\begingroup\$ @ArthurWulfWhite I did actually get rejected from Turbine a few years back. Guess it has made me a little gun shy so I've been focusing more on school and trying to get into more Betas before going for it again. They ended up calling me agian a few months after that and offered me a temp position but financially it was an impossible move for me. Wish I had taken it now but it would have been a pretty drastic pay cut for a job I wasn't guarenteed to have in 3 months. \$\endgroup\$
    – Prototype958
    Commented Feb 27, 2014 at 20:31
  • \$\begingroup\$ It sounds like you made a reasonable decision. I guess you need to keep trying. Sometimes money is a major deal breaker but other times you need to weigh in other factors. In Japan for instance the average pay in the gaming industry is disappointing but what can you do? It's all a matter of demand and supply. What I'm trying to say is that you'll learn what you need on the job. Not all jobs are the same. Keep doing what you can till' you get the job you want. \$\endgroup\$
    – AturSams
    Commented Feb 27, 2014 at 20:41
  • \$\begingroup\$ Unfortunately, even with your edit, you're asking the kind of question that is better asked on a more discussion-oriented forum (there's a list in the help center): by asking for "some methodologies" you're asking for a list of equally valid options. I'm sure the Game Development Chat would be interesting in discussing this topic once you get the requisite reputation (20) as well. \$\endgroup\$
    – user1430
    Commented Mar 1, 2014 at 17:07
  • \$\begingroup\$ @JoshPetrie Thank you, feel free to close this topic then I suppose \$\endgroup\$
    – Prototype958
    Commented Mar 1, 2014 at 21:22

1 Answer 1

Reset to default
2
\$\begingroup\$

1) Learn to log quality bugs. Finding a bug is one thing, presenting it in a way that a developer understands why the behavior is a bug and having enough detail to actually fix it without wasting time is a HUGE asset.

  • Clear concise title (should not be vague or unclear "Bug!!" is not a helpful title, "Character clips through can clip through wall in World 1 Act 2 while carry an ammo crate" is better)
  • Steps to reproduce (always try to reproduce the issue and then list the steps to do so clearly)
  • Severity of the issue (helps in triage, the game crashing will most likely trump the color of a characters cape not being correct)
  • Screen shots if possible
  • Environmental data (what hardware is in use? Operating system? Version / Build of the software)
  • What the expected behavior was (this is your reasoning for thinking what you're logging is a bug)
  • What the actual behavior is (clearly define the actual behavior)

2) There are always bugs, always. Know that there will always be bugs, you can never find them all especially in complex software. There is a trade off between time and risk. Always try to prioritize testing the functionality that would impact the most users first and provides the most return on time spent testing.

3) Mentally prepare yourself by asking how you would test something that is open ended. In some companies there are really strict requirements to test against, a lot of times this isn't the case. If a developer told you they implemented the "save" functionality and send you a build but no requirements, stop and think if you can't come up with a list of 30+ questions / things to test over the next 10-15 minutes think again.

4) If you can code (which you say you can) pick up a scripting language, Python or Ruby for example. Use them. Make side projects. Make small utilities. Become so comfortable that you don't have to look up syntax and can write a script that does something useful quickly. Automating menial tasks that you have to do in your daily testing is a huge asset, even if it isn't directly automating testing of the software.

I do not work in the Gaming Industry, but do QA for a living and most of this should carry over.

\$\endgroup\$
1
  • \$\begingroup\$ Thank you for taking the time to identify some of the important aspects of testing for me. Most of these I've learned/understood already, but I'm glad to see them re-enforced. Tells me I'm on the right path. I think one of my problems is that I've never had any directed test cases with specified conditions, it's always been public/invite only betas or stress tests so I have no experience looking for specific issues, just roaming around trying to break things. \$\endgroup\$
    – Prototype958
    Commented Feb 27, 2014 at 20:59

Not the answer you're looking for? Browse other questions tagged .