Sunday, March 13, 2011

Programmers make Excellent Testers - Arguments and Counter Arguments

Janet Gregory’s post on Programmers as testers prompted me to do this post. She mentions in the post that “Programmers make excellent testers”. So I asked myself can I think of few reasons to support and few others reasons to refute the statement. Here I go …

Programmers make excellent testers because:

  1. Programmers understand their code and their fellow programmer’s code /very/ well. Hence knowledge of the code helps them to test /it/ better. Creator knows the best about his/her creation having created it.
  2. Programmers understand /better/ the technicalities of the platform (anything other than “software application under test”) on which their code runs.
  3. Programmers can /write/ /better/ automation code that tests their product code. Writing automation is part of testing right? Or test driven development?
  4. Programmers being closest to the code – can find and fix the bug in smallest time possible – hence can do efficient testing. First opportunity of finding bug in a code is with programmers. If there is a problem in the code – they are the ones that should know about it FIRST.
  5. … I can’t think 5th one … probably need some help...

Now, let me cross over to other side.

Programmers make not-so-good testers because:

  1. Programmers are /usually/ blind to their own mistakes. Their testing is limited by cognitive bias (confirmation bias)
  2. Programmers /typically/ good at “construction” work – getting spec to working code – not a key tester skill. Programmer testing is more like a cook tasting food made by him/her before serving.
  3. Programmers testing is /typically/ happy path – where would they get time to do “out of the box” as testing, unusual paths, usability, security and performance related tests? (Unless explicitly called out as a part of specification). Programmers /often/ do not see big picture.
  4. Programmers, all through their professional life, work to improve their coding skills – so testing is a part time work for them (which programmer would work to improve testing skills unless he/she decide to become full-time testers)
  5. It is hard for programmers to /think/ like users (many types of them) – their mission of Spec2Code limits them to think in terms of code

A bonus: Typically programmers hate or avoid testing (other than writing automation –which is again a coding work) as far as they can. Many would say “testing is not cup of tea” but I need to do it as we all in a team are responsible for quality. Programmers can’t make excellent testers simply it is not their job (in all).

In sport like Cricket – there are specialist batsmen, bowlers and also all-rounders (who can do both equally well). That is not true for testing.

Someone might say Janet’s context is /Agile/ development model – well, how does that change my “for” and “against” arguments here? How far does that matter?

Update : Pete Houghton (Twitter @pete_houghton) mentioned that debugging is a form of testing - programmers do it well. To me, debugging is an act of hunting down a reported or known problem and fixing it. Thus debugging follows testing - not a form of the latter. By going through the process of debugging repeatedly, programmers gain understanding of how they (programmers) make mistakes and how to avoid them. That also helps them to think about interesting ideas about testing. That is one reason that helps them to be better testers.

BTW, working in customer support - gives probably the best experience for testers, through exposure to wide variety of usage patterns (many of them - out of scope of specifications). Unfortunately - end users do not use applications as per the specification or user guide.



DiscoveredTester said...

A good post, and always an interesting topic to discus Shrini. My comments were becoming so long, so I decided to turn it into a blog response instead. My curiousity may not be in the same vein as that of the initial topic, as if one programmers or testers is automatically the answer. I think team context, budgets, and team composition plays more of a factor here than any ideal programmer vs tester choice for testing type tasks. I always find I try to avoid over generalizing that one group of individuals is better off not doing X or Y, when i feel the diversity of knowledge is what when leveraged together makes a team strong. In any case here is my blog post, lengthy admittedly, and I may have to refine some of the ideas within it in a later post, but Since its been a month since I've had free time, I better post it now or it will be April before I find time again :D

Some Thoughts on the Programmer vs Tester Argument

Anonymous said...

Great post Shrini! To the spot and concise compilation. But as I have the feeling that you actually somewhat are favoring the latter list, I would have a look at renaming the URL, which buts off the last part of the title. =)

Devon Smith said...

"Programmers can’t make excellent testers simply it is not their job (in all)."

Are you talking about having people with programming backgrounds be QA people full time? Or about having a full time programmer also have to take on QA responsibilities. I think this makes a big difference in how you answer this question. From reading Janet Gregory's post, it seems like she was speaking more of people with programming backgrounds, who wanted to work full time in QA vs just having the team's programmers take on the testing duties.

Russian Programmers said...

@ Devon Smith If you can start with a local programmer who is excellent and get them to devise a very short (1-3 hour) test that is difficult and exactly matches the skills that you are looking for. Then give all of your candidates this test.

Software Development Company said...

its very nice and interesting............. thankx for this post

Software Development Company said...

its very nice and interesting............. thankx for this post

Khushboo Bangur said...

A programmer cannot be good tester. Bz programmers end up by coding there on own module as per the given specs. but tester knows the end to end workflow of the system. So a tester can think better scenarios to be implemented and tested.