Live data from Hacker News

Asking developers to do QA is broken – why anyone should own QA

rainforestqa.com

71–80 of 193 posts

Re: Asking developers to do QA is broken – why anyone should own QA

#71
post #2

I think product owners should do (manual) QA. On their own, and when necessary for scalability reasons also via a small team under their direct control.

Yeah, this is the only thing that practically worked, in a complex product I used to work on. - If you ask the devs to do QA, you'll get no bugs other than the ones they already caught during testing and deployment. - If you have a mostly independent QA team, they will find somewhat silly/trivial bugs like the login page not working in an extreme edge case scenario. - However, when you ask your Product team to own QA…

> when you ask your Product team to own QA, you get the real good stuff

A good QA who is part of the team can do that as well.

Re: Asking developers to do QA is broken – why anyone should own QA

#72
> Every minute spent doing QA is a minute not spent writing code

This is flawed reasoning. 80% of all engineering disciplines is in double checking your results. Bridges, space shuttles, heck even the chips. Only in software do we say that the 20% is 95%.

*edit, fixed mistake.

Re: Asking developers to do QA is broken – why anyone should own QA

#73

Devs doing QA worked fine for us. You need to have a team that actually cares about the product, and you need figurehead devs - not necessarily seniors or team leads, but charismatic people others will fall into line with - who model the behaviours you want. The problem with almost anything else is that it increases the number of hand-offs between groups of differently-aligned people on the route to production. If yo…

My main problem with devs doing QA is that QA is huge, knowing the entire product is hard. In my case, devs were just testing what they changed and never noticed something horribly broken somewhere else. I think all devs should test that what they built works in production (you don't need QA for that), you need QA to keep everything else tested and working.

> devs were just testing what they changed and never noticed something horribly broken somewhere else.

There's your problem. If they broke it but didn't test what they broke, then they changed it but didn't realise they had. "Horribly broken elsewhere" sounds like the sort of thing that should show up in an automated test, no?

If the problem is "we don't have a good enough automated test suite and our architecture doesn't limit the blast radius of changes" then I can see how throwing QA headcount at it might look tempting.

Re: Asking developers to do QA is broken – why anyone should own QA

#74

Dev sometimes aren't the best QA because they think like developers and not like end users. The mindset prevents you from doing things on the corners that end users do. Its like your instincts kick and a keep you safe without the railing where an end user might plow ahead thinking their path is ok and fall off the edge. Devs should do automated unit and functional tests, but after that, get some good QA that do not h…

This can absolutely be learned, enabled, and encouraged by the right guidance and, if necessary, training at the dev-team level. It's just part of the job.

Re: Asking developers to do QA is broken – why anyone should own QA

#75

Earlier quoted context omitted.

Communication is great until someone becomes unreasonable and doesn't want to do something. Trust but the chain-of-command must verify. Shouldn't need to, but it should be there as insurance.

People don’t just randomly become unreasonable halfway through. If they’d be unreasonable, they’d do so from the start. If it happens midway, there’s almost always some reason. That said, I do I agree that the chain of command should always be aware of what’s going on, or have a reliable way to find out.

> If they’d be unreasonable, they’d do so from the start.

It sounds like a sentence about programs, not people. Consider people tend to make mistakes and being flexible in their intentions.

Re: Asking developers to do QA is broken – why anyone should own QA

#76

Why can’t the QA people just live on the dev team? Why do they need to be siloed away or not exist? I had this in my past job. Have 1 QA per two developers, the QA sits with those two developers, and you are constantly telling them when a build is done and on staging. They write tests, do some manual checks, and then tell you how it is going relatively immediately. They also handle the problem of reproducing bugs and…

> Why can’t the QA people just live on the dev team? Because there is little incentive for devs to police themselves and there could be multiple dev teams spanning client/server that needs to be integrated and tested. A slightly better org to own QA would be product team.

Sure there’s incentives for devs to police themselves. I’d rather catch problems early than have a to deal with a shitstorm from pissed off product owners and VPs when bugs are found in production. But our QA person is on another team. I’d much rather have them on my team.

Re: Asking developers to do QA is broken – why anyone should own QA

#77
There's a little bit of an insane assumption in this pitch that PMs should be writing tests because they are the ones that "care a about quality."

With my engineering hat on, I hate this idea because the message that devs don't care about quality (but PMs do) is not how I want to operate.

With my PM hat on, I hate this because having the PM do test automation has got to be the lowest value activity you can ask the PM to do. That is, whatever the PM doesn't get to do because he's writing tests is almost certainly more valuable.

So yeah this pitch is nuts. If your system makes it easy to define tests with no code, awesome and that should be useful by the teams that do testing today. Weird that it isn't their angle.

Re: Asking developers to do QA is broken – why anyone should own QA

#78
post #65

I agree with not asking the developers of the feature. I don't think it should be part of product. QA is a deeply technical job. At GitLab QA gets own department called Quality. They are on the same level as development, design, development, and infrastructure. The people in it are mostly Software engineers in test. For more information please see https://about.gitlab.com/handbook/engineering/quality/

Some of QA is technical needlessly; we think that's a common issue with tooling today. QA today is just not accessible to folks that think about and manage change to the product, namely product folks.

Why don't you think it should be part of product?

Love that your department is called "Quality", implies more metrics-less-feeling before reading the doc.

Re: Asking developers to do QA is broken – why anyone should own QA

#79
post #78
post #65

I agree with not asking the developers of the feature. I don't think it should be part of product. QA is a deeply technical job. At GitLab QA gets own department called Quality. They are on the same level as development, design, development, and infrastructure. The people in it are mostly Software engineers in test. For more information please see https://about.gitlab.com/handbook/engineering/quality/

Some of QA is technical needlessly; we think that's a common issue with tooling today. QA today is just not accessible to folks that think about and manage change to the product, namely product folks. Why don't you think it should be part of product? Love that your department is called "Quality", implies more metrics-less-feeling before reading the doc.

Thanks Russell. In our experience a lot of QA improvements require automation which is more of a software engineering job than a product management one.

Re: Asking developers to do QA is broken – why anyone should own QA

#80
Does a project needs a QA person? It depends. I had projects where QA did offer negative productivity and projects where we spends weeks because we didn't have QA.

I believe the problem is that we do not have good QA professional. Being QA is more the applying a process is understating the projects needs, UX and the process, and being able to delivery on all fronts.

Post reply on HN