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

21–30 of 269 posts

Re: Maybe getting rid of your QA team was bad

#21

Post by amlozano »

This point is brought up in the article but I think it is at the real heart of the issue.

QA is almost always seen as a 'cost center' by the business and upper management. I have a hypothesis that you never ought to work in a department that is seen as a 'cost center'. The bonuses, the recognition, and the respect always goes to the money makers. The cost center is the first place to get more work with less hands, get blamed for failures, and ultimately fired when the business needs to slim up. I think the same thing applies to IT.

This spiral is why QA will always be a harder career than just taking similar skills and being a developer. It self reinforces that the best people get fed up and switch out as soon as they can.

Re: Maybe getting rid of your QA team was bad

#22

Post by philk10 »

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…

the engineering team are usually great at writing tests that test their code, a good QA can test alongside them to find cases they've missed and issues that automated code tests can't find. The QA person doesn't have to spend time checking that the app basically works, they can be confident in that and spend their time testing for other 'qualities' But yes, I've known QA teams that will only find bugs that no one cares about or are never likely to happen - often because they are not trained on the product to be able to dig deep

Re: Maybe getting rid of your QA team was bad

#23

Post by yabones »

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…

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, etc.

Re: Maybe getting rid of your QA team was bad

#24

Post by hasoleju »

I completely agree with the sentiment of this article: It is a big problem that being a "software tester" is not at all as prestigious as being a software engineer. Having someone who really understands how the users interact with the software and systematically covers all behavior in test cases is very valuable.

I experienced both worlds: I worked in an organization where 4 QA engineers tested each release that was built by 6 software engineers. Now I'm in a situation where 0 QA engineers test the work of 8 software engineers. In the second case the software engineers actually do all the testing, but not that systematically because it's not their job to optimize the testing process.

Having someone with the capabilities of a software engineer who's daily work is uncovering defects and verifying functionality is important. Paying someone who owns the testing process is more than justified commercially. The problem is: You don't find those people. For various reasons. Therefor you are stuck with making the software engineers do the testing.

But there is hope. There is a new standard released for my industry that requires organizations to have a QA department that is independent of the software engineering department. If they don't have that, they are not allowed to role out there software product complaint to the standard. Maybe this will help to reintroduce the QA Engineer as an important and prestigious role.

Re: Maybe getting rid of your QA team was bad

#25

Post by BiteCode_dev »

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…

Frameworks like playright can record as code user actions and you can replay them in a test.

So you can make your QA teams create plenty of tests if you give them the right tools.

Re: Maybe getting rid of your QA team was bad

#26

Post by righthand »

harshalizee wrote: post #15

This is a symptom of a larger issue in tech where C/E suites are trying really hard to turn engineers into some sort of fungible cogs in the system that can be swapped in and out and in different parts of the system and still have everything work perfectly in order.

Yep I see this a lot where people want swappable engineers and no one is able to understand if you have an engineer working in the Frontend most of the time they will not be acquainted with backend work. Nor is there a need or logical way to keep everyone working across the stack to keep them in this swappable state. Each time you change a persons job they need retraining and orientation. Code is code but a drop down menu is not a database insert.

Re: Maybe getting rid of your QA team was bad

#27

Post by wmichelin »

yabones wrote: post #23
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…

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…

Agreed! I did have some good experiences at my last job with the QA team, but it was definitely a unique model. They were really a "Customer Success" team, it was a mix of QA, sales, and customer support.

These "Customer Support" reps, when functioning as QA, knew the product better than product or eng, exactly how you're describing. I did enjoy that model, but they also did not write tests for us. They primarily executed manual test plans, after deploys, in production. They did provide more value than creating noise, but the engineering team still was QA, at least from an automated test standpoint.

Re: Maybe getting rid of your QA team was bad

#28

Post by philk10 »

cloths wrote: post #8

I can't agree more. > Focus: There is real value in having people at your company whose focus is on the quality of your end product. Quality might be “everybody’s job”…but it should also be “somebody’s job”. Yes indeed, naturally every person have just one focus, having dedicated person focus on QA is important. Another practice, or buzz word (or used to be buzz word:) ), Exploratory Testing, which can pretty much be…

That's pretty much my role - I don't write test cases, I'll explore the system and try to find issues that the devs have missed. Then they learn from what they missed so I have to explore more to find other types of issues.

Re: Maybe getting rid of your QA team was bad

#29

Post by reactordev »

ptmcc wrote: post #17

I stepping-stoned through QA on my way into development, now a decade something ago, and this part stands out as especially true in my experience: > This created a self-reinforcing spiral, in which anyone “good enough at coding” or fed up with being treated poorly would leave QA. Similarly, others would assume anyone in QA wasn’t “good enough” to exit the discipline. No one recommends the field to new grads. Eventual…

>anyone in QA wasn’t “good enough”

This is why. Engineers have some of the most inflated egos that they set an extremely high bar for being “part of the club”. Sometimes that’s corporate policy (hire better than you) and sometimes it’s just toxicity (I am better than you). Without realizing that the most valuable skills they could learn are soft skills. I’m open to finding anyone willing to code. Whether it’s from QA, sales, Gerry’s nephew, recent CS grad, Designer turned coder, or that business analyst that taught themselves Python/Pandas.

A good QA team is sorely missed. A bad QA team turns the whole notion of QA teams sour. Just the same for development teams :D

I think devs are first line of defense. Unit tests etc. QA is second line (should we release?), feature testing, regression, UX continuity, etc. There’s value in it if you can afford it.

Re: Maybe getting rid of your QA team was bad

#30

Post by lambic »

convolvatron wrote: post #13
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…

in the classic model, most QA orgs were a useless appendage. partially by construction, but largely because QA gets squeezed out when dev is late (when does that happen?). they aren't folded in early, so they twiddle their thumbs doing 'test infrastructure' and 'test plans', until they finally get a code drop and a 48 hr schedule to sign off, which they are under extreme pressure to do. but every once and a while you…

Not sure why this was downvoted, that second paragraph is right on the money.
Post reply on HN