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

181–190 of 269 posts

Re: Maybe getting rid of your QA team was bad

#181

Post by godelski »

philk10 wrote: post #145
godelski wrote: post #125

Earlier quoted context omitted.

> I don't get measured on bugs found so there's no pressure on me to find stupid bugs just to boost my figures. Sounds like the right incentive structure. If you don't mind, how are you judged? Do you feel like the system you're in is creating the appropriate incentives and actually being effective? Certainly this example is but I'd like to know more details from an expert so I can update my understanding.

The system is really effective, I wanted to work at a place where the cliche "everyone cares about quality" is actually true and I found it - devs test, designers test, I test, customer has the chance to test the latest build every 2 weeks so that we can check that our quality checks are aligning with theirs. It gets to be a game of 'can the devs get it past my checks' and 'can I find new ways to trip them up' which…

That's cool to hear. I also like the periodic table on your team's site haha. Looks like great philosophy

Re: Maybe getting rid of your QA team was bad

#182

Post by natbennett »

spinningD20 wrote: post #86
natbennett wrote: post #80

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

Doing every quality activity "after the fact" I agree is the issue. That's the root of the problem you're seeing, not that there was a separate quality team.

It’s not the “separate” part that I think is ridiculous. It’s the fact that the team is named “quality assurance.” It relies on a metaphor from manufacturing that’s entirely inappropriate for software.

If you want to call it “Testing and Exploration” you’d get no argument from me. (Though I do think you’ll find that team is hard to staff.)

Re: Maybe getting rid of your QA team was bad

#183

Post by hj3939393d »

tstrimple wrote: post #137
serial_dev wrote: post #111

Earlier quoted context omitted.

Even as a developer (mobile app developer) I feel like one has to be careful not to work on "cost center" things. Accessibility, observability, good logging, testing infrastructure improvements, CI/CD tweaks, stability, better linting and analyzer issues are all important, but you will be rewarded if you ship features fast. This year I spent too much time on the former because I felt like that's what the team and app…

The purpose behind all those things you were pursuing (apart from accessibility) should have been to increase the rate at which the team is able to ship features. If your work on these items over the course of a year haven't demonstrably improved delivery speed, then what value did they actually bring? If they have improved delivery speed and you can show evidence for that, why would you be nervous going into a revie…

> demonstrably improved delivery speed

Thinking this can be reduced to a single metric is the blight of modern software (and business in general, I think). Mapping an individual change to improved delivery speed is in the vast majority of cases an impossible task and any decent developer knows this. It's management+ that wants simple easy metrics since they lack the deep understanding required to do their job well. Software development is - despite management's hopes - not line work. It's much more akin to R&D. The line work gets eaten up by AWS.

Re: Maybe getting rid of your QA team was bad

#184

Post by bluGill »

JonChesterfield wrote: post #164
pjsg wrote: post #103

At the start of my career (late 70s), I worked at IBM (Hursley Park) in Product Assurance (their version of QA). We wrote code and built hardware to test the product that was our area of responsibility (it was a word processing system). We wrote test cases that our code would drive against the system under test. Any issues we would describe in general terms to the development team -- we didn't want them to figure out…

> This meant that you could use fancy statistics to estimate the actual number of bugs left. That's very clever. Precise test case in QA plus vague description given to dev. Haven't seen it before, thank you for sharing that insight.

If there is a precise testcase, automate it. There real value of manual tests is whene they explore to find variations you didn't think of. Your manual tests should be explore x

Re: Maybe getting rid of your QA team was bad

#185

Post by sporedro »

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…

While QA and testing is important, I’m not sure you can convince the people only concerned about profits… I think the “release it fast and patch it later” concept here to stay due to the internet being so accessible. Why bother spending tons of money and time when the users will just report the bugs and you can release updates over the internet they can download. Ever since physical copies of video games and software were replaced mainly by downloads, it seems like patching is cheaper. Of course this leads to horrendous security issues, bad user experience, etc. but who cares as long as the guy on top is maximizing profits.

Re: Maybe getting rid of your QA team was bad

#186

Post by bluGill »

Zelphyr wrote: post #56

I worked at two companies 15-20 years ago that invested in top-tier QA teams. They were worth their weight in gold. The products were world class because the QA team were fantastic at finding bugs we developers didn't think of looking for because we were too close to the problem. We are too used to looking at the happy path. One key attribute to both companies is that it was dictated from on high that the QA team had…

Automated tests take manual testing from 60% to 50% of the time to develop quality software. Valuable, but not a bullet to manual tests.

Re: Maybe getting rid of your QA team was bad

#187

Post by bluGill »

ponector wrote: post #146
alkonaut wrote: post #105

Earlier quoted context omitted.

I love my really thorough QA’s. Yes it’s an antipattern to let me as a dev lean too much on them catching what I won’t. But where I dread even running the code for a minute, they enjoy it. They take pride in figuring out edge cases far beyond any spec. They are definitely worth their weight in gold. It lets developers have confidence when changing things in the same sense a good type system does. For some classes of…

People here are talking about skillful QA worth their weight in gold. Unfortunately people in the industry who have actual power in planning budgets don't think so. An article is right. QA engineers now are viewed as janitors: no one respects then, better to outsource to cheap location.

Depends on industry. Some care about quality, they respect qa.

Re: Maybe getting rid of your QA team was bad

#188

Post by mdavidn »

ponector wrote: post #138
mikestew wrote: post #130

Earlier quoted context omitted.

That’s not because “QA had the final say”, it’s because your QA team were ass clowns. Any QA team that discourages dev from writing or running tests needs to be burnt to ground and rebuilt.

Unless dev is switching to write test 100% of time and become a tester it is highly not recommended to let developers write tests. That QA was not a clown, they've seen some shit... Would you let QA to write features in your production code?

Developers need to write tests so they understand how to structure the application in a manner that can be tested. The test engineer brings a fresh set of eyes and different expectations about how the application should work. That's valuable too.

Re: Maybe getting rid of your QA team was bad

#189

Post by tunesmith »

dylan604 wrote: post #94
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 t…

Unit tests are used to test functions that have only defined inputs, and whose outputs depend only on those inputs.

You can extract a lot of business logic into those kinds of functions. There's a whole art in writing "unit testable code". Those unit tests have value.

What's left is the pile code and scenarios that need to be tested in other ways. But part of the art is in shrinking down that pile as much as possible.

Re: Maybe getting rid of your QA team was bad

#190

Post by nlavezzo »

JonChesterfield wrote: post #167
nlavezzo wrote: post #142

When we built FoundationDB, we had a maniacal focus on quality and testing. So much so that we built it in a language we invented, called Flow, that allowed us to deterministically simulate arbitrary sized FDB clusters and subject them to crazy conditions, then flag each system property violation and be able to perfectly reproduce the test run that triggered the violation. We got to a point where the default was that…

Is this the language in question? https://github.com/apple/foundationdb/blob/main/flow/README....

Yep!
Post reply on HN