On the back of the great presentation by Sigge Birgisson about Developer Exploratory Testing (DET) at Agile Testing Days 2012, and seeing one of our other teams doing it, I persuaded my team to give DET a go. Well I didn’t really have to do much persuading, they all thought it was a great idea, and were well up for it!
Since our team is a mix of developers and testers, I elected to call it Team Exploratory Testing (TET) and this is how it will now be referred as.
So for those who are not familiar with the principle, it is quite simple. Basically, the entire team does exploratory testing! There are a few more details, but essentially that’s it! The benefits of doing this are that it gets the entire team, regardless of your role, looking at parts of your product in different ways, perhaps even parts of the product you’ve never really used before!
The format goes something like this; firstly the session facilitator (me!) preps the session and determines the ‘mission’ for the session. It may be related to recent work, it might be more off-topic. In this case it was related to recent work we’ve been doing. The team is then split into pairs (yes, that pairing thing again!), and each pair was given a rough scope within that mission. I was careful to stress that they could stray from that by all means, but just to bear it in mind. I assigned the pairs to get a mix of experience, skills and abilities in each. A side effect from this is that the members of the team will get to work with people they might not have necessarily worked with much before.
The timings were planned as follows; after a 15 minute set-up period, the 45 mins of testing was to start. After the testing session, we would then have 30 mins reflection/chat/discussion about what we found.
Best laid plans …
|Two of the pairs getting set-up|
So that was the plan… you’re sensing a ‘however’ aren’t you!
However, it didn’t quite go to plan. On the morning of the TET session, one of our test engineers called in sick (there a lot going around at the moment!). Thankfully I managed to coerce a test engineer I know well from one of the other teams to step in, and for that we are very grateful!
Also people related, at the last minute it was suggested that our Technical Author and our Marketing guy might want to take part, and yes they did! So a hurried re-work of the pairings took place to ensure a mix of tech and non-tech etc.
For many reasons/excuses, I didn’t prepare as much as I was hoping to. The plan was to set up a bunch of virtual machines with test environments ready to go, but this didn’t happen so we were using developers own machines, this meant the set-up time was closer to 30 mins and lead to some ongoing confusion about configurations.
|Team Exploratory Testing!|
The testing part, however turned out to be very valuable. Something that had only been changed in the code base the night before lead to a very serious bug to be almost immediately found which was good. This did, however, reduce the overall usefulness of the remaining test time for that test pair.
A couple of other issues were also found, one of which will need to be fixed before release, the other can wait. This is in addition to a couple of minor UI change requests.
All in all, though, everyone gave pretty favourable feedback about the session, and are keen to do it again so it can’t have been that bad!
- Prepare Prepare Prepare!!
Having virtual machines set-up and tested would have saved a lot of time and allowed more time for testing. Will do this for next time!
- Book the TET session in plenty of time!
I tried to book a time in everyone’s calendar to do the TET session, the day before I wanted to do it…. needless to say I was somewhat naive in thinking that would work and was only able to book it for a few days after my preferred date.
- Have some people on stand-by
So by all accounts TET doesn’t work as well if not everyone is in a pair. So it would be good to have a couple of people on stand-by should anyone fall sick.