Ask HN: Is QA/Tester profession dead?
20 comments
I think QA is still a very important role in a serious company, we still have a lot of QAs in the company I work in.
We developers do write tests but that is usually not enough and QA always founds meaningful bugs.
IMO a good QA team is still really valuable.
I agree with this. Additionally, a lot of QAs at my company are transitioning to a test automation role where they are writing/coding their tests in addition to their normal work.
Management may not see it that way, but a cunning, experienced tester is invaluable.
The nature of testing may have changed.
For one, the approach to testing is different with more smaller iterations and more powerful automation.
For another, better automation has split testing into more of an automated test developer/pipeline plumber part and an exploratory (manually testing the juicy stuff, the boring routine is handled by automation) part.
The nature of testing may have changed.
For one, the approach to testing is different with more smaller iterations and more powerful automation.
For another, better automation has split testing into more of an automated test developer/pipeline plumber part and an exploratory (manually testing the juicy stuff, the boring routine is handled by automation) part.
Not dead at all. At my current company, 15% of the total tech team is comprised of QA/SDETs. Though, Manual QA is now being replaced with automation. For every new feature we work on, we have to make sure that we have automation ready before we go live into production. We work on Selenium, Appium, Karate for automation. We use ADF for testing our apps on real devices. Our CI/CD pipeline takes care of running the tests and when the tests fail, deployment doesn't happen.
Like every other job, you've to keep yourself updated with the latest.
Like every other job, you've to keep yourself updated with the latest.
For many, the QA/tester was someone not worthy of being a developer because of not having sufficient programming skills. Nowadays the testing frameworks (web front-end!) got so complex and testing stacks so hysterical that QA/tester job is basically full time development job. Thus, developers do the QA/tester job nowadays (which doubles their work).
I didnt know this perception existed. I believe QA would be crucial in avoiding disastrous customer interactions (customers get ticked by the slightest bugs ) and in mission critical software. Didnt a QA guy find out about the bugs in Ubers self driving car dep and Uber still ignored it and then killed a pedestrian ?
Don't think it was a QA. https://techcrunch.com/2018/12/10/report-a-manager-at-ubers-...
Also, when it comes to things like Self Driving, the line between a QA/dev is really not there. Both of them are just writing software since testing such a thing can't be a manual process.
Also, when it comes to things like Self Driving, the line between a QA/dev is really not there. Both of them are just writing software since testing such a thing can't be a manual process.
Yeah. True that. But I guess that just means the job has additional requirements. You can teach a QA guy to write code but its kind of hard for devs to think like a QA.
I started as a QA and made the jump to development simply because it's more difficult to get paid well and be taken seriously in QA. People perceive the job to be less important and require less skill (which isn't necessarily true), in my experience.
The QA/Tester profession isn't dead, but the traditional manual testing role is dying out. Most of the companies I know that use manual QA processes have outsourced the manual QA to teams in Asia (primarily India) and those are only used for legacy products where writing tests are difficult/impossible. My current company (~50 people) doesn't have QA, and we would only consider hiring someone in QA if they were able to write high-quality test code (contractors we've used in the past have written test code but not high-quality). Using GUIs to create automated tests are a no-go. Those people I know with QA backgrounds all have significant difficulty finding new positions, even if they are good (6 months unemployed would not be unusual)
QA (both embedded and external) is extremely far from dead in the game dev industry at least.
I am very interested in how game dev does e2e testing. Arent there millions of strategies that players can follow and the games must therefore respond consistently in all these scenarios ? How is this type of combinatorial explosion avoided ? Any references ?
I haven't done QA in a very long time so unfortunately do not have much detailed insight anymore.
In general, in a AAA studio when I think of "QA" I think of so much more than just game testing for end users.
We have things like:
* Daily smokes for content creators. Embedded QA doing manual (and sometimes partially automated) smokes of core game features as well as our proprietary editor and other tools multiple times a day before new binaries get rolled out to content creators, with the sole purpose of making sure that artists are able to actually work with the build(s).
* _A lot_ of automated runtime testing and automated unit tests (some teams are better with this than others) which QA helps monitor. This can help test various combinations of weapons etc very quickly. Tests for everything from locomotion to weapon-switching, damage output validation, etc.
* Cert testing - before we send a build to MS or Sony our own QA has to go through various certification requirements and approve it. This will include testing not just game features but loading times, build metadata, various security measures, etc.
* Engine integration testing...when game teams integrate new engine drops or features (or when features are even integrated between engine streams and the main release line) things like editor, environment framework, other tools and relevant features, etc are tested on an example data set by QA.
* Full playthrough testing. I don't know for sure which QA department/team handles full playthrough testing and various iterations thereof but I suspect it's our remote QA-specific studio vs in-house QA (although I'm sure they do some of that too).
* And more that I'm not thinking of off the top of my head right now.
And then of course we have the regular team playtests where the entire team plays certain maps in development and files bugs/provides feedback/etc - having a few dozen to a few hundred devs actually playing the thing helps catch various issues with different scenario/equipment combinations, map problems, etc.
In general, in a AAA studio when I think of "QA" I think of so much more than just game testing for end users.
We have things like:
* Daily smokes for content creators. Embedded QA doing manual (and sometimes partially automated) smokes of core game features as well as our proprietary editor and other tools multiple times a day before new binaries get rolled out to content creators, with the sole purpose of making sure that artists are able to actually work with the build(s).
* _A lot_ of automated runtime testing and automated unit tests (some teams are better with this than others) which QA helps monitor. This can help test various combinations of weapons etc very quickly. Tests for everything from locomotion to weapon-switching, damage output validation, etc.
* Cert testing - before we send a build to MS or Sony our own QA has to go through various certification requirements and approve it. This will include testing not just game features but loading times, build metadata, various security measures, etc.
* Engine integration testing...when game teams integrate new engine drops or features (or when features are even integrated between engine streams and the main release line) things like editor, environment framework, other tools and relevant features, etc are tested on an example data set by QA.
* Full playthrough testing. I don't know for sure which QA department/team handles full playthrough testing and various iterations thereof but I suspect it's our remote QA-specific studio vs in-house QA (although I'm sure they do some of that too).
* And more that I'm not thinking of off the top of my head right now.
And then of course we have the regular team playtests where the entire team plays certain maps in development and files bugs/provides feedback/etc - having a few dozen to a few hundred devs actually playing the thing helps catch various issues with different scenario/equipment combinations, map problems, etc.
We’re having trouble finding QA’s to hire at my current company so that may have something to do with there being less positions.
To be fair, we’re not really in a tech hot zone so that might be why we struggle.
To be fair, we’re not really in a tech hot zone so that might be why we struggle.
QA is still much a thing in our company, although not necessarily working in the traditional "assurance" role but rather in a "assistance" role.
Lately, I have been searching for open engineering test positions in Microsoft, and I have found none of QA, Tester, SDIT, SEIT etc.
The same goes for duckduckgo
The same goes for duckduckgo
QA jobs are getting outsourced to cheaper markets outside the U.S.
We have, and other companies around here have as well (Thailand).
Not in East Europe it is not.
Do you have QA in your team? Of no, may I ask why?