Can developers QA their own code?

Been really busy with everything and can't believe that it's been like two years since my last post.

So here's the thing, a lot of managers wonder should they have developers write more tests for their code or should they invest more in hiring QA's? In my experience I've worked in environments where developers write absolutely no tests of any kind (unit, user behavioral tests) and on the opposite side of the spectrum where developers write tons of tests whether it's unit tests or following TTD model and writing tests before coding even begins.

Does it help overall quality of the code? Does it save QA's time? Is it worth investing in?
Dev testing is defiantly worth implementing into your SDLC but should not over heavily be relied on. I do believe having unit tests is a good thing since a lot of tests with different state transitions could be tested much quicker by devs as apposed to manually generating users events by a manual tester performing regression testing. It defiantly saves QA's time by having dev do a basic end to end test on a client that a customer would be using. I can't remember how many times I've seen a feature be so badly broken that I would have to log bunch of bugs, wait for them to be fixed then spend time verifying. In these cases it should not even made to QA. All of this takes longer to ship product to end user and usually add to dev time and easts through QA's. So why most developers are not so effective testing their own product? Here are my takes on the subject.

Emotional Connection
1. When a developer writes code to implement a feature there is some kind of connection between with their code since it's their baby project that they just created. Writing code also represents the logical decisions one makes so it's hard to be objective to those decisions.


Having the Right Mindset
2. To be an effective QA you need to have the right mindset which is to acknowledge that there are ton of bugs in an application they are just hiding from you and it's your job to find them so the end user would never see them. If you have a positive mindset toward code that it's perfectly written and completely bug free you will find much fewer bugs as they won't jump out at your and you will easily miss them. I think this is the biggest downfall of a developer testing their own code they don't expect it to have much bugs. The minds set usually that it will work otherwise if you don't think it will it should not even go to QA.

QA's Intuition

3. When you go through testing an application seasoned QA's develop what girls call "intuition" or what guys call "gut feeling" :). I almost always can spend 10 minutes doing Ad-hoc testing and I would have a good sense where there are weaker area's in the app and the ones that most likely to fail. At times it almost seems like you can smell bugs in certain area of the application and I actually had developers tell me that in the past. "Leo you can just smell bugs a mile away" I don't know if this just comes from experience or what. 

What does not fit in?

4. Seasoned QA's can almost always see if something stands out or does not belong in an app at all almost at all. A lot of devs focus on the scope of the project and on bigger picture and miss a lot of little details. You have to be ultra sensitive to detail and question if something makes sense or not like all the time. This also takes effort question the product spec that you get since sometimes certain requirements just don't make any sense.

User Perspective

5. Dev mostly focus on big picture of the product and specific features and components of the application. You really want to put yourself in customer shoes and ask yourself. Does this make sense? Is this product easy to use? Is it intuitive? Would I like it if I was a customer? This also involves talking to product, design, UX to make sure that the application we are building would meet and exceed customer's expectation.

Dev testing defiantly add's a lot of value to QA's and the software life cycle as they can test certain area's much better than testers. Bottom line you can never replace QA testing with developer testing for the reasons listed above and the ones I missed.