Comment by ryandrake | Hacker News Reader

Comment by ryandrake | Hacker News Reader

Parent Full thread

QA is not just about running the software, observing problems, and filing them. As you say, eager beta testers can do that!

QA is also about: 1. Exploring every corner of the software, comparing it to the written spec, and measuring any discrepancies, even those not visible to the user. 2. Exploring beyond the corners of the spec and using that exploration to improve the documents. 3. Writing software to automate this exploration and to automate defect-finding in general. 4. Fuzzing and other “red team” penetration testing. 5. Participating in design reviews and contributing towards the testability of the product. In other words working side by side with the developer to ensure the hooks are there to make the software testable and automatable. 6. Monitoring metrics and telemetry to find trends that are emerging post-deployment and getting them documented and reported before they are widely noticed.

And so on.

QA should be a highly skilled, highly technical job, a level equal to developers. If QA at your company is just waiting for a new build to get thrown over the wall so they can manually test it in a vacuum, your company might be doing it wrong.

General software QA does, or at least should, work like that but games QA isn't like general software QA. Since games software is basically a one-shot project (i.e. there's no expectation of long term support beyond a few patches) and not really amenable to automation, games QA are usually non-technical manual testers given fixed scripts to execute.

> Since games software is basically a one-shot project (i.e. there's no expectation of long term support beyond a few patches)

That used to be the norm but it’s not always now. Just look at Minecraft or Terraria, they’ve been getting updates for over a decade now

that's not a new concept; the first everquest is still being updated -- but parent is still right, the 'normal game' has an initial release, a few updates to fix those bugs, maybe a content patch, a few updates to fix those new bugs, and that's about it.

Agree with all of this. Our QA do all this and also provide dev support to designers, content creators and engineers, support build and editor stability in addition to the actual game quality, manage several labs with various hardware and set-up for reviews/playtests etc. and they do a lot of automation work and process improvements/documentation, including a lot of the onboarding documentation because as someone else pointed out, they have a good understanding of all aspects of the projects.

They are highly skilled and technical.

I really like this idea, but what you’re describing sounds more like “Software Engineer, Testing Department” than QA. In my experience, QA functions more like an extension of automated unit tests for the things an engineer hasn’t gotten around to automating yet.

SDET (Software Developer Engineer in Test) as a title/career path seems to have gone mostly out of vogue in the past decade or so unfortunately. Most companies I've worked for seem to hold the philosophy that the engineers developing the features themselves should do the testing. Which is a legitimate viewpoint, but there are of course pros and cons to everything and not every use case is really suited for that.

I think part of the problem for SDET is that pay bands are often different (read: lower) for SDET, and if you are doing SDET you already probably have the skills to be a developer and are going to opt for the higher pay band/career path. A lot of companies seem to hold a weird perspective that SDET is "lesser" or requires less skills than just a typical feature developer.

Reply on news.ycombinator.com