Hacker News new | ask | show | jobs
by pavel_lishin 5378 days ago
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.
2 comments

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.

> 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.

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.

Yeah, that's probably the first thing you learn when you start writing code in the corporate world - no matter how thoroughly you think you've tested your app, QA will break it almost immediately.

Very humbling.