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

91–100 of 269 posts

Re: Maybe getting rid of your QA team was bad

#91

Post by hasoleju »

zabzonk wrote: post #46
hasoleju wrote: post #24

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…

what industry is that?

Mechanical engineering and shopfloor software for factory automation in Europe. There is a new IT security standard released that also includes requirements for the software.

Re: Maybe getting rid of your QA team was bad

#92

Post by spinningD20 »

ThalesX wrote: post #85

I am currently working with a startup that spends a lot of time on building tests that need to be refactored every sprint because it's early stage and the assumptions change. I am shocked at the amount of developer-hours spent on tests that need to be disabled / deleted instead of just hiring 1 - 2 super cheap manual testers that just go through the flows days in and out. For me it's a no brainer, if I were CEO / CTO…

When outsourced, you either A) rely on someone in your org to tell them what to test and what the workflows are, ie use them as a warm body/monkey to click on things for you - this is what most people see QA as, which is silly - or B) you rely on the outsourced QA to know your product and know what is important or what all of the edge cases are.

If your product is non-trivial in size or scope, ie it is not a cookie-cutter solution, then the testing of your product will also be non-trivial if you want it to work and have a good reputation (including during those all-important live demos, poc's, etc).

QA does not mean "click on things and go through the happy path and everything is fine" - not saying you are implying that, but gosh the amount of companies that think it's child's play is crazy.

Re: Maybe getting rid of your QA team was bad

#93

Post by amaterasu »

Ignoring the common trope that developers are bad testers (I am, but not all devs are), QA presence allows teams to move faster by reducing the developer test burden to automated regression, and developer acceptance testing only. Good QA can often assist with those tasks too, further improving team velocity. Also, moving tasks to people who specialise in them is not usually a poor decision.

The best way I've found to sell QA to management (especially sales/marketing/non-technical management), is to redefine them as marketing. QA output is as much about product and brand reputation management as finding bugs. IMO, nothing alienates customers faster than bugs, and bad experiences result in poor reputation. Marketing and sales people can usually assign value to passive marketing efforts, and recognise things that are damaging to retention and future sales.

Re: Maybe getting rid of your QA team was bad

#94

Post by dylan604 »

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…

Unit tests are great when you provide data that the methods expect and are sane. It's not until users get in front of the UI and submit data that you never even thought about testing with your unit tests.

To me, unit tests are great to ensure the code doesn't have silly syntax errors and returns results as expected on the happy path of coding. I would never consider that QA no matter how much you randomize the unit test's input.

Humans pushing buttons, selecting items, hover their mouse over an element, doing all sorts of things that have no real reason but yet they are being done anyways will almost always wreck your perfect little unit tests. Why do you think we have session playback now, because no matter what a dev does to recreate an issue, it's never the exact same thing the user did. And there's always that one little WTF does that matter type of thing the user did without even knowing they were doing anything.

A good QA team are worth their weight in $someHighValueMineral. I worked with one person that was just special in his ability to find bugs. He was savant like. He could catch things that ultimately made me look better as the final released thing was rock solid. Even after other QA team members gave a thumbs up, he could still find something. There were days were I hated it, but it was always a better product because of his efforts.

Re: Maybe getting rid of your QA team was bad

#95

Post by joe_the_user »

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 Q&A teams I've seen worked the way you describe initially except they were valuable.

They weren't there for engineering, they were there for product quality. Their expertise was that they knew what the product was supposed to do and made it did it. Things like "unit tests" help development but they don't make sure the product satisfies client requirements.

If engineering is really on top of it, they learn from QA and QA seems to have nothing to do. But don't let that situation fool you into thinking they are "just creating noise and taking away more value than they provide"

Re: Maybe getting rid of your QA team was bad

#96

Post by JohnMakin »

godelski wrote: post #32

The main problem with QA teams is the same problem with IT teams or even management. If they are doing their jobs well they appear to be doing nothing. This often creates a situation where people need to "justify" their jobs. Usually this happens due to an over reliance upon metrics (see Goodhart's Law) rather than understanding what the metrics are proxying and what the actual purpose of the job is. A bad QA team is…

> This often creates a situation where people need to "justify" their jobs.

On DevOps teams I see this constantly. Usually the best-compensated or most senior "Ops" guy or whatever they're called at the company spends a lot of his time extinguishing fires that were either entirely of his own creation/incompetence, which makes it look like he's "doing something." You automate away the majority of the toil there and this person doesn't have a job, yet this pattern is so insanely common. There's little incentive to do it right when doing it right means management thinks you sit there all day and do nothing.

Re: Maybe getting rid of your QA team was bad

#97

Post by philk10 »

e28eta wrote: post #45
philk10 wrote: post #22

Earlier quoted context omitted.

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 car…

It seems so obvious to me that your typical engineer, who spent hours / days / whatever working on a feature, is never going to test the edge cases that they didn’t conceive of during implementation. And if they didn’t think of it, I bet they’re not handling it correctly. Sometimes that’ll get caught in code review, if your reviewer is thinking about the implementation. I’ve worked in payroll and finance software. I…

I started off as a dev, wanted to change to being a tester/QA but was told by the CEO that "the customers are better at finding bugs than we are so just give the app a quick look over and ship it out" - I left soon after that.

Re: Maybe getting rid of your QA team was bad

#98

Post by philk10 »

hotpotamus wrote: post #66
philk10 wrote: post #38

Earlier quoted context omitted.

When I work with new devs I can often trip them up with basic tests of double-clicking, leading spaces, using the back button on Android. They then learn these and from then on these issues dont appear ( well, OK, it might take a couple of times of a ticket being rejected because of these but they do quickly learn all my tricks ) I don't get measured on bugs found so there's no pressure on me to find stupid bugs just…

I had a buddy who liked to do that kind of thing. I think his favorite trick was just to enter nothing in a form and hit enter to see what happens. It's probably his favorite because it deleted the database on some little thing I wrote at one point and we got a good laugh over it and I got a good lesson out of it.

Yep, I start off by entering nothing, then just spaces, then special characters and then finally get to entering some typical data

Re: Maybe getting rid of your QA team was bad

#99

Post by ncphil »

bgribble wrote: post #65

I was lucky enough to work in a small eng team with 1 full-time dedicated QA person. One of the very few coworkers from my long career that I have really tried hard to poach away from whatever they were doing after our shared workplace went bust. Yes, part of the job was to write and run manual test suites, and to sign off as the DRI that a certain version had had all the automated and manual tests pass before releas…

"Developers should test their own code" is emblematic of a juvenile mindset in people who regularly fire up their "reality distortion field" to avoid the effort of educating themselves on their own operations (and that helps them deny responsibility when things go South). As W. Edwards Deming, bane of all "gut instinct" executives, once wrote, "The consumer is the most important part of the production line. Quality should be aimed at the needs of the consumer, present and future." The lack of a dedicated quality team shows a lack of respect for your customers. You know, the people you need to buy your products or services (unless you're intent on living off VC loans until you have to pull the ripcord on your golden parachute).

Re: Maybe getting rid of your QA team was bad

#100

Post by esafak »

amtamt wrote: post #54

> The most conscientious employees in your organization are the most bitter. They see the quality issues, they often address them, and they get no recognition for doing so. When they speak up about quality concerns, they get treated like mouthbreathers who want to slow down. They watch the “move fast and break things” crowd get rewarded time after time, while they run around angrily cleaning up their messes. To these…

No, just jump ship and let the damn company fail. Fail faster, haha! This is how we have nice things; when bad companies are not propped up.
Post reply on HN