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

201–210 of 269 posts

Re: Maybe getting rid of your QA team was bad

#201

Post by WrongAssumption »

feoren wrote: post #161
ponector wrote: post #132

Earlier quoted context omitted.

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.

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

Re: Maybe getting rid of your QA team was bad

#202

Post by dredmorbius »

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.

Generally, "The German Tank Problem":

https://en.wikipedia.org/wiki/German_tank_problem>

There are similar methods used in estimating wildlife populations, usually based on catch-release (with banding or tagging of birds or terrestrial wildlife) or repeat-observation (as with whales, whose fluke patterns are distinctive).

Re: Maybe getting rid of your QA team was bad

#203

Post by jSully24 »

wrs wrote: post #123
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…

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.

We do a similar thing but call it a bug hunt.

Not only do we uncover bugs, it’s a great way to get the whole company learning about the new things coming and for the product team to get unfiltered feed back.

Re: Maybe getting rid of your QA team was bad

#205

Post by jSully24 »

mb7733 wrote: post #191
JohnFen wrote: post #175

Earlier quoted context omitted.

> Is someone using story points as a metric of anything other than forecasting? Very nearly every company I've worked at that uses Scrum uses story points, velocity, etc., as a means of measuring how good you or your team are. Forecasting is a secondary purpose.

Don't teams assign points to their own tickets? So how could one compare the points between teams?

Yes. But many Sr. Leaders just see a number so it must also be a metric you can use for measurement. They do not understand it’s real use.

I picture a construction company counting the total inches / centimeters each employee measured every day. Then at the end of the year firing the bottom 20% of employees measured in total units measured in the last 12 months.

Re: Maybe getting rid of your QA team was bad

#206

Post by ChrisMarshallNY »

Testing has always been a huge deal with me. I tend to work alone, so I usually have to test my own stuff[0]. I’m pretty brutal. I learned from the best. I really feel that the level of testing I went through, for most of my career, would have a lot of modern devs, curled up in a fetal position, under their desks, whimpering.

We are currently in a “phase 2” test, of the project we’ve worked on, for the last year or so. It has shown us some issues (nothing major, though). Phase 1 testing showed us some nasties.

I had to force the team to do all this testing. They would have happily released before phase 1. I don’t think it would have ended well.

[0] https://littlegreenviper.com/miscellany/testing-harness-vs-u...

Re: Maybe getting rid of your QA team was bad

#207

Post by guhcampos »

BoxFour wrote: post #160
guhcampos wrote: post #156

“ To these folks, it feels like giving a damn is a huge career liability in your organization. Because it is.” And it’s easy to see why. Software Quality, Cose Maintainability, Good Design. These things only matter if you are planning to work on that company for a long time. If you’re planning to stay a couple years then hop to the next company, the most optimal path is to rise fast by doing high visibility work, the…

> Startups work the same. If this product becomes unmaintainable in 5 years, who cares? This is a reasonable stance for a startup to take. The majority of startups likely won't last five years as they tend to fail. Being alive in five years with technical debt is a good problem for most startups to have, because that means they managed to make it five years.

Exactly. That’s why I say I don’t like it, but understand it. I enjoy the fast paced and highly creative environments of startups more than the politics and bureaucracy of corporations, but the short term vision bothers me a lot. The result is I choose to work for midsized companies, or established startups. I kind of specialized in working on the growing pains of companies in their first hundred of engineers.

There’s a lot to say about startup culture and the growth mindset, but I don’t consider it necessarily evil. It exists, lots of the products we use and love would be impossible to build without it. It can be extremely harmful, though. It burns out people, it leads to excessive risk taking, it favors aggressive, invasive marketing, it rewards reckless management - yet it works.

It isn’t good or evil, like mostly everything in the World. It’s just… there.

Re: Maybe getting rid of your QA team was bad

#208

Post by hedora »

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 best approach I’ve seen is to do all of the above.

- Have QA run pessimal versions of real use cases. Trying to sell a word processor to lawyers? Format the entire US legal code and a bajillion contracts in it, then duplicate it 10x and start filing usability/performance bugs.

- Have the engineers test everything with randomly generated workloads before committing. Run those tests nightly, and fix all the crashes / failures.

- Have Product Management (remember them?) work with marketing and sales to figure out what absolutely has to ship, and when.

Make sure it only takes one of the above three groups to stop ship, and also to stop non-essential development tasks.

Re: Maybe getting rid of your QA team was bad

#209

Post by kristjansson »

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…

At $website, we used to call that “swarm”. All features had to go through swarm before being released, and all product managers were made to participate in swarm.

Its demise was widely celebrated.

Re: Maybe getting rid of your QA team was bad

#210

Post by spinningD20 »

natbennett wrote: post #182
spinningD20 wrote: post #86

Earlier quoted context omitted.

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.)

I'd call it something like "Risk analysis, identification and mitigation group"
Post reply on HN