We are getting close to the make or break point for the educational initiatives we have been planning for SummerQAmp. As I’ve been working through a lot of material, ideas, and suggestions, I’ve been trying to think about the proper order of what we can use and how to apply it. Yet no matter how we massage the data, no matter how we put the modules together, no matter what rosy scenarios we paint, there is one undeniable fact… we have no idea how this is going to go over until we sit some 16-24 year olds down and try this out.
My prevailing theory, and the prevailing theory of most of the people I have talked to on this front, is that we are putting the cart before the horse in much of the training that we have developed to date. It works good for those people who have experience with doing testing, but not so well for those who don’t have experience or don’t really see how to connect the dots.
It’s with this in mind that I am trying to create modules that will, effectively, allow people interested in software testing to look at a number of activities, consider them, poke at them, see what happens. At the end of those activities, we discuss what they did, what they learned, and then fill in the details of what they have been doing. Rather than go through and discuss exploratory testing, let’s give them an application to explore, fumble around with, “poke the box” (to borrow a Seth Godin metaphor) and otherwise have a play at the application. Then let’s discuss all of the things they did, didn’t do, and how what they did all maps to in that “theoretical” space.
We’re coming down to the wire and it’s time to see if we have something that will keep their attention. We’ll know soon enough, I guess :).