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

251–260 of 269 posts

Re: Maybe getting rid of your QA team was bad

#251

Post by PH95VuimJjqBqy »

NegativeK wrote: post #198
ponector wrote: post #138

Earlier quoted context omitted.

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?

I spent a long time in QA. Devs that don't test their own code are usually wasting the QA team's time with garbage. It also tends to cultivate (or is a symptom of) an environment where groups are throwing projects over the wall, so to speak, without tightly integrating QA into the process. This wastes significant amounts of time.

that's exactly what was being described, moat building. It's political rather than effective.

Re: Maybe getting rid of your QA team was bad

#252

Post by PH95VuimJjqBqy »

ahtihn wrote: post #157
ponector wrote: post #138

Earlier quoted context omitted.

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?

Test code is just code. If you can write test code you can write production code. If you can write production code you can write tests. If your concern is that devs don't have the right mindset for testing, you can have them collaborate with a QA specialist to define the test cases and review the test implementation.

better yet, developers write their own tests, QA write their own tests.

QA is a safety net, but they are not the first line of defense.

Re: Maybe getting rid of your QA team was bad

#253

Post by mlrtime »

VHRanger wrote: post #136
onlyrealcuzzo wrote: post #127

Earlier quoted context omitted.

Worked at a company where QA had the final say - and that was by far the most toxic / worst environment I have ever been in. QA also REFUSED to let developers write automation tests, also REFUSED to let us run them ourselves. What a nightmare. YMMV, but just having the final say is not a silver bullet for sure.

You see that with devops often. When they are incentives to block stuff instead of enabling the product they become the roadblock team. It's why Google has SRE instead of devops people largely

SRE's through Error Budgets can also block stuff. They just use a different tool and metric.

Also, the SREs should be knowledgable enough to work on the fix, not just block.

Re: Maybe getting rid of your QA team was bad

#254

Post by mlrtime »

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…

This comment requires some context and nuance.

I've worked with conscientious engineers. Sometimes they are right but their delivery mechanism is broken. Sometimes they are just in the wrong place. If we're building a POC SASS product, it really doesn't need the quality of a avianoics microcontroller. All these trade-offs come with risk and cost, good engineers need to know the difference.

Re: Maybe getting rid of your QA team was bad

#255

Post by Aachen »

PH95VuimJjqBqy wrote: post #109
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…

The QA culture has to be there, not just dictates that the QA has final say. I've seen companies where that's true and it was still trash because the QA were mostly low-paid contract workers who only did exactly what they were told and no more.

this is the internet, where saying a thing doesn't make it true.

have at your claims good sir.

Re: Maybe getting rid of your QA team was bad

#256

Post by fatnoah »

steveBK123 wrote: post #121
pavel_lishin wrote: post #116

Earlier quoted context omitted.

> When I've worked for organizations without QA teams, I introduce the concept of "sniff tests". This is a short (typically 1 hour) test session where anybody in the company / department is encouraged to come and bash on the new feature. We call those bug-bashes where we work, and they're also typically very productive in terms of defects discovered! It's especially useful since during development of small features,…

A good QA person is basically a personification of all the edge cases of your actual production users. Our good QA person knew how human users used our app better than the dev or product team. It was generally a competition between QA & L2 support as to who actually understood the app best. The problem with devs testing their own & other devs code is that we test what we expect to work in the way we expect the user t…

> It was generally a competition between QA & L2 support as to who actually understood the app best.

So true!

Re: Maybe getting rid of your QA team was bad

#257

Post by steveBK123 »

fatnoah wrote: post #256
steveBK123 wrote: post #121

Earlier quoted context omitted.

A good QA person is basically a personification of all the edge cases of your actual production users. Our good QA person knew how human users used our app better than the dev or product team. It was generally a competition between QA & L2 support as to who actually understood the app best. The problem with devs testing their own & other devs code is that we test what we expect to work in the way we expect the user t…

> It was generally a competition between QA & L2 support as to who actually understood the app best. So true!

And to clarify specifically because those who haven't experienced don't understand it...

The uses of your app as intended by the authoring developers never matches the uses of your app out in the wild in the hands of human users.

Over time, power users develop workflows that may go unknown by dev/product/management and are only well understood by QA / L2 support.

The older the app, the more the divergence

Re: Maybe getting rid of your QA team was bad

#258

Post by gluteart »

I joined my current company just months before they started to cut down small QA team we had then. QA Automation was supposed to be the answer. 1.5 years forward - product quality dropped, automation for the client side application barely exists and even those parts that is covered by it prone to bugs.

I tried to draw attention to the fact that at least some manual QA is needed, but even after obvious fail (some people lost their job) managers are adamant. Automation, 'special bug-hunting projects', 'we should concentrate on code quality' lectures, all-hands testing - anything, instead of very obvious solution to get QA team back. Development time is up, regression is often, communication became harder.

The only QA who still works in the company (now in a different role) became invaluable, because he is one of the very few people who deeply understands the product as a whole and knows all the services we work with.

I can't think of another example of so very obvious mistake and solution to it, that's being ignored so relentless.

Re: Maybe getting rid of your QA team was bad

#259

Post by JonChesterfield »

bluGill wrote: post #184
JonChesterfield wrote: post #164

Earlier quoted context omitted.

> 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

Yes, automated tests are better than manual. The subtle point I'd missed is to consider not giving the dev team your automated test to improve the odds they fix the general pattern as opposed to your point instance.

The statistical side to it is really interesting too, still thinking about that.

Re: Maybe getting rid of your QA team was bad

#260

Post by feoren »

WrongAssumption wrote: post #201
feoren wrote: post #161

Earlier quoted context omitted.

> I've seen developers writing tests with no assertions This can be OK if the code executing without throwing exceptions is itself testing something. If you have a lot of assertions written directly into the code, as pre- or post-conditions for instance. But I'm guessing that wasn't the case here.

Why would it be ok to not test the assertions would be triggered if the conditions are bad? How would you verify that the assertions are correct with just a happy path? If you run a code with pre-post assertions, then remove all the assertions the same test will continue to pass.

Agreed: such tests are not sufficient to test the pre- and post-conditions themselves, and are definitely happy-path focused. But such tests may be sufficient to test the happy-path code itself (which the in-code checks are also testing). It would be ridiculous to have an entire test suite with no assertions for these reasons, but it's not ridiculous (in isolation) to see some unit tests with no assertions. In theory -- and this is not advice: theory and practice are different -- but in theory, if you've absolutely air-tightly tested the "happy path", then you've basically proven no other paths occur (short of cosmic rays).

But you could actually make this same argument about unit tests with assertions: do you have any test that those assertions are written correctly? Do you unit test your unit tests? Pre- and post-conditions living "in situ" are the equivalent thing to "control" and test assertions (respectively) living in your unit tests. Would you be more comfortable if the in-situ checks were simply cut/pasted into the unit test? I wouldn't be!

Post reply on HN