We do have a dedicated QA team and it's absolutely essential because developers (like me) aren't necessarily domain experts.
Ask HN: Do you have a dedicated QA team?
11–20 of 84 posts
Re: Ask HN: Do you have a dedicated QA team?
#12The QA team brings something significant that developers (myself) will never have: their machines closely represent the customers machines. They use a well-polished methodology to push the models we ship to their limits and provide relatively detailed information about how to reproduce failures.
I can't count the number of times I've tested something 5 times, convinced myself that the code handled tons of error cases, shipped it, and in 10 minutes a customer types "five" into a field expecting an integer which causes the next step to use "0" for processing.
Re: Ask HN: Do you have a dedicated QA team?
#13We 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 learn how to type, you can't really hire a bunch of children to learn how to type... but I think for most companies, this can and does work.
Re: Ask HN: Do you have a dedicated QA team?
#14Having 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. Large scale software engineering is a human coordination problem (see Conway's Law and the Mythical Man Month), and the time required for engineers to write tests after already understanding the requirements is small compared to the time required for the organization to have someone else try to separately understand the same information and separately write the test. That didn't use to be the case, but today it is. I get not wanting to take time to write tests, just as I get not wanting to take time to document your code, but that's not a good enough reason for introducing the inefficiencies of having someone else try to do something that is best described as your own job (again, the economics used to be different because writing tests used to be slow and inefficient, but that is changing/has changed).
I will say however that I think you do generally still need a team (or individual at smaller shops) dedicated to tooling for automated testing to make the process of writing tests efficient for all those who are writing tests.
Re: Ask HN: Do you have a dedicated QA team?
#15My feel is that this pattern leads to quantitatively better software that is qualitatively worse. There are two reasons for this: 1. QA teams come up with new ways to break software in the way humans use it. Automated tests etc confirm the software works as designed. 2. Because the org making this choice isn't stupid, they measure bug frequency and impact and find that "only X users have Y impact where Y is ranked as…
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.
Re: Ask HN: Do you have a dedicated QA team?
#16Having 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…
The problem with this is that a person who makes a mistake when doing something is much more likely than someone else to make a mistake when evaluating that same piece of work.
Re: Ask HN: Do you have a dedicated QA team?
#17I always setup a dedicated QA team that has right of veto for releases. Developers indeed can do some testing, but quality assurance is more than that. It starts at the problem definition stage, when QA engineers ensure there’s no misunderstanding of the requirements, they make sense and they answer all important questions. It ends long after release, because production support is also part of QA. QA engineers do their part of testing, just like developers do, but they also coordinate delivery and support from quality perspective. Their feedback is often valuable to product managers and designers, they can help a lot your customer support team.
Re: Ask HN: Do you have a dedicated QA team?
#18We have a QA team of 4 that supports x4 as many engineers.
If they weren’t there - engineers would spend at least 1/4th of their time performing QA duties with likely worse results and at significantly higher cost to the company, since their compensation is higher.
So it makes sense to do that only as a cost saving measure in hard times - you are picking losing which employees will be less detrimental in the long term, even if you expect that those that remain will be less productive.
Re: Ask HN: Do you have a dedicated QA team?
#19I don't at my current job, but my last job did. The benefit of having them is that they maintain domain knowledge about how something works, will ask pertinent questions about new functionality, and are able to dedicate a lot of time to trying to break a component. The drawback of having them is that if they are mismanaged or get backed up, it can take a long time before a feature even gets looked at (my last job was so bad with this that I would often get asked about features that I submitted 4-6 weeks later).
The good thing about not having a QA team is that QA becomes a much more active part of the process where something must be tested by the developers before it's completed. You also don't have a single bottleneck if the QA team is overwhelmed. The drawbacks are that developers aren't always very thorough and that their testing time takes away from their development time.
Re: Ask HN: Do you have a dedicated QA team?
#20Having 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…
The problem with this is that a person who makes a mistake when doing something is much more likely than someone else to make a mistake when evaluating that same piece of work.
Exactly. The problem isn't "writing tests", is writing test cases.