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

QA? We don't need no stinking QA

thecodist.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: QA? We don't need no stinking QA

#51

Post by MartinCron »

pavel_lishin wrote: post #32
MartinCron wrote: post #27

Earlier quoted context omitted.

It means that I (the dev) will have no one at my back. Everyone should always code and test their code like that, right?

Eh, there's a difference between testing code you just wrote, and actual QA. I know my code, and I'll be testing for specific things, and I'll know what not to do. Our QA guy has no idea what I just did - so he's likely to uncover things I didn't think to check for.

Eh, there's a difference between testing code you just wrote, and actual QA

That's what I'm challenging. I think the whole "developers can't test their own code" business is a myth.

There really is something to the idea of the "curse of knowledge" and there really is a different mindset when you're trying to make something work and trying to make something break, but isn't switching between contexts and mindsets and levels of abstraction a core part of being a developer?

Developers can get lazy and don't bother testing their own code. Developers can get sloppy and don't bother thinking through corner cases. Developers can be short-sighted and write poorly-encapsulated code that is brittle and creates side-effects.

Re: QA? We don't need no stinking QA

#53

Post by MartinCron »

DanielRibeiro wrote: post #31

For startups you usually don't have enough people to have QA team. Therefore you have to take a more lean approach: Build Quality In. On the other hand, when you are building your MVP, progress is not built features, but validated learning. So QA tasks takes more of an approach of building measuring tools (which have to be done by the people building the MVP). Even on a later stage startup, QA takes a whole new role,…

Build Quality In isn't just something you do when you don't have the luxury of a QA department. It's something that you can do to prevent having to have a distinct QA department at all.

Re: QA? We don't need no stinking QA

#54

Post by MartinCron »

mrgoldenbrown wrote: post #11

I would have liked to see a more realistic discussion of when QA helps the bottom line and when it doesn't. Plenty of software is sold and tolerated by users despite having bugs. If Microsoft waited until the bug count in Windows was 0, they would never ship, and would go out of business. In other words, this blog post is telling us that the correct amount of QA is higher than "no QA", but it is not helping us determ…

A more realistic discussion takes into account the fact that a lot of software isn't anything like Windows. You don't get a single shot to release to manufacturing to press images onto media to shove into boxes to put onto store shelves.

So much of our thinking about roles and teams and efforts and project management is still in last century's approach to monolithic one-shot releases.

Re: QA? We don't need no stinking QA

#55

Post by absconditus »

imperialWicket wrote: post #45
absconditus wrote: post #19

I have been working in QA for a few years now and have made several observations. * The people who are good at QA usually have the skills to work as a developer. QA is generally not as desirable as development to a young developer, so why do it? * Many QA people are almost completely useless and exist just to generate paperwork so that the company can cover its ass. Warning signs for bad QA people seem to be certific…

It is unfortunate how true these statements are. I followed to standard path of starting in QA and moving to development. While I do not think it's a bad path of itself, I think it is unfortunate that a lot of really great QA analysts hang up their QA title in order to develop. I think one of the core problems is that QA is treated as entry level; which is odd, because as you point out, most devs are practically inca…

I believe that Google treats their "QA" people well. Of course their "QA" people are probably better developers than most developers at other companies.

(I put QA in quotes because their testing structure does not seem to be at all similar to most companies.)

Re: QA? We don't need no stinking QA

#56

Post by pavel_lishin »

MartinCron wrote: post #51
pavel_lishin wrote: post #32

Earlier quoted context omitted.

Eh, there's a difference between testing code you just wrote, and actual QA. I know my code, and I'll be testing for specific things, and I'll know what not to do. Our QA guy has no idea what I just did - so he's likely to uncover things I didn't think to check for.

Eh, there's a difference between testing code you just wrote, and actual QA That's what I'm challenging. I think the whole "developers can't test their own code" business is a myth. There really is something to the idea of the "curse of knowledge" and there really is a different mindset when you're trying to make something work and trying to make something break, but isn't switching between contexts and mindsets and…

> isn't switching between contexts and mindsets and levels of abstraction a core part of being a developer?

Sure, but you can only do that so rapidly. Why not just let me stay in the flow, and test the changes I expect, and pump out more code and bugfixes, and let the QA look at things I might not catch?

I'd rather do a quick test of my code and send it off to QA than spend two hours second-guessing myself as to whether I've tested everything in-depth enough.

