Welcome to my blog!

Thanks for stopping by!

Alaska

Alaska
Showing posts with label programmers. Show all posts
Showing posts with label programmers. Show all posts

4/20/14

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.