3 ms·

I have known a number of people that work in Quality Assurance for games and they all have pretty much the same story. Though treating employees like this may

I have known a number of people that work in Quality Assurance for games and they all have pretty much the same story. Though treating employees like this may not be ethically ideal, it is certainly not to be unexpected when considering a few points: * The gaming industry has far more people that want to work in it than there is need for. This gives the employer a LOT of leverage. * The type of Quality Assurance that this individual speaks about is not a position that could be considered "highly skilled". Though there are QA positions that require a higher level of expertise and knowledge, the people doing regression testing on a game are not them. Because of this, there is a mentality within the industry that "if you won't do the job, it will be trivial to find someone else that can". * This type of QA the writer speaks of tends to have a productivity curve that is concave. The difference between a really great QA tester and an okay QA tester is probably less than 2x. The type of management style described in this article tends to be pervasive in professions with the aforementioned productivity curve. On a personal level, I do feel for the individual. That being said, the best solution to his problem is to gain a skill set that gives him more leverage in the work force, and get out of low skilled quality assurance testing.

stcredzero 13y ago
> Though there are QA positions that require a higher level of expertise and knowledge, the people doing regression testing on a game are not them. I suspect that's a self fulfilling prophecy there. > The difference between a really great QA tester and an okay QA tester is probably less than 2x. If you're going to treat people like QA people like they're low skilled, and that they really make no difference as people, then you're going to get wind up with people like that. QA can be more than just kitty on the keyboard button pushing. Customer service has been thought of this way, and unsurprisingly, companies got lots of mediocre and bad outcomes. Zappos shows that this doesn't necessarily have to be the case.
- sdoowpilihp 13y ago
  > If you're going to treat people like QA people like they're low skilled, and that they really make no difference as people, then you're going to get wind up with people like that. I wasn't saying that. What I was trying to say is that this style of Quality Assurance tends to have a throughput that scales linearly. There are a lot of professions like that, even highly skilled ones. For example, traditional hand drawn animation (think Bambi or any other classic disney movie) requires highly skilled artists. And though some of those artists maybe faster than others or more proficient, it is nowhere on the scale of what you might see with a profession such as software development. A few A+ developers can probably build a system that can support just as many users just as fast as a much larger C team. The same isn't true for a feature animated film, in which a single person will hit a physical limit to the number of drawings they can create in a day, or for QA'ing a game, where the number of areas that can be tested or bugs that can be found is also bound, and where the quality of the product created does not directly influence productivity by orders of magnitude.
  - stcredzero 13y ago
    > The same isn't true for a feature animated film, in which a single person will hit a physical limit to the number of drawings they can create in a day, or for QA'ing a game, where the number of areas that can be tested or bugs that can be found is also bound, and where the quality of the product created does not directly influence productivity by orders of magnitude. This makes me wonder how Valve does QA. Also, note that QA of this kind has the same kind of scaling as customer service. The raw measured throughput may not vary that much. Quality could vary a lot, however.
recovering_qa 13y ago
> The difference between a really great QA tester and an okay QA tester is probably less than 2x. I did QA for about 5 years at a Fortune 100; my admittedly anecdotal experience was that top performers wrote more Priority 1 issues that resulted in more fixes than many people combined. It depended on the team and the project, but for me it was closer to 6x. Beyond find & fix rates, there is the general quality of a bug, good QA understand the system well enough to quickly & correctly isolate where a problem occurs even without looking at any code. This can result in a ton of saved time for developers. Regression testing is a small part of QA, just because you have a focus area for a particular day doesn't shut down your capability to find bugs in issues unrelated to say, regressions. And for a final tidbit, regression testing (going through bug reports that have already been fixed, ensuring they are still fixed) probably has the lowest find rate out of almost any type of other testing in my experience (in terms of the original issue being 're-broken'), and it should be done by software, not people.

stcredzero 13y ago

> Though there are QA positions that require a higher level of expertise and knowledge, the people doing regression testing on a game are not them. I suspect that's a self fulfilling prophecy there. > The difference between a really great QA tester and an okay QA tester is probably less than 2x. If you're going to treat people like QA people like they're low skilled, and that they really make no difference as people, then you're going to get wind up with people like that. QA can be more than just kitty on the keyboard button pushing. Customer service has been thought of this way, and unsurprisingly, companies got lots of mediocre and bad outcomes. Zappos shows that this doesn't necessarily have to be the case.

sdoowpilihp 13y ago
> If you're going to treat people like QA people like they're low skilled, and that they really make no difference as people, then you're going to get wind up with people like that. I wasn't saying that. What I was trying to say is that this style of Quality Assurance tends to have a throughput that scales linearly. There are a lot of professions like that, even highly skilled ones. For example, traditional hand drawn animation (think Bambi or any other classic disney movie) requires highly skilled artists. And though some of those artists maybe faster than others or more proficient, it is nowhere on the scale of what you might see with a profession such as software development. A few A+ developers can probably build a system that can support just as many users just as fast as a much larger C team. The same isn't true for a feature animated film, in which a single person will hit a physical limit to the number of drawings they can create in a day, or for QA'ing a game, where the number of areas that can be tested or bugs that can be found is also bound, and where the quality of the product created does not directly influence productivity by orders of magnitude.
- stcredzero 13y ago
  > The same isn't true for a feature animated film, in which a single person will hit a physical limit to the number of drawings they can create in a day, or for QA'ing a game, where the number of areas that can be tested or bugs that can be found is also bound, and where the quality of the product created does not directly influence productivity by orders of magnitude. This makes me wonder how Valve does QA. Also, note that QA of this kind has the same kind of scaling as customer service. The raw measured throughput may not vary that much. Quality could vary a lot, however.

recovering_qa 13y ago

> The difference between a really great QA tester and an okay QA tester is probably less than 2x. I did QA for about 5 years at a Fortune 100; my admittedly anecdotal experience was that top performers wrote more Priority 1 issues that resulted in more fixes than many people combined. It depended on the team and the project, but for me it was closer to 6x. Beyond find & fix rates, there is the general quality of a bug, good QA understand the system well enough to quickly & correctly isolate where a problem occurs even without looking at any code. This can result in a ton of saved time for developers. Regression testing is a small part of QA, just because you have a focus area for a particular day doesn't shut down your capability to find bugs in issues unrelated to say, regressions. And for a final tidbit, regression testing (going through bug reports that have already been fixed, ensuring they are still fixed) probably has the lowest find rate out of almost any type of other testing in my experience (in terms of the original issue being 're-broken'), and it should be done by software, not people.