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

171–180 of 269 posts

Re: Maybe getting rid of your QA team was bad

#171

Post by duderific »

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…

I'm kind of in the same boat re story points and Scrum metrics, but sometimes we can get management buy-in to create a ticket to do this sort of thing, if it's seen as high value for the business.

Re: Maybe getting rid of your QA team was bad

#172

Post by krisoft »

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…

> I've been in these test session where we have generated 100 bug tickets in an hour.

Is that like… usefull to anyone? Especially if they are duplicates. It feels to me that 10 different bugs is enough to demonstrate that the feature is really bad, after that you are just kinda bouncing the rubble?

Re: Maybe getting rid of your QA team was bad

#173

Post by SkyPuncher »

fizx wrote: post #104
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…

How often did you release?

That's my question as well. Bug free code is not the goal. Valuable product is.

Re: Maybe getting rid of your QA team was bad

#175

Post by JohnFen »

Shaanie wrote: post #165
hornban wrote: post #128

Earlier quoted context omitted.

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…

That's not a problem with Scrum, it's a problem with your team. If you're doing a bug bash every sprint, then your velocity is already including the time spent on bug bashes. If it's not in every sprint, you can reduce the forecast for sprints where you do them to account for it (similar to what you do when someone is off etc). If you're competing within the team to complete as many story points as possible that's pr…

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

Re: Maybe getting rid of your QA team was bad

#176

Post by hinkley »

jabroni_salad wrote: post #169
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…

My idea of the pendulum swinging back is 'you build it you run it', personally. Don't like the oncall pager? don't make it ring.

The hard part for most people is learning to tell the devil in a necktie to fuck off every time they try to sweet talk you into volunteering for that kind of pain. Also with no recognition or compensation.

All it takes is one person on my team to defect and support an untenable amount of tech debt, and everyone on my team has to pay for it.

Re: Maybe getting rid of your QA team was bad

#177

Post by hinkley »

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…

We've been through snake oil and pyramid schemes and now we have settled on depeche mode.

Re: Maybe getting rid of your QA team was bad

#178

Post by tester756 »

mschuster91 wrote: post #6

Another part is that there is barely any training for QA people. Even your average CS course will only graze the top of the topic, most usually some prof droning on about Java unit tests on some really old version of Java and a testing framework just as old. There are no "Software Quality Assurance" academic degrees, there's barely any research into testing methodologies, there's barely any commercial engagement in t…

>Another part is that there is barely any training for QA people

What training is in your opinion needed?

Re: Maybe getting rid of your QA team was bad

#179

Post by pierat »

Shaanie wrote: post #165
hornban wrote: post #128

Earlier quoted context omitted.

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…

That's not a problem with Scrum, it's a problem with your team. If you're doing a bug bash every sprint, then your velocity is already including the time spent on bug bashes. If it's not in every sprint, you can reduce the forecast for sprints where you do them to account for it (similar to what you do when someone is off etc). If you're competing within the team to complete as many story points as possible that's pr…

> That's not a problem with Scrum, it's a problem with your team.

I've seen that justification time and again, and it feels disingenuous every time it's said. (Feels like a corrolary to No True Scotsman.)

I've also seen scrum used regularly, and everywhere I've seen it has been broken in some fashion. Enough anecdata tells me that indeed Scrum, as stated, is inherently broken.

Re: Maybe getting rid of your QA team was bad

#180

Post by ultrasaurus »

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…

Ah the classic: How do I improve quality in an org 'without any regard for quality'? :)

But assuming that everyone cares about quality (I know, a big leap), what has worked for me is: tagging stories as bugs/regressions/customer-found-this and reporting on time spent. If you're spending too much time fixing bugs, then you need to do something about it. New bugs in newly written code are faster to fix, so you should be able to show that bug bashes make that number going down quarter over quarter which contributes to velocity going up.

Alternately (and not scrum specific) I've had success connecting a CSM/support liaison to every team. Doesn't give you a full bug bash, but even one outside person click testing for 20m here and there gets you much of the benefit (and their incentives align more closely with QA).

Post reply on HN