Diligent Reader Ayaz asks:

Everywhere there is talk about *the tester mentality* and how the testers should refine their approach towards a problem. My question is what would you advise a *developer* so that he can test his code and catch the bugs himself instead of waiting for a test engineer to report it. What would *your* approach be if you were an SDE?

I know there are always time constraints pulling your legs as a developer but I still think that a fair amount of testing should be done at the development site rather than at the testing site. Testing and finding an issue at the developer's end, for me, is far more effective and even time efficient (because there is no time loss in all the reporting and discussion).

My approach is that I come to work as a *Tester* and think that I am testing someone else's code. But this does not work as well as it should because I always find a soft spot for myself while testing. Its not completely possible (at least for me) to drain all the information about the code and implementation details and start with a completely different state of mind.

I completely agree that developers should do as much testing as they possibly can. Bugs developers find before they check in are cheap to fix - no red tape or change board to deal with. Bugs developers find may be a symptom of a larger issue that will radically affect their design or implementation. Every bug a developer finds and fixes is a bug a tester doesn't have to waste time finding and reporting. <g/>

I have not yet had the misfortune of working with a developer who refused to test their own code. I *have* worked with many developers who did not have the first clue how to test their own code. My Testing For Developers checklist is an attempt to remedy that.

If a developer wants to go even further into testing their own code, they can work to acquire the tester mentality. As Ayaz says, everyone talks about the tester mentality, and everyone has their own definition of it. I think of the distinction this way: developers tend to focus on "How can I make my code work?", whereas testers tend to focus on "How can I find all of the places and scenarios where my developer's code doesn't work?"

These are two very different mindsets. Take Test Driven Design. This is a design and coding technique where the developer writes a test describing one tiny bit of functionality, runs the test to verify it fails, writes just enough code to make that test pass (whilst keeping all other tests still passing of course), and then repeats. This is all about "How can I make my code work?"

Contrast this with the techniques James Whittaker describes in his books, which are effectively checklists of ways to find common defects (i.e., places where your code does not work). Or with the questions I list in my Testing For Developers checklist, which aim to get you thinking about what you might have done wrong - that is, "How can I find all of the places and scenarios where my code doesn't work?"

Switching back and forth between dev-think and tester-think is hard. Really hard. Very extremely hard. Essentially you are swapping out one mindset and swapping in a completely different one. Lots and lots of practice is typically required to gain even a modicum of facility in making this swap. Oooh - a challenge! What developer (or tester) can pass that up? <g/>

My final suggestion is to take the same approach as you would when learning any other skill: observe, talk with, and train with a master. Which is to say, watch your testers do their thing! Talk with them about how they approach their work, why they do the things they do. Pair test with them, which is useful and productive for all the same reasons pair programming is. Ask them to help you brainstorm test cases for your code. Any good tester will jump at the chance to help their developer test better!

How much testing should developers do? The answer is completely dependent on your context. In general, I feel that developers should do as much testing as they possibly can, freeing up my time from finding checklist bugs and allowing me to focus on cross-feature, integration-type bugs that tend to be harder to find and have nastier effects. You may answer differently. More important than any particular answer, though, is to simply have the discussion with your feature team!