Game Testers
by Travis Bolek · in General Discussion · 07/23/2001 (9:44 pm) · 6 replies
I am interested in becoming a game tester, mostly for experience and I would also like to see how they make games and such. I'm just trying to immerse myself in games as much as possible. I would like anyone who has been a tester before, tell me about it. I am currently in high school, although my last year (hopefully...lol). I just would like to know the ins and outs of it. I know that I would have to work ungodly hours, and of course the game I would be testing would be in a very early form. But what skills would i need to possess? Please someone answer my questions and give me some info that might prove useful.
#2
Also your writing skill have to be good as well. Most people look over that but you have to write down the issues and you have to have reports sometimes, to show to the game dev team. These are all things people look over when wanting to become a "beta tester"
07/24/2001 (4:11 am)
I would Agree with Brendan. being a tester can be a tough skill, a lot of people think you just play and play and then report an issues. Tha is not the case at all. haveing been a tester for some small game dev companies, you have to find all the bigs and you have to be abel to communicate with the dev team at all costAlso your writing skill have to be good as well. Most people look over that but you have to write down the issues and you have to have reports sometimes, to show to the game dev team. These are all things people look over when wanting to become a "beta tester"
#3
I would disagree with those who say that the primary skill of a QA person is to find bugs. This is not really the case. I can design a test plan that will generally find hundreds of bugs in any piece of software - the trick is to find the bugs that matter...
In my opinion, a good QA person is one who can tell you that the interface is good or bad - and WHY. Great ones can tell you how to improve it. They can test a piece of code and find a bug and tell you HOW to reproduce it - sometimes keystroke by keystroke. They don't bother you with bugs that aren't really important in crunch time. They can make intelligent suggestions how to improve your program that don't require a three month rewrite.
Good QA people don't believe any software is ever bug free and they know that it doesn't have to be to ship. They communicate well and they listen to why a problem exists, what's being done to fix it, and how the fix will correct the problem. They often have a good programming background (I programmed professionally for ten years before I got into doing QA work.) QA people are generally non-confrontational, and don't make a lot of remarks about the "crappy" state of the code, but they will defend a point when they feel they are right.
My routine has changed little since I moved out of QA. I generally have lunch with a couple of the programmers in my company every week and I listen to what they are working on, what problems they are having, how they are trying to solve those problems and why they picked that way to go. I ask intelligent respectful questions and I expect to get intelligent and respectful replys. I still sit in on design meetings and listen, make suggestions, suggest alternatives and I don't hesitate to disagree with an assessment of a risk.
Personally, I never work at a job where I am expected to "punch a clock." I set my own hours, work at home occasionally and I have excellent writing skills. (If you have ever designed test plans you know how important it is to be able to examine a design spec and consider all the possible ramifications of each item - what will need testing and what kind of testing will be most effective - without a large number of distractions.) When the crunch comes I work long hours I keep a good attitude, I encourage communication and discussion and I discourage sulking, tempers, backstabbing and negative comments.
I also make it a point to keep up with the technology, I read huge amounts of information each week I think most QA people do as well.
08/01/2001 (5:43 am)
Having done QA for quite a number of years until I shifted directions I would like to offer my two cents. I would disagree with those who say that the primary skill of a QA person is to find bugs. This is not really the case. I can design a test plan that will generally find hundreds of bugs in any piece of software - the trick is to find the bugs that matter...
In my opinion, a good QA person is one who can tell you that the interface is good or bad - and WHY. Great ones can tell you how to improve it. They can test a piece of code and find a bug and tell you HOW to reproduce it - sometimes keystroke by keystroke. They don't bother you with bugs that aren't really important in crunch time. They can make intelligent suggestions how to improve your program that don't require a three month rewrite.
Good QA people don't believe any software is ever bug free and they know that it doesn't have to be to ship. They communicate well and they listen to why a problem exists, what's being done to fix it, and how the fix will correct the problem. They often have a good programming background (I programmed professionally for ten years before I got into doing QA work.) QA people are generally non-confrontational, and don't make a lot of remarks about the "crappy" state of the code, but they will defend a point when they feel they are right.
My routine has changed little since I moved out of QA. I generally have lunch with a couple of the programmers in my company every week and I listen to what they are working on, what problems they are having, how they are trying to solve those problems and why they picked that way to go. I ask intelligent respectful questions and I expect to get intelligent and respectful replys. I still sit in on design meetings and listen, make suggestions, suggest alternatives and I don't hesitate to disagree with an assessment of a risk.
Personally, I never work at a job where I am expected to "punch a clock." I set my own hours, work at home occasionally and I have excellent writing skills. (If you have ever designed test plans you know how important it is to be able to examine a design spec and consider all the possible ramifications of each item - what will need testing and what kind of testing will be most effective - without a large number of distractions.) When the crunch comes I work long hours I keep a good attitude, I encourage communication and discussion and I discourage sulking, tempers, backstabbing and negative comments.
I also make it a point to keep up with the technology, I read huge amounts of information each week I think most QA people do as well.
#4
08/01/2001 (8:56 am)
That sounds fun..
#5
07/03/2008 (11:00 pm)
Game testing could be very frustrating because it's not just about playing the game, it's mostly about spotting even the smallest bugs and/or errors which means you might have to spend hours or even days playing the game over and over again... 
Brendan Rogers
The most important thing is being able to spot a bug/error in the game. Knowledge of how 3d engines work is very valuable to have as well. Its really important for QA testers to communicate thier findings to the Dev team accuratly and simply.
Its all well to love playing games and wanting to be a tester but the best ones are real fanatics.
Testers must play games for hours and hours and hours on end. Although it sounds really cool to play games all day, It gets quite repetative. You must play a single section of the game sometimes for weeks/months.
Its a great place to start in the games industry and work your way up. We have alot of QA test people coming upto Artist or programmer positions.
If you have worked on quake mods or game demos , thats an excellent foot in the door as well as programming or artist skils. If you really want to get a job as a tester, approach as many game companies in your area that you can (in person is even better) tell them you know games inside out and willing to work long hours to hammer out thier bugs. Im sure if you present yourself well you will score a job.
Caliban