Re: QA? We don't need no stinking QA

#57

Post by DanielRibeiro »

MartinCron wrote: post #53
DanielRibeiro wrote: post #31

For startups you usually don't have enough people to have QA team. Therefore you have to take a more lean approach: Build Quality In. On the other hand, when you are building your MVP, progress is not built features, but validated learning. So QA tasks takes more of an approach of building measuring tools (which have to be done by the people building the MVP). Even on a later stage startup, QA takes a whole new role,…

Build Quality In isn't just something you do when you don't have the luxury of a QA department. It's something that you can do to prevent having to have a distinct QA department at all.

Agree. Having a seperate department can be helpful for large organizations, so that you can have one team supporting many products. However, if you prefer to hire generalists[1][2], then you can do away with it. Which is also a great away to mitigate Conway's Law[3]

[1] http://jessicamah.com/the-ceos-job-part-2

[2] http://blog.eladgil.com/2010/12/5-myths-to-building-awesome-...

[3] http://en.wikipedia.org/wiki/Conway%27s_Law

Re: QA? We don't need no stinking QA

#58

Post by MartinCron »

pavel_lishin wrote: post #56
MartinCron wrote: post #51

Earlier quoted context omitted.

Eh, there's a difference between testing code you just wrote, and actual QA That's what I'm challenging. I think the whole "developers can't test their own code" business is a myth. There really is something to the idea of the "curse of knowledge" and there really is a different mindset when you're trying to make something work and trying to make something break, but isn't switching between contexts and mindsets and…

> isn't switching between contexts and mindsets and levels of abstraction a core part of being a developer? Sure, but you can only do that so rapidly. Why not just let me stay in the flow, and test the changes I expect, and pump out more code and bugfixes, and let the QA look at things I might not catch? I'd rather do a quick test of my code and send it off to QA than spend two hours second-guessing myself as to whet…

I think the throughput you get of pumping out more code (without really testing it) may be a micro-optimization.

I only bring this up because I once worked at a place with a really strong, borderline omniscient, QA Department and I felt myself getting sloppy and checking in things that I knew were probably wrong, but I knew that QA would find it and tell me how it was wrong. It appeared to be optimal for me as a developer, I got lots of code pumped out, but as far as the whole organization or product, it was a net loss.

Subsequently, I've worked on a few projects with no dedicated QA people, and my overall "getting good software shipped to users in the real world" effectiveness hasn't decreased.

Re: QA? We don't need no stinking QA

#59

Post by D-Coder »

bitmage wrote: post #42

Ugh. I worked QA years ago and swore to never do it again. Management hates you because you're telling them the product is not ready to ship. Developers hate you because you're pointing out their errors. No one has your back, and everyone wants to blame you. The company had literally fired the whole testing department previously for saying the product wasn't ready. With those annoying testers out of the way, out the…

I'm a developer and I love my QA department. It's unprofessional and embarrassing to ship a bug. QA prevents that (not always but frequently). When they find a bug in my code I say "Thank you!"

Re: QA? We don't need no stinking QA

#60

Post by wnight »

Shenglong wrote: post #28

Question: When you're doing QA on a product, do you worry about border cases? I found quite a few bugs related to time syncing and inadequate safeguards in a project I worked on - but they were difficult to reproduce without a macro. I'm still not sure whether people were happy or angry with me, for reporting all those bugs.

The good devs would be happy because those rare bugs you found could take them months (literally) to track down from user reports.

One company I worked at had both buffer overflow and timing problems and didn't dedicate the time to fixing either properly so easily half the bugs we found were the same giant ones (and thus always ignored even if crash-level). This slowed us incredibly as you can imagine. The timing bugs could cause really anything and the buffer overflows prevented us from stuffing commands properly which kept us from ever reliably reproducing the timing bugs.

Eventually one of the lead devs fought through the backlog and implemented scripting into the product itself and we were able to get a much better handle on things through more intensive and repeatable testing.

These days I expect the developer has written specs for their code at the unit level. How else do they know what they claim to be delivering? So the job of QA (or, as I'd prefer - just another developer playing QA) focuses more on testing the stuff the weird stuff, edge cases, etc.

Automate everything. Writing a system to parse screenshots to decide if your windows drew properly is cheaper, and sooner than you think, than manual testing. Especially if you count the cost of bugs you miss through inattention.

Post reply on HN