Last week I had the chance to take part on a project as a developer (OK, maybe a bit less than a developer since I was mostly writing Ruby-Wrapped HTML & CSS).

Something interesting happened to me at the end of my second day of work. I took a 1-hour break in order to do some sanity testing on the application. My project partners though that I would come out of my exercise with buckets full of bugs, but to my and their surprise I was only able to find some pretty trivial issues.

It’s not that the application was clean, this week I did the same exercise and I found a large number of bugs I most certainly missed the first time around, but what I think happened was that I was trying to test while still on the mind-set of a developer.

I could not explained it then, but now I finally understood it. During my first testing pass (wearing the Developer’s Hat & Shoes) I was verifying that the code we wrote was working based on the scenarios we had defined, I was focused on a specific path; but during my second pass I started working like a tester, running scenarios from the point of view of a customer who will use the application in any way it will let him work.

Don’t get me wrong, I’m not justifying the lazy developers who release their code to testing without even compiling it outside of their personal environment, but on the other hand we need to understand the limitations a developer has when approaching testing.

Next time you get a developer for some testing task on your project make sure he switches hats and starts looking at the application like a tester. Work with him and show him how to look for bugs outside of pre-defined (and sometimes over-trivial) scenarios.

Related posts:

  1. Why can’t developers be good testers?
  2. Management by Walking Around (your bugs and tests…)
  3. Great testers, not so great CVs…
  4. Test Plan Recipe for a Mixed Formal & Informal Testing Approach