5 ms·

Yet another team that seems to think the programmers should QA their own code. I learned that lesson 30 years ago, good QA people are worth their weight in gold

Yet another team that seems to think the programmers should QA their own code. I learned that lesson 30 years ago, good QA people are worth their weight in gold. QA is a set of skills separate from the skills that programmers have; expecting a programmer to be good at both is asking for trouble. I never would hire an architect to wield a hammer and saw. You can't be good at everything.

edawerd 11y ago
ZenPayroll CTO here. At least for the stage that we're currently in, having high unit test coverage, high-level integration tests, a strong code-review process, and individual accountability for bugs has worked very well for us so far. So well, in fact, that we don't feel we need a dedicated QA team. It's also worth mentioning that when coming up with our values/principles, we started with the understanding they can and probably will change over time, especially as we grow. So while we don't have dedicated QA team today, we'll keep an open mind do whatever works best for us in the future.
fweespeech 11y ago
> Yet another team that seems to think the programmers should QA their own code. That phrasing is a bit different than what I think they meant. Programmers familiar with the problem domain should QA the code of other programmers is how I took it. I've never seen the value in "pure" QA people largely because you need to be a developer to be an effective QA person [writing automated, repeatable tests] at which point you are just looking to use the developers that are more meticulous than the others to write those tests. They are still ultimately software developers / programmers / whatever. Its just the problem domain they spend half their time on is QA instead of Ops or whatever else. Maybe I'm just used to being part of an IT department embedded in a larger company where we tend to mix a couple things in a single position. :P
patmcguire 11y ago
I used to ask in interviews if they had a QA team, because it was on the Joel on Software list http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html I stopped asking because the answers were always some variant on "that encourages programmers to be lazy, because they know QA will be there to catch it" and because it seemed like lot of companies treated that question as a culture fit red flag. The responses were pretty hostile, like I'd asked why none of the engineers were wearing suits. I have no idea whether it's a good idea, but the current tech culture seems pretty opposed to it.
- ryan-allen 11y ago
  I once ran a small team with a specific QA guy, he was awesome. He had more technical knowledge of the product than the remainder of the team (3 other programmers) combined. As a new manager, he was who I leaned on the most to find out things, and who saved my ass on a number of occasions. He deserved more respect than he got.
- omouse 11y ago
  If the expectations around QA aren't clear and you have a bad manager they'll actually force you to rely on QA since QA should be vetting things before they get to the customer. I've been told by one manager that I should not waste time writing unit tests and that I should rely on the QA person to test. If the QA person has skills along the lines of a software test engineer (like at Google and other places) and can actually create tools and automate things and write some unit tests or acceptance tests, then they're half-a-programmer and I'll be happy to rely on them and share the work. Otherwise I assume the QA is there just to bow to management/marketing and give the OK for deploys.
- Lawtonfogle 11y ago
  Because having a QA team allows for a very nasty blame game. It larger organizations it can get pretty nasty. The problem only grows as greater amounts of bureaucracy separates the two sides.
yetanotherjosh 11y ago
I've always argued that a QA engineer's job is to augment the skill set of the feature engineers to help them in writing good tests and automation suites that ensure the user requirements are actually met, as well as to build and maintain the CI server, QA and staging environments, and so on. Basically QA as a support for the engineers, not in contrast/conflict with engineers. Note that I said "QA engineer" there; manual QA is a different role entirely that should occur outside of engineering frameworks, whose goal is to really evaluate UX and who really answers to and works with product and design teams, not engineering. /2c
sdenton4 11y ago
The tests+code review make sure people are doing basic due diligence on the code they're contributing. Meanwhile, SRE roles are defined to take up a bunch of the brass tacks of making software storm-worthy... Are there aspects of good QA that you feel aren't hit by this combination? (Genuinely curious.)

edawerd 11y ago

ZenPayroll CTO here. At least for the stage that we're currently in, having high unit test coverage, high-level integration tests, a strong code-review process, and individual accountability for bugs has worked very well for us so far. So well, in fact, that we don't feel we need a dedicated QA team. It's also worth mentioning that when coming up with our values/principles, we started with the understanding they can and probably will change over time, especially as we grow. So while we don't have dedicated QA team today, we'll keep an open mind do whatever works best for us in the future.

fweespeech 11y ago

> Yet another team that seems to think the programmers should QA their own code. That phrasing is a bit different than what I think they meant. Programmers familiar with the problem domain should QA the code of other programmers is how I took it. I've never seen the value in "pure" QA people largely because you need to be a developer to be an effective QA person [writing automated, repeatable tests] at which point you are just looking to use the developers that are more meticulous than the others to write those tests. They are still ultimately software developers / programmers / whatever. Its just the problem domain they spend half their time on is QA instead of Ops or whatever else. Maybe I'm just used to being part of an IT department embedded in a larger company where we tend to mix a couple things in a single position. :P

patmcguire 11y ago

I used to ask in interviews if they had a QA team, because it was on the Joel on Software list http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html I stopped asking because the answers were always some variant on "that encourages programmers to be lazy, because they know QA will be there to catch it" and because it seemed like lot of companies treated that question as a culture fit red flag. The responses were pretty hostile, like I'd asked why none of the engineers were wearing suits. I have no idea whether it's a good idea, but the current tech culture seems pretty opposed to it.

ryan-allen 11y ago
I once ran a small team with a specific QA guy, he was awesome. He had more technical knowledge of the product than the remainder of the team (3 other programmers) combined. As a new manager, he was who I leaned on the most to find out things, and who saved my ass on a number of occasions. He deserved more respect than he got.
omouse 11y ago
If the expectations around QA aren't clear and you have a bad manager they'll actually force you to rely on QA since QA should be vetting things before they get to the customer. I've been told by one manager that I should not waste time writing unit tests and that I should rely on the QA person to test. If the QA person has skills along the lines of a software test engineer (like at Google and other places) and can actually create tools and automate things and write some unit tests or acceptance tests, then they're half-a-programmer and I'll be happy to rely on them and share the work. Otherwise I assume the QA is there just to bow to management/marketing and give the OK for deploys.
Lawtonfogle 11y ago
Because having a QA team allows for a very nasty blame game. It larger organizations it can get pretty nasty. The problem only grows as greater amounts of bureaucracy separates the two sides.

yetanotherjosh 11y ago

I've always argued that a QA engineer's job is to augment the skill set of the feature engineers to help them in writing good tests and automation suites that ensure the user requirements are actually met, as well as to build and maintain the CI server, QA and staging environments, and so on. Basically QA as a support for the engineers, not in contrast/conflict with engineers. Note that I said "QA engineer" there; manual QA is a different role entirely that should occur outside of engineering frameworks, whose goal is to really evaluate UX and who really answers to and works with product and design teams, not engineering. /2c

sdenton4 11y ago

The tests+code review make sure people are doing basic due diligence on the code they're contributing. Meanwhile, SRE roles are defined to take up a bunch of the brass tacks of making software storm-worthy... Are there aspects of good QA that you feel aren't hit by this combination? (Genuinely curious.)