[kabdib]

On the other hand, I've seen QA groups who do no QA at all. Instead, they do frameworks.

"We need a test framework" are terrifying words to me. It means that I (the dev) will have no one at my back. It means that tests will be written by junior QA engineers (the senior ones are off writing and maintaining the framework, right?). It means that I am responsible for my own tests, because /no one/ else besides the customer will be testing my code.

That's generally all right; I think I do a good job. But not everyone does; some devs think they can toss code over the fence to a group that will tell them if it worked or not.

Everyone is responsible for quality; Devs must do unit tests, but they have blind spots and that is what QA is for, namely higher-level assurance that things are working as intended.

[hello_moto]

Sounds like Microsoft with their SDETs. Most of them build crazily complicated frameworks because that might push them to SDE level, you know, the rockstar level.

If they failed, these SDETs will move to PM role.

I'm not saying all SDETs are like this, but join MS and you'll see quite a few of them.

Google probably have some too but lately I noticed that their approaches are different: instead of building a large automation frameworks, they build tools to help developers be more productive and produce less bugs even before the automation testing happens.

[MartinCron]

It means that I (the dev) will have no one at my back.

Everyone should always code and test their code like that, right?

[pavel_lishin]

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.

[MartinCron]

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.

[pavel_lishin]

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

[MartinCron]

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.

[silverbax88]

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.

[DanBC]

Like Boeing engineers sign off their own work when they're building aircraft. The test problem is well known in electronics manufacturing. When ISO900x and TQM etc is done right test & inspection are useful.

[aidenn0]

There is a difference between QA and testing and that needs to be well established. Devs should develop and QA should QA.