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

131–140 of 269 posts

Re: Maybe getting rid of your QA team was bad

#131

Post by justinator »

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…

This dude gets it.

Re: Maybe getting rid of your QA team was bad

#132

Post by ponector »

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…

I've seen developers writing tests with no assertions, or with assertTrue(true). Always green, with 100% coverage!

The same people have been asking: why should I write tests if I can write new features?

And then one senior QA comes and destroys everything.

Once I found that if I press f5 50 times during a minute then backend will go in outOfMemory while spinning requests to the database.

Re: Maybe getting rid of your QA team was bad

#133

Post by debatem1 »

hornban wrote: post #128
wrs wrote: post #123

Earlier quoted context omitted.

At Microsoft back in the day, we called those “bug bashes”, and my startup inherited the idea. We encouraged the whole company to take an afternoon off to participate, and gave out awards for highest impact bug, most interesting bug, etc.

This is a bit of an aside, but I have a question that I'd like to ask the wider community here. How can you do a proper bug-bash when also dealing with Scrum metrics that result in a race for new features without any regard for quality? I've tried to do this with my teams several times, but ultimately we're always coming down to the end of the sprint with too much to do to implement features, and so anybody that "tak…

The team with the lowest bug bash participation this week is the victim err host of next week's bug bash.

Re: Maybe getting rid of your QA team was bad

#134

Post by mikestew »

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…

I can't count how many products I've seen with 100% code coverage that objectively, quantifiably doesn't work.

That’s because code coverage doesn’t find the bugs that result from code you didn’t write, but should have. Code coverage is but one measure, and to treat it as the measure is folly.

(But, yes, I have heard a test manager at a large software company we’ve all heard of declare that test team was done because 100% coverage.)

Re: Maybe getting rid of your QA team was bad

#135

Post by m4rtink »

hornban wrote: post #128
wrs wrote: post #123

Earlier quoted context omitted.

At Microsoft back in the day, we called those “bug bashes”, and my startup inherited the idea. We encouraged the whole company to take an afternoon off to participate, and gave out awards for highest impact bug, most interesting bug, etc.

This is a bit of an aside, but I have a question that I'd like to ask the wider community here. How can you do a proper bug-bash when also dealing with Scrum metrics that result in a race for new features without any regard for quality? I've tried to do this with my teams several times, but ultimately we're always coming down to the end of the sprint with too much to do to implement features, and so anybody that "tak…

Seems like another data point stating sprints don't make sense in real world projects ?

Re: Maybe getting rid of your QA team was bad

#136

Post by VHRanger »

onlyrealcuzzo wrote: post #127
PH95VuimJjqBqy wrote: post #109

Earlier quoted context omitted.

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.

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

Re: Maybe getting rid of your QA team was bad

#137

Post by tstrimple »

serial_dev wrote: post #111
amlozano wrote: post #21

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, ge…

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 review?

Re: Maybe getting rid of your QA team was bad

#138

Post by ponector »

mikestew wrote: post #130
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.

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?

Re: Maybe getting rid of your QA team was bad

#139

Post by asadotzler »

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.

Not really. As QA I always reviewed the checkins since yesterday before opening up the daily build. Between the bug comments and the patch comments, even if the patch itself is a bit Greek to me, I can tell what was going on enough to be a better tester of that area.

Re: Maybe getting rid of your QA team was bad

#140

Post by acdha »

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 think that complicates conversations like this. I’ve seen a range of QA people ranging from the utterly incompetent to people who knew the product and users better than anyone else to people writing code and tackling gnarly performance or correctness issues.

If your company hires the low end of that scale, any approach is going to have problems because your company has management problems. It’s very easy to take a lesson like “QA is an outdated concept” because that’s often easier than acknowledging the broken social system.

Post reply on HN