Live data from Hacker News

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

rainforestqa.com

181–190 of 193 posts

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

#181

Earlier quoted context omitted.

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.

Yep. People aren't rational, compliant, cooperative actors 24/7. Agendas. Bad days. Illnesses. Family events. So then it's unreasonable and foolish to extend trust unconditionally, perpetually, and without auditing.

If all people were angels, no government (or whoever regulates) would be necessary.

If all people (and systems) were perfect, no backups would be needed.

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

#182

Earlier quoted context omitted.

Terrible idea. The dev team manager is focused on growing new features in the next release. QA is focused on the excellent of the current release. Subordinating quality to new releases is the result. In a similar situation, devops supposedly addressed similar tensions of dev and ops.

QA here, disagree. In this situation QA is focused on the quality of the new features, so they're already excellent when they go out into the current release.

What about ongoing quality and quality regressions of existing functionality?

What happens when the dev mgr asks QA to rush testing? Been There, Done That, Bought The T-Shirt, Said "No," and Tendered a Resignation

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

#183
post #90

Earlier quoted context omitted.

Terrible idea. The dev team manager is focused on growing new features in the next release. QA is focused on the excellent of the current release. Subordinating quality to new releases is the result. In a similar situation, devops supposedly addressed similar tensions of dev and ops.

That's false. QA can also be concerned about growing new features in the next release. We have embedded QA's on our teams. They QA new features, as well as help to triage current bugs.

Anecdotal.

Embedded QA doesn't scale for projects where the teams are larger, or the concerns and complexity are significant.

https://qualitysystemsanalyst.com/2017/10/06/independence-th...

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

#184

Earlier quoted context omitted.

Terrible idea. The dev team manager is focused on growing new features in the next release. QA is focused on the excellent of the current release. Subordinating quality to new releases is the result. In a similar situation, devops supposedly addressed similar tensions of dev and ops.

I work at a startup so we have a small team. But for us it goes: 1. Develop some feature (me and the other engineer are full stack) 2. Send to other engineer for code review 3. Deploy to a staging site, with test data. Send to product girl to QA If she finds a bug (or realizes her design doesn’t look as right in practice as she envisioned) she sends back with notes, we implement or fix them, and then start back at 1-…

QA is different for every type of engineering organization.

It shouldn't be automatically thrown around or diffused as something tertiary that can be subordinate wherever it lands. That works in a 3 person startup, but not if you're building an aircraft carrier or an iPhone.

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

#185

Earlier quoted context omitted.

I work at a startup so we have a small team. But for us it goes: 1. Develop some feature (me and the other engineer are full stack) 2. Send to other engineer for code review 3. Deploy to a staging site, with test data. Send to product girl to QA If she finds a bug (or realizes her design doesn’t look as right in practice as she envisioned) she sends back with notes, we implement or fix them, and then start back at 1-…

QA is different for every type of engineering organization. It shouldn't be automatically thrown around or diffused as something tertiary that can be subordinate wherever it lands. That works in a 3 person startup, but not if you're building an aircraft carrier or an iPhone.

I agree that was kind of my point. It’s different everywhere so saying it only should exist to test stable is untrue.

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

#186
post #155

Earlier quoted context omitted.

> folks that think about and manage change to the product, namely product folks It's weird to me that the software engineers building the product are not viewed as "product folk". The people designing the architecture for and building the actual product aren't managing the changes to it or concerned about it? The people who have to address any defects in it aren't concerned about their processes as they pertain to qu…

Nowhere do we say that the entire product organization - devs, designers, PMs - should not care about quality. It's a question of ownership and focus.

Engineering needs to own and focus on quality. It's construction that determines quality. It's construction that addresses defects. It's engineering that owns construction.

If engineers aren't owning and focused on quality the business either doesn't really believe there are quality issues or there is a huge alignment issue.

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

#187
post #90

Earlier quoted context omitted.

That's false. QA can also be concerned about growing new features in the next release. We have embedded QA's on our teams. They QA new features, as well as help to triage current bugs.

Anecdotal. Embedded QA doesn't scale for projects where the teams are larger, or the concerns and complexity are significant. https://qualitysystemsanalyst.com/2017/10/06/independence-th...

Anecdotal too, but I've been QA lead on a team for a 9 figure project in aviation, concerns and complexity very significant, and it was very successful.

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

#188

Earlier quoted context omitted.

QA here, disagree. In this situation QA is focused on the quality of the new features, so they're already excellent when they go out into the current release.

What about ongoing quality and quality regressions of existing functionality? What happens when the dev mgr asks QA to rush testing? Been There, Done That, Bought The T-Shirt, Said "No," and Tendered a Resignation

do that too. Tests for new features also include regression testing, as does integration tests and automation CI/CD tests.

In our working agile environments, you know the team's velocity. Managers know the team's velocity. Points per story include QA work. If they want something faster in this sprint, something else has to be taken out. Firm but fair, and it works very well.

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

#189

Asking developers to own QA is broken because developers are naturally biased towards the happy path. If you want to build a bar, you need someone to order -1 beers[1]. Handing off QA to an external team is broken because those people don't have the necessary experience with the product, nor can they quickly and easily engage with development to get to the heart of a problem (and a fix.) Having QA rely exclusively on…

> Asking developers to own QA is broken because developers are naturally biased towards the happy path

This overlooks that "no customer calls with product issues that dev needs to get fixed asap on a Saturday evening" is part of the happy path to optimize for. If those things happen, the dev has deviated from the happy path, including the embarrassment in front of fellow devs "but that's really a case we should have tested". This is another of those details the article is lacking.

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

#190

Earlier quoted context omitted.

What evidence do you have for this?

I'd say google W. Edwards Deming to start.

Can you help me find where he examines "when people test what they are responsible for"?
Post reply on HN