Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you have a dedicated QA team?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Ask HN: Do you have a dedicated QA team?

#21

Post by swiftcoder »

I've always had dedicated QA teams when working with physical devices (android smartphones and VR headsets, specifically). I think a dedicated QA team is absolutely non-negotiable for hardware development, because there is no test harness that can accurately simulate the range of stupid shit that happens with hardware:

"smartphone doesn't boot reliably when the ambient temperature is below 40 degrees fahrenheit" (temperature lowers the battery voltage + high power usage during startup = voltage drops below FCC-mandated minimums for the antennas -> automated SoC shutdown)

"bluetooth controllers won't pair reliably in building 17" (too much interference to pair if there are more than ~100 other bluetooth devices nearby)

The combinatorial explosion of external factors in this kind of bug is insane - you just won't have a good time without dedicated folks whose focus is chasing these down (and I'll take a good QA over a good engineer for this sort of investigation, any day).

Re: Ask HN: Do you have a dedicated QA team?

#22

Post by Veuxdo »

lalaithion wrote: post #13

We don't have a QA team; we have an internal team that uses our product to do their work. It's part QA, part product development, part marketing; they help us prioritize feature work, they write blog posts about the cool stuff they can do with our product, and when bugs surface, they find them, because it's all part of their workflow. This doesn't work for all companies; if you're building a system for children to le…

This sounds like a great setup. Can I ask what kind of product it is?

Re: Ask HN: Do you have a dedicated QA team?

#23

Post by candiddevmike »

yodon wrote: post #14

Having been through the decision process in the past for whether to go when centralized QA, dedicated QA on teams, or automated testing as an engineering responsibility, I came away with the personal opinion that the quality of automated test frameworks has improved so drastically in the past five years or so that we really are in a different place than we were when concept of dedicated QA teams was invented long ago…

Automated tests (at least when it comes to web) are unlikely to catch graphical and UX issues in my experience, even when you're doing screenshot comparisions--things get missed. I've also had manual QA discover unrelated UX bugs too.

Re: Ask HN: Do you have a dedicated QA team?

#24

Post by justin_oaks »

QA teams primary benefit shouldn't be running automated tests that the developers could do. It should be to do exploratory testing and trying to break things.

There should be a adversarial, yet respectful, relationship between dev and QA where dev tries to get their software released and QA is finding reasons why it shouldn't be released.

If there's only developers who test their own code then they're not incentivized for finding the ways their code breaks. They'll downplay the faults or even be blind to them because they're too close to the implementation and aren't "thinking like a user".

It seems odd to me when those in charge ignore the problems of disbanding QA. But I assume it's because the management may not be incentivized to promote quality software. Instead the incentives are to crank out features.

That said, maybe the market for the software doesn't punish the software makers for having buggy software. In such a case, ignoring QA work is a rational decision.

Re: Ask HN: Do you have a dedicated QA team?

#25

Post by jasonlotito »

We have a dedicated QA team. They work side-by-side with devs, and we rely on them. They are absolute lifesavers and let us focus on the dev side of things. Their knowledge of the products, all the various ways it interacts, and their dedication to testing are wonderful. The quality of the product would suffer if they didn't exist, hands down.

Re: Ask HN: Do you have a dedicated QA team?

#26

Post by gvpmahesh »

We do have QA team(2 members, 30+ engineers) but they are not the gate keepers for releases.

Developers write all sorts of tests(TDD + pair programming helps), and when we need an extra pair of eyes, we ask the product team to have a look at it.

But that's about it. QA's are involved more in the creative side of things post releases or have an independent path to see where the things could go wrong, more like doing monkey testing.

Re: Ask HN: Do you have a dedicated QA team?

#29

Post by ivan_gammel »

thebean11 wrote: post #15
sanitythrowaway wrote: post #9

Earlier quoted context omitted.

The best QA setup I've seen was a parallel one. Devs and QA were given the same requirements doc, and independently worked out their assumptions and implementation. QA was often ready before dev work was done so sometimes devs could even run their tests locally to see if they pass. It was really remarkable. It's frustrating its not so clean usually.

That seems like it would only work on very specific types of software teams. I've never been given a requirements doc that prescribed exact interfaces or anything even close.

True, but documented test cases can help too, because developers can use them along with requirements for better understanding of the problem.

Re: Ask HN: Do you have a dedicated QA team?

#30

Post by runlevel1 »

ineptech wrote: post #8

Devs can add automation tests to a suite just fine. What you lose when you lose dedicated QA is: who improves the automation suite? Who checks out new testing tools and POCs them? Who reads QA blogs and goes to QA conferences and generally considers it their profession to find ways to test more effectively?

This is my take as well.

I've worked with various types of QA teams over the years (all in SaaS). Based on my experience, from MOST effective to LEAST effective:

1. QA team works on test harnesses, automation, and works alongside developers to improve how we do testing. This was by far the most effective.

2. No QA team. Developers own every aspect of quality. This worked, but was not as effective as #1.

3. All releases are thrown over the wall to QA who stamp them and do the deploys. This shifted the responsibility for quality to people who weren't as familiar with the code and weren't equipped to fix it. Outages abound. It also slowed releases to a crawl.

4. QAs are non-technical. They mostly write and manage test cases. It's up to the developers to implement tests, but some tests are done manually by QA. I never saw any benefits from tracking test cases outside of the code that validates them. Properly prioritized tickets were fine for defect follow-up. Manual testing might be ok if you're a new startup, but it quickly becomes untenable as you grow.

Post reply on HN