There is a common practice in our company to perform Developers Exploratory Testing (DET) sessions, explained by my colleague Davor [here](http://www.stickyminds.com/sitewide.asp?function=DETAILSIDX&tvniu=1&sqry=*Z(SM\)*J(ART\)*R(createdate\)*&ObjectId=17003&ObjectType=ART&sidx=1) . The cool thing is that this way of performing higher level testing has actually become accepted by our developers, and [they really enjoy it.](http://blog.jayway.com/2010/10/11/three-reasons-for-me-as-a-developer-to-love-developer-exploratory-testing/) In my current work of [developing our organization wide practices for quality](http://blog.jayway.com/2011/12/01/organization-wide-test-strategy-step1-deriving-our-quality-values/), I have made a deep dive into how DET is carried out on a regular basis. What I have seen is that DET is accepted and acknowledged as a valuable practice, however it is not really carried out in its full potential. There are many details and aspects of it to work on, especially regarding reporting and follow-up. This talk will gather my learnings from coaching many of our different development teams in their DET sessions. Some improvements are achieved just by carrying out ET in a better way, but there are also specifics about the involvement of the whole team testing together that give alot of value back to the project. One example is about what information that is gathered which are not plain bugs.
http://submit2012.agilealliance.org/files/session_pdfs/20120815_Siggeb_DET_Agile2012.pdf
