Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe getting rid of your QA team was bad

davidkcaudill.medium.com

Post reply on HN
Print view View original

71–80 of 269 posts

Re: Maybe getting rid of your QA team was bad

#71

Post by willsmith72 »

jawns wrote: post #49
blastbking wrote: post #47

Agree with the sentiment of this article but the disturbing ai generated images every paragraph were definitely not necessary - do people actually need to see these?

It did strike me as ironic that the article is about ruthlessly automating to avoid paying QA engineers, and it uses AI to avoid paying illustrators.

not saying this is you, but i get so tired of feedback about ai-generated images along the lines of "you're taking money away from local artists"

it's not one or the other. in my experience it's a decision of "no images" vs "ai images".

in this case, probably "no images" would've been better for the reading experience. but there was never any illustrator getting paid

Re: Maybe getting rid of your QA team was bad

#72

Post by Ensorceled »

I hired a great QA Developer a few months ago. They are building out integration, performance and end to end tests; finding bugs, speeding up releases and generally making things better.

I get asked, every week, if they are contributing and what are they contributing.

It's exhausting, so I can't imagine what it feels like to actually BE in QA.

Re: Maybe getting rid of your QA team was bad

#73

Post by alex_lav »

wmichelin wrote: post #7

This might be my personal experience, but I've never encountered a QA team that actually writes the tests for engineering. I have only had QA teams that wrote "test plans" and executed them manually, and in rarer cases, via automated browser / device tests. I consider these types of tests to be valuable, but less so than "unit tests" or "integration tests". With this model, I have found that the engineering team ends…

+1 to this. My whole career has been spent with QA teams that behave this way.

I worked at a place with a 10 year old legacy product and a 10,000 test case spreadsheet of each manual action a QA tester must perform on that product to greenlight any individual change. Obviously this lead to huge wait times to get anything deployed. Also was pretty amusing to catch all the bugs in production that their exhaustive spreadsheet totally overlooked. Almost as though it did not have value in the first place.

Re: Maybe getting rid of your QA team was bad

#74

Post by importantbrian »

bbarn wrote: post #53
yabones wrote: post #23

Earlier quoted context omitted.

From what I've seen, the value in QA is product familiarity. Good QA'ers know more about how the product actually works than anybody else. More than PM's, more than sales, and more than most dev teams. They have a holistic knowledge of the entire user-facing system and can tell you exactly what to expect when any button gets pushed. Bad QA'ers are indeed a source of noise. But so are bad devs, sysadmins, T1/2 support…

This is a great model, until those people so familiar with the business needs end up.. doing business things instead. It's really hard to keep people like that in a QA role once the business recognizes their value. Kind of the same problem with QA automation people - once they become really good at test automation, they are effectively software developers, and want to go there.

I think that's a compensation problem more than anything else. I've known some QA folks who enjoyed QA and would have stayed in that role if they could have justified the massive differential in comp between QA and SWE or product development. If we valued QA and compensated it at the same level we do those other roles then there would be a lot less difficulty retaining good QA folks.

Re: Maybe getting rid of your QA team was bad

#75

Post by wombat-man »

wmichelin wrote: post #7

This might be my personal experience, but I've never encountered a QA team that actually writes the tests for engineering. I have only had QA teams that wrote "test plans" and executed them manually, and in rarer cases, via automated browser / device tests. I consider these types of tests to be valuable, but less so than "unit tests" or "integration tests". With this model, I have found that the engineering team ends…

Microsoft used to test this way, at least in the team I worked with. SDEs still wrote unit tests. But SDETs wrote a lot of automated tests and whatever random test tools that ended up being needed. The idea was to free up more SDE time to focus on the actual product.

I think that era is over after the great SDET layoffs of 2014/2015? Now I guess some SDE teams are tasked with this kind of dev work.

Re: Maybe getting rid of your QA team was bad

#76

Post by senderista »

wmichelin wrote: post #7

This might be my personal experience, but I've never encountered a QA team that actually writes the tests for engineering. I have only had QA teams that wrote "test plans" and executed them manually, and in rarer cases, via automated browser / device tests. I consider these types of tests to be valuable, but less so than "unit tests" or "integration tests". With this model, I have found that the engineering team ends…

Anecdotally, from my time on Windows Vista I remember an old-school tester who didn't write any code, just clicked on stuff. From what I could tell, in terms of finding serious bugs he was probably more valuable than any of the SDETs who did write code. His ability to find UI bugs was just amazing (partly due to familiarizing himself with the feature specs, I think, and partly due to some mysterious natural ability).

Re: Maybe getting rid of your QA team was bad

#77

Post by hysan »

cableshaft wrote: post #43
yabones wrote: post #23

Earlier quoted context omitted.

From what I've seen, the value in QA is product familiarity. Good QA'ers know more about how the product actually works than anybody else. More than PM's, more than sales, and more than most dev teams. They have a holistic knowledge of the entire user-facing system and can tell you exactly what to expect when any button gets pushed. Bad QA'ers are indeed a source of noise. But so are bad devs, sysadmins, T1/2 support…

> Good QA'ers know more about how the product actually works than anybody else. More than PM's, more than sales, and more than most dev teams. Not disagreeing with this, but there's one thing they won't always be aware of. They won't always know what code a dev touched underneath the hood and what they might need to recheck (short of a full regression test every single time) to verify everything is still working. I k…

> They won't always know what code a dev touched underneath the hood and what they might need to recheck (short of a full regression test every single time) to verify everything is still working.

This is a good point, but there are some QA that do review code (source: me - started career in QA and transitioned to dev). When making a test plan, an important factor is risk assessment. If QA has a hunch, or better when the dev lead flags complex changes, the test plan should be created and then the code diffs should be reviewed to assess whether or not the plan needed revising. For example, maybe the QA env doesn’t have a full replica of prod but a query is introduced that could be impacted if one of the joining tables is huge (like in prod). So maybe we’d adjust the plan to run some benchmarks on a similar scale environment.

I’m definitely biased since I started in QA and loved it. To me, good QA is a cross section of many of the things people have mentioned - technical, product, ops, security - with a healthy dash of liking to break things. However, reality is that the trend has been to split that responsibility among people in each of those roles and get rid of QA. Works great if people in each of those job functions has the bandwidth to take on that QA work (they’ll all have a much deeper knowledge of their respective domains). But you’ll lose coverage if any one of those people don’t have time to dedicate to proper QA.

(I’ll also completely acknowledge that it’s rare to have a few, let alone a full team, of QA people who can do that.)

Re: Maybe getting rid of your QA team was bad

#78

Post by macksd »

wmichelin wrote: post #7

This might be my personal experience, but I've never encountered a QA team that actually writes the tests for engineering. I have only had QA teams that wrote "test plans" and executed them manually, and in rarer cases, via automated browser / device tests. I consider these types of tests to be valuable, but less so than "unit tests" or "integration tests". With this model, I have found that the engineering team ends…

I've seen good QA teams who own and develop common infrastructure, and can pursue testing initiatives that just don't fit with engineering teams. When developing a new feature, the team developing it will write new tests to cover the functionality of the feature, and will own any failures in those tests moving forward. But while they're doing that, the QA team is operating a database of test failures, performance metrics, etc. that can provide insight into trends, hot spots needing more attention, etc. They're improving the test harnesses and test frameworks so it's easier for the engineering teams to develop new tests quickly and robustly. While the engineering team probably owns all of the unit tests and some integration tests - a dedicated QA team focuses on end-to-end tests, and tests that more accurately recreate real world scenarios. Sometimes there are features that are hard to test well because of non-deterministic behavior, lots of externalities, etc., and I think QA should be seen as an engineering specialty - sometimes they should collaborate with the feature teams to help them do that part of their job better and teach them new testing techniques that may be appropriate that perhaps aren't obvious or common.

I would also second another comment that pointed out that good QA folks often know the real surface area of the product better than anyone. And good QA folks also need to be seen as good QA folks. If you have a corporate culture that treats QA folks like secondary or lesser engineers, that will quickly be a self-fulfilling prophecy. The good ones will leave all the ones who fit your stereotype behind by transitioning into dev roles or finding a new team.

Re: Maybe getting rid of your QA team was bad

#79

Post by l72 »

At our small tech company, QA is elevated to a whole different level. The QA lead(s) are involved in all product planning meetings and develop the requirements with the product team. Our QA lead has a phd and two have masters degrees! They know how the application is supposed to work better than most of the developers and play a big role throughout development. In my opinion (as the person that leads the developers), this is how it should work. They aren't some separate team we chunk over stuff to at the end of the day.

Re: Maybe getting rid of your QA team was bad

#80

Post by natbennett »

Strongly disagree with the literal premise of this post. The idea of having a separate team with the mandate to “ensure quality” was always ridiculous. Occasionally it was helpful by accident but it was always ridiculous. “Quality” isn’t something you can bake in afterwards by testing a bunch.

Getting rid of everyone with testing expertise, and treating testing expertise as inherently less valuable that implementation expertise? Sure, you could convince me that was a bad idea.

Post reply on HN