Hacker News Reader

Comment by MattGaiser | Hacker News Reader

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 narrowing down exactly where they occur, which is not trivial.

For all the faults in that organization (including letting our test runner be broken for months), we didn’t put out a lot of bugs and we found all manner of strange edge cases very quickly.

View on HN

The key part in that is communication. That’s makes all the difference whether it be with BA’s, QA’s, or the end user. Speeds up the development cycle and greatly reduces the number of bugs.

The best experience I had was on a team that had essentially 2 BA’s and 7 devs. There was constant communication to clarify actual requirements, devs would build automated tests off them, BA’s would test against the requirements and then a business user would do a final look over. All in all features were able to be released usually within a day and there would be days we’d get out 3 or 4 releases. Only in one case did a major bug get released to production and the root cause of that was poorly worded regulations which had a clarifying errata come out at the 11th hour.

For as many faults as that company had that caused me to move on I’ve yet to run across a team that functioned as well as that one did.

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.

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.

I’ve experienced both, were the dev team also had to do QA, and a dev team with QA people.

I personally hated writing automated tests, but it did give me a much deeper understanding of the product. Especially when writing tests for features I wasn’t working on.

That said, having a dedicated QA person within the team is far more effective. The dev team can build features, while our QA person works with the business to come up with test cases and test data.

We had that in one of my assignments. It kinda works, but at the same time, they were a gatekeeper, a barrier, and usually a release was delayed for a day while they tested out their new testing approach and went through their excel sheets of things to test for.

I think the ideal team setup is one you allude to: a cross-functional team with experts from each domain collaborating together. My intent was not to say that can't happen - but that it typically doesn't, because of specialization and organizational politics. The vast majority of software teams have a siloed QA team. Why? That's for another thread :)

Makes a lot of sense to me. The best and highest quality software I've ever worked on (people could die if it failed) had the devs doing testing and writing automated tests, with an intermingled QA team doing further testing, and often jumping in on dev.

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

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.

I agree in theory and there are certainly teams where this could happen, but what happened on this team was that the bugs were found so quickly than the fixes were also quick (I would always get a bug report the same day and often within the hour), making shipping stuff with few bugs relatively painless.

Was there pressure to keep releasing? Yes. But with the rapid feedback, it never became too onerous to get them done anyway.

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.

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

I think QA is different for every org but I believe there should be steps. At bigger orgs there should be QA for every feature developed (so each team should have a QA person) and then an integration QA of the current beta.

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.

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

Each team should have some QA resources. Server can be tested independent of client, etc. Then the QA staff work together to ensure appropriate systems integration tests.

Siloed QA team runs the risk of becoming a bottleneck as work from disparate teams comes through.

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.

Reply on news.ycombinator.com