This post is growing into a large one and I will divide it in two parts.

One thing that has struck me through the years are how divided we are.
Testers Vs. Developers ... and all the prejudices that exists between the two groups.
This was an issue that was raised several times at Eurostars by several speakers and also on the panel session in the last day of the conference.

This has been especially clear to me since I routinenly move between the two camps being a so called "test developer".
On one hand I love coding and the craftmanship involved and on the other hand I love testing and the whole intellectual challenge in that process.

This text will be a bit stereotypical and exagerated, but all in order to show my point.
But on the whole I´ll bet you will have seen the things I mention here more or less in your daily work regardless if you´re a tester, developer or something in between.

But is it really as black and white as testers vs. developers?
No in between we actually have a few other groups that can bridge the gap and act as ambassadors between the two groups.
I´ve already mentioned test developers and theres also testers who have coded in the past.
Of course there also exists the group of developers who have tested in the beginning of their career, although these tend to have seen testing only as a necessary evil in order for them to get a foothold into the company to do "real coding" instead.

The other day I thought of another group that exists, the so called Design&Maintenance developers, in other word when you're on permanent defect fixing duty.
The work involed in defect fixing actually has lots of elements that resembles exploratory testing.
The developer looks for the reported fault, gathers data/information, learns about the product/feature, tests theories, gathers more information and so on, all in a continuous feedback cycle with the aim of learning enough of the problem to be able to fix it properly.
Also when we fix a defect we have to be on the lookout for other sideeffects or symptoms of this defect that we might not have considered and that also have to be taken care of.

Kaner decribes testing like CSI in that we have tools and procedures, but they don't define the investigation, that there is to much information to process everything and the investigator must select what to investigate and what not to.
This is also very applicable to the process of fixing a defect for a developer.

It would be very interesting to see if D&M developers would benefit from a class in exploratory testing (or a class aimed towards developers: "Exploratory Defect Fixing") and what their thoughts would be on it.
I might be tempted in the future to give a presentation at my company (which is heavily developer-centric, I´m the only one with a testing background) and see what the developers think of exploratory testing.

In the next part of this post I will try to discuss different ways that can be used to make the gap smaller between testers and developers.