Exploratory ensemble testing - 18 months later

18 months ago I approached the developers of one of the products that I'm testing with a radical idea: To take 90 minutes every four weeks to run an exploratory ensemble testing session on the current state of our product.

This idea was the result of two triggers: 

• Attending a workshop by Lisi Hocke on remote exploratory ensemble testing
• The fact that we kept getting lots of feedback from internal and external customers on our new features. Sometimes the feedback was proper defects but more often than not it showed ways to improve a feature that we could have noticed ourselves. 

There was also a hidden agenda in introducing those sessions. Many of the developers did know that testing is important but they were reluctant to test their own implementations. I hoped that by having them test regularly they would pick up testing skills and also see that testing can be fun and challenging in a good way.

In this talk I’ll explain how I introduced the idea, how a usual session is run including preparation and wrap-up and what both me and the team learned in the last 18 months.

Not everything happened as expected, so I’ll talk about

• how biscuits didn’t always solve our problems
• which moderation approaches worked - and which didn’t
• the effect those sessions had on the product and team
• how we made this work in a distributed team
• note taking, the good and the bad

In the end I hope to convince you that exploratory ensemble testing is a useful tool in a team's toolbox and that giving it a try is worth it.