Later this month at Agile Testing Days in Potsdam, Germany.  I’ll be collaborating with Matt Heusser on a full-day tutorial on Exploratory Testing practices and how they can be applied to speed information from testing to stakeholders.  Frankly, I’m looking forward to that.  This is going to be really good. 

Matt gave a good explanation of what we’re doing, and why, in the video linked above.  In short, we’ll be talking on how you can give fast and informative feedback to the people who care (and matter) on projects.  Yeah, I know we’re talking about this at Agile Testing Days.  The thing is, these approaches can work, and have worked at shops Matt and I have worked in, no matter what the development methodology in use is. 

The next day I’ll be conducting a two hour workshop we’re calling a “Tester Round Table“.  The idea is testers meet and talk about problems they are facing or dealing with right now

This is something similar to a SWOT analysis (what ever cool cred I have just took a significant hot by referencing that) where people talk about what the problems they have, what possible things they can do about them, what steps they might need to take to fix these issues and who, or what roles) they need to get on board and gain support from to make this work. 

Simple, no? 

We ran a similar exercise as an evening/extra activity at CAST.  One thing I learned, or re-learned, is that some things will not be able to be fixed from the grass-roots level.  If you are the only one who sees a problem, maybe that is, in itself, the problem?  Are you not understanding the context of the organization or the mission?  Excellent point for introspection.

Other folks participating at CAST came away with suggestions to try at their company.  These generally work by introducing them in a small way.  Going in with trumpets and slogans and big “motivational pitches” and “kick-off celebrations” and “bright! shiney! NEW!” ways of doing things tend to get rejected as “cool process du-jour.

The goal at CAST, and at ATD, is to present the model so people can take it back to their company and try it with their team or a subset of the team. 

Why do I think there is value in this? 

Simple.  I’ve seen it work.

I’m not much into the philosophical considerations around varied and sundry aspects of software and software testing.  I’m concerned with getting problems addressed and corrected, and getting good software out the door so people can do their jobs better. 

This works.

Another example of this was presented recently. 

At my local tester meetup, GRTesters (Grand Rapids Testers) we ran this same exercise for the August meeting.  The results were interesting.  Three folks from a single company showed up and presented an interesting problem.  After voting, that problem was selected as the one to work on.  We discussed aspects around it, including the roadblocks and how to deal with them.  It was a really good conversation.  (Checkout the notes here.)

The September meeting, the same guys from the same company came back and excitedly reported they took the ideas from the meeting, presented them to their management who were convinced enough to try it.  The notes from the September meetup read:

We start with a follow-up from last month.  The group that was having the issues we talked through last month – have actually ACTED on the discussion and are seeing improvements.  Coolness!

They were seeing positive change in less than a month! 

Can it work?  Absolutely.  Maybe not that quickly for you, but it does work when people are open to communication and understanding. 

If you are going to Agile Testing Days, please check these two things out.  They are going to be pretty cool.  If yo are considering going to Agile Testing Days, just do it.  Sign up and go.  Tell the Boss you NEED to go.  Get the boss to go!

This is going to be good.