Hacker News Reader

Comment by lt | Hacker News Reader

Not that the indentation complaints are valid, but the fix should definitely go through QA while the users continue to suffer. While I'm sure it works on the developer machine, it is much better to have a program that takes a long time and works right than for it to give incorrect results to users, or make a different part of the application stop working.

If the feature was really critical and important, QA should find a way to expedite the verification, but it should never be skipped in order to ship the fix faster.

View on HN

I've seen lots of software that's gone through QA but didn't work. Ever use Microsoft Windows?

QA is important, but determining how many spaces a line of code is indented is not QA. That is a code review, which is important, but not critical. There should be automated acceptance tests, so that new releases can be shipped immediately. (It's also worth noting that stuff like indenting, naming conventions, etc. can be automatically checked at checkin time. See Perl::Critic, for example.)

If there is some feature or corner case that the users test but isn't in the acceptance test suite... well... yeah, the software is going to be unreliable. So don't do that. Write a test.

(I worked somewhere with a QA department once. They didn't like it when the programmers wrote tests, because they felt their job would be threatened. It was true, so we were asked to only write unit tests; no "integration" or "acceptance" tests. I quit a few weeks later.)

I did QA for years (8+) and would love to have developers write a test. Specifically NOT unit tests, but the harder more interesting one. I think it happened once. Or, was it twice?

You mean like functional tests, end-to-end integration tests, and view tests?

No developer should limit themselves to unit tests.

Bullshit, its attitudes like this that lead to crap software. Developers should work with QA to find the bugs, they're not "QA's bugs" they're OUR Bugs, we're a team, right? When you change a component you should also be able to write a simple manual test to prove the functionality works you should also perform this test yourself.

As an optional if the QA people are good then describe what else might be effected by the code (if you edited a generic component). Good QA people will run your test, work out their own variations and also check other areas.

I'm really unsure of where your attitude here is coming from.

At ThoughtWorks we work with QAs constantly. It's a great relationship. There's no such thing as "QA's bugs".

Like all "lost job" situations, it is a myth. If you write good Integration tests, QA's job should be to find gaps in them, test the really weird edge cases only a human can come up with and perhaps provide usability feedback.

Any decision made that promotes inefficiencies to "save jobs" puts the entire company in danger.

And indeed, that company was absorbed, the management fired, and the application rewritten.

QA is basically your testing framework. It's there to do all the tests to make sure the software actually does what you say it does.

No developer is good at testing their own code because deep down no developer wants to break the code they just lovingly crafted.

As amusing as that statement is (and I think you meant it jokingly), I definitely have to disagree. There's just too many different developer styles to say No developer. Personally I like to ship quality code and am pretty anal about it's quality as well as it's interface, so you can bet I refactor my code a lot... and I mean a lot.

(In fact I just refactored this comment to fix a spelling mistake... but I published it without writing any automated tests, or running it by QA... somehow I don't think many people noticed)

I've always been treated well by QA. I'm sure there are problem QA departments out there but I doubt they are the rule. It's amazing to me that the parent got down moded for supporting the task of QA.

QA is awesome.

I think people are responding to the suggestion that in general developers will subconsciously protect their ego by willfully ignoring flaws in their own software. That is just tremendously offensive to any real hacker, and if it were true the world of software would be a pale shadow of what it is today.

I don't think it's a slam on developers - I've hit and played outfield, and I know what each side feels like. It's not that developers wants to ship bad software, but haven't you ever avoided running a test because you're afraid of opening a can of worms? QA wants to open that can. There's a perverse glee in seeing all the worms get out.

When a new bug is found (a good one, not BS indentation) then QA has a justifiable joy in finding it before it got to the customer. The developer may also be devoted to quality, but doesn't your heart sink a little when you see a new bug? Overall you both want to ship good product, but your minute-to-minute motivations are just different.

No, QA is your double-check, you shouldn't rely on them as we're all just humans and we all can make mistakes. You should still test the code yourself and think of ways to break it. Although I will agree that developers are blind to some bugs (which is why you need the double-check).

That's only true some times. Unless the data is mission critical, or you introduce a really major bug, the company in question could be losing customer's and / or significant revenue due to the slow down of the application.

I'm not saying you're wrong, I'm just saying there's no hard rule on this. I've had to push code many many times without any outside testing and while occasionally it's been detrimental (but fixed quick, because I didn't have to go through QA), the large majority of times has been beneficial.

A large and formal QA process can kill a product / project just a quickly as cowboy code.

Reply on news.ycombinator.com