In a response to my
blog post on training, Mark wrote:
I would worry more about the thrashing effect of a developer testing course which did not focus on a specific developer tool set. Choosing a specific tool set allows the teacher to remove many variables from the discussion so they can rapidly teach concepts like "red, green, refactor" without spending time deciding if pyunit, nunit, junit, TestNG, or utplsql is the right choice for the user.I agree, and here's what I'm thinking -
A one-day course on "What works in software testing: Or How To be Lazy Without Really Trying" (With Credit Mike Schwern, of course)
Before the course, attendees email a list of the core technologies they work on. Then, we customize the afternoon, perhaps splitting into small groups.
Essentially, the course is "Homebrew Test Automation"++ - as a workshop.
Now, the whole idea isn't fully baked, but developing ideas with people on the cutting edge is part of what I use this blog for. The risks in the format are medium-sized; people REALLY like stable, repeatable training and start to weird out when I customize training on the fly. Such custom training is also hard to get right and easy to get wrong.
Still, that's what I'm thinking about right now. What do you think?