Too Much Information

I'm in the mood to lighten things up a bit, but at the same time, I'm also in the mood to state what is probably a blinding flash of the obvious: I am a willing victim in the "too much information" reality robbing my effective attention span.


The Police song was released on the "Ghost in the Machine" album in 1981. Sting, Andy and Stewart felt their lives were, to creatively borrow a title of another band's Greatest Hits collection, "suffering from 'A Slight Case of Overbombing'" (I know of a few readers who will get that reference ;) ).  The amazing thing is, I wonder how they would feel about the world that has come about in the 31 years since this was originally released!


I used to pride myself as one who could say "you only have to tell me something once, and it will get done." In a simpler time, that was entirely true, and I prided myself on being able to do exactly that. I also used to pride myself on having a photographic memory. Sadly, I no longer can make either of those claims. The reason? With the sheer number and volume of things that vie for my attention, it's impossible to keep everything going on in my head at the same time. Once upon a time, I could do that. I genuinely can't any longer.


I've gone on the record in the past to say that multi-tasking in the human sense is a total myth, and I believe that to be the case more so now than I ever did before. Anyone who claims they can "multi-task" is full of it. They can ineffectively split their attention at a variety of points, and they can focus and defocus on things that matter to them. I'll accept that listening to well traveled and fully consumed music while working is a sort of multi-tasking (personally, I just consider it mono-tasking with a soundtrack), but the idea that you can code and follow a discussion on Twitter, or solve a high order problem while managing your email inbox, not so much.


There are some horible habits that I, try as I might, struggle with. I made a point a few months ago to do my best to live "Inbox Zero", and for several weeks, I succeeded. However, over time, older habits crept in, specifically the habit of "I can't deal with that right now, but I'll get back to it later when I have more time to deal with it". The dirty secret is "we don't have more time later". Any set of time we choose to focus on something is a conscious choice to not focus on something else. Time can't be banked, and unless we make tremendous strides to knock through a backlog of issues, that mythical "time later when things are not so hectic" is not likely to appear.


There are several techniques I use to effectively force myself to dig into my task list and back log of "Too Much Information". Again, I share these not because I'm some time management guru, but because I'm a wayward time management schlub just like so many others out there. Thus, here's some thoughts on how to dig out of the information rubble that surounds you.


Find Out When Your Circadian Rhythm Works Best: If you have noticed that you have high points and low points when your attention span and brain seem to be acting in an overclocked fashion, and some times you just feel like you want to pass out or veg, this is your circadian rhythm at work. More to the point, it's getting tuned into your dips and valleys and when your brain will fire the best. I'm not sure that I know when this hapened, but I discovered about ten years ago that my most productive cycle is as follows:


- 4:00 AM - 7:00 AM - Best time for solving Deep Problems or Studying hard Topics 

- 7:00 AM - 10:00 AM - High energy for communication and interpresonal issues 

- 10:00 AM - 1:00 PM - Best time for repetitive busywork and maintenance issues 

- 1:00 PM - 2:00 PM - Natural lull, usually when I get lunch. If the option is open, an awesome time to take a 20 minute nap. 

- 2:00 PM - 5:00 PM - 2nd Best Time for Deep Problems or Hard Topics 

- 5:00 PM - 7:00 PM - 2nd Best Time for communication/ interpersonal issues 

- 7:00 PM - 10:00 PM - Natural lull after dinner, usualy a good time for casual reading or busy work.

- 10:00 PM - 4:00 AM - Sleep (note, this often varies, and can start as early at 9:00 PM and run as late as 6:00 AM)


These are general guidelines for me, they are not absolutes. It's not like I can't tackle a big problem before lunch, but if I had my choice, I'd structure the things I do during the times I listed. When I take advantage of these rhythms, I am able to get a lot more done than if I try to shoehorn things in at less optimal times.


Make Focus Time a Game: I have stated in the past that I use tools like RescueTime and Pomodairo to set up blocks of time to see if I'm really being as productive with my time as I think I am. RescueTime is a good way to actually see where your time goes and how much of it goes where and when while you are online. Pomodairo is a little tool that lets me set up dashes of focused time and enforced breaks to step away and de-focus. It's entirely possible to "game the system" so that you feel more productive than you really are, but if you are honest with yourself, and you are willing to be a little competitive, you can get some excellent productivity gains out of these tools.


Going on a Media Diet: A lot of us may do a number of things on social sites for a variety of reasons. I make no bones about the fact that I use tools like Facebook, LinkedIn and Twitter as ways to keep in touch with and communicate with friends and family, but that I also use these tools to help build a brand for me and my blog. Spending time on these endeavors and effectively communicating with others is helpful, but the benefits are asymptotic; a little time with each can yield good benefits, but spending ten times as much time doesn't yield ten times as much benefit. These tools can be a great boon of interesting information, or they can be monumental time sucks. To get this under control, sometimes declaring a media diet is a great way to get control of your time and energy. Pick one service for a day, a week, whatever, and just focus on reading or interacting with that one service.

Take Advantage of "Ubiquitous Capture": This is a nebulous term, and it really comes down to "write stuff down", but how you do it and what you write down will vary from person to person. I use Dropbox and a variety of spreadsheets to store interesting links, thoughts, ideas, random events, and people's forwards of "you should check this out". I use Twitter's Favorites option regularly so that, at the end of each day, I can go back and see what I wanted to remember and not lose track of. I try my best to group and filter emails into topics and subjects and deal with them in their sphere rather than one at a time.


Do Your Best to Banish the "Mindless" From Your Activities: Have you ever noticed how often, whenever we want to get a handle on a problem (weight, money, time, exercise), the first recommendation we are given is to "write down everything you do in [Domain Sphere] for a week"? It's cliche, it's trite, it's sometimes patronizing... but it's tremendously effective. Why? It brings to the fore all of the things we do at a subconscious level. Tracking every bite of food makes you aware of how many times you get up and go to the break rooom or open your drawer to nosh on something. Writing down everything you purchase at all times makes you aware (sometimes painfully) where you are spending your money. Writing down how far you walk, how many reps you do, how much poundage you lift, how many miles you ride, makes you aware of your true activity level. Being totaly honest with yourself in RescueTime tels you where you are spending your time when you are online. All of these things have the same goal; they move you from mindless action to mindful action. Our deficiencies or under-achieving areas are often not because we are defective, but because we are not paying attention to those areas. If you really want to get a handle on a problem, focus your full attention on it for a given period. You'll be amazed what you discover.


Remember, I don't share these ideas because I think I'm great at doing this. I share them because I know I am frequently lacking in these areas. The Twelve-Step Programs first step is "the way to deal with a problem is to know/acknoledge/admit that you have a problem". It's unlikely that we can banish all distraction, or shut off the flow of too much information completely, but with a little proactive action, and realization of what works best for us, we can help tame a lot of these issues and, perhaps, significantly rein in the overbombing.

A Tourist Returns: Adventures in TestComplete Land

I'm willing to bet some of you are scratching your head at the title.

Back in 2007, when I was working with Tracker Corp, we were exploring the options available for performing automated testing of both Windows applications and Web sites. We had received a number of recommendations, and I was tasked with trying out a few of the options. Ideally, we wanted to have "one tool to rule them all", and while we had some money we could spend on the process, it wasn't unlimited. Tracker's total headcount at the time was 20 people; we weren't looking to break the bank on this.

After several screencast demos, a variety of vendor conversations, and me playing with several demo releases and installations, I decided that I liked AutomatedQA's tool TestComplete. It had some cool options for providing what I liked to refer to as "computer aided testing" within a Windows app, and it let me "Record and Playback" a variety of basic tests.

Now, I need to make a few things clear. I was never an expert at TestComplete. It used languages that were fundamentally different than what our team was using, though VBScript was a close enough environment that I could use it to communicate with our team, who were using VB.net or C# for most of the application code we were writing at the time. Also, we had implemented our web solution using a tool called DotNetNuke, which had a stubborn tendency to resist robust automation efforts.

Still, even with all of that, I found quite a bit to like in TestComplete. Alas, my journey with TestComplate ended when I changed jobs. The TestComplete license stayed with my former employer, and I embarked on a new expedition into Ruby/Rspec/Cucumber Land, a realm in which I am dwelling and actively exploring today.

Ruby/Rspec/Cucumber and its assorted tools has been an interesting learning curve, and I'm doing quite a bit of testing with them, helped considerably by the fact that my development team uses all of the same tools. Yet I've long wondered "what ever became of my friends in TestComplete land?" How are they faring? What does TestComplete look like now?

The cool thing about having a blog, being a tester, and shooting one's mouth off at opportune times is that, amazingly enough, people will listen! It's with this that I was presented with an opportunity. Come back to TestComplete Land, and see what has changed in my absence. Oh, and would I be willing to write a bit of a travel guide and some comparisons to my current workaday environment, and some thoughts about where TestComplete has come since I last visited their fair land? I said "Of course!"... and this is where we are today!

So what's the catch? There isn't one, other than the fact that the folks at SmartBear have given me a license for TestComplete for free. In exchange, I write about it and tell them what I think. I'm mentioning this out of full disclosure to say that I have received the software so that I can write about it. I'm happy to do so, but I want to make clear I am not obligated to provide a glowing review. I'll call them as I see them, and if I get confused, lost, or frustrated, y'all will definitely know. Likewise, if I see something really interesting, noteworthy or cool, I'll likewise let you know.

This will be a series, and I'll be coordinating with Alex Forbes over at SmartBear over the areas to cover. Stay tuned for further travelogues :).

Weekend Testers Americas Is Looking For Facilitators

For the past year and a half, I’ve happily run the Weekend testing Americas sessions and, with few exceptions, I’ve been the primary facilitator for these events. So far, it’s worked great… except when things happen where I can’t be there. Then we have a problem.

Sadly, due to some automobile challenges and some needed reshuffling of drivers for my Boy Scout Troop and those attending Scout Camp starting July 7th, and since we are now no longer self contained (originally all Adult leaders attending were driving there and back, now we need to recruit some drivers to go up and come back the same day) there’s no way I can get kids to Scout Camp and facilitate the session at the same time.

This is a known danger with me, and it stems from being a lone gun much of my career. I tend to do things and just, well, do them. My biggest weakness is that I rarely ask for help, and because I rarely ask for help, it tends to leave a vacuum when I can’t be there to do something. So starting today, I’m actively recruiting for Weekend Testing Americas facilitators to be.

What does being a facilitator entail. At its core, it means committing a few hours on a Saturday (or any other day, really, the facilitator sets the schedule) so that they can do the following:

- Set up a Skype session (using the “weekendtestersamericas” account)
- Welcome and add attendees to the group discussion
- Introduce the topic, the testing objective and the charter(s)
- Encourage newer testers to participate (often pairing with people who are very new to the process)
- Keep track of the time and make sure that the discussion moves well and freely
- Ask questions to keep the conversation moving
- Make sure the session ends on time

After all is said and done, they capture the Skype chat transcript and save it as a document, and then the final steps would be to write an experience report and post it, along with the chat transcript, to the Weekend Testing site.

There are some additional steps as well, usually involving posting announcements of sessions to Twitter and sending an email to the list of contacts, getting more testers to likewise advertise the sessions, and posting the “next session" details on the weekendtesting.com site.

Is that asking a lot? I honestly don’t know. I’ve done this for so long now that it’s mostly automatic. It may be a lot to ask one person to do, but it may not be too much to ask two or three people to do (and to be fair, I frequently get facilitation assistance in sessions from Albert Gareev and Ajay Balamurugadas, so even if you go it alone, you most likely will not be “going it alone”).

So yes, this is a call to arms, and a request. I have been remiss in sharing how to do this, and I want to help spread the ability and knowledge so that, when I cannot be around, Weekend Testing Americas doesn't just stop. Here’s another thing, you do not have to be in the Americas to facilitate the sessions. You can be from anywhere in the world and do this. My only request is that you schedule the session(s) at a time that participants in the Americas can reasonably be there (we’ve typically used a range of from 9:00 a.m. – 3:00 p.m Pacific, with 10:00 a.m. Pacific being the sweet spot).

If you are game, please feel free to email WTAmericas@gmail.com and I will most certainly get back to you… very quickly, I’m willing to bet ;).

3 Books that Can Help Master an Open Source IDE

First, some background. My company has been using RubyMine as an integrated IDE for some time, but the team has tried some other options; there has been a preference to move towards using Vim as the editing environment, along with some other modifications. Additionally, I've been trying to do what I can to maintain the Ruby I am learning (granted, it's still fairly rudimentary, but I'm getting better).

One of my goals is to make a driver for a number of Cucumber scripts that I use to drive my testing. The name of this test environment is jokingly referred to as "Mordor" and the driver that oversees everything is called "Sauron" (yeah, our group has other utilities that are LoTR inspired too, it happens when you get a bunch of geeks together ;) ).

To this end, "Sauron" right now is a bash script that does some things in a fairly simple manner:

- it runs some preliminary steps to make sure the environments are clean.

- it then runs a randomized order of tests (currently hard-coded in my rake setup, looking to make it a flag that I can call on for the future).

- it then takes the failed test cases, does some text substitution to make new test suite lines, and then reruns the test suite.

- currently, I have it set to run repeatedly until the failed cases log file is empty. This alerts me to troublesome test cases and the areas in which they might be failing.

While this does the job in bash, I'd really like to make this a standalone app in Ruby, I'd also like to make it act and have all the attributes of any well designed command line application. To this effect, I've found "Build Awesome Command Line Applications in Ruby" by David Bryan Copeland to be a very cool read. This is a recently released title from Pragmatic Publishing (as are all three of these books I might add) that walks the user through how to create a robust and well designed command line application in, you guessed it, Ruby.

This book goes well beyond just the basics of writing a command line app. It also discusses options such as how to create an effective man page and usage syntax, how to create meaningful exit codes and format output so that other programs can use them, trapping signals from other apps so that your app can use them effectively, making your app customizable by using external configuration options, distributing your app using RubyGems, and creating acceptance tests that follow human behavior and an introduction of sorts to test driven development.

It's a slim book that clocks in at just under 200 pages, but the information provided and the way that it structures the development process is very reasonable and easy to follow. Plus, the information on how to do these steps goes well beyond hacking together an app. If you want to approach the process from a craftsman's level of appreciation, I think this book does a great job.

Having come to enjoy the ability to open a bunch of tabs in RubyMine. I'm also used to doing the jumps between tabs on the terminal window and keeping track of a lot of the processes I run while writing code, checking on runs and also looking at system resources. Still, I like the ability to actually see everything in front of me, and move and navigate between the various areas while all of the steps are happening in real time.

There are several ways that this can be accomplished, and my team has decided to use tmux to do this. How timely then to have Brian P Hogan come out with "tmux: Productive Mouse Free Development". This is a quick read (the whole thing is just under 70 pages) but it is packed with helpful ways to leverage and get used to working within a multi paned environment and customize it to maximize your speed and focus.

Sections include setting up multiple panes and navigating between them, running commands to optimize movement, copying and pasting text between windows, and how to utilize pair programming with tmux, both with shared accounts and separate accounts. I've grown to really like using tmux, and this is a quick and informative way to get up to speed.

Finally, to take advantage of this cool new tmux layout and leverage speedy text editing, the team has decided that Vim is the tool of choice (thankfully, my years of Vi on SPARC machines in the 90s can come back and help me once again :) ). To this end, Pragmatic Publishing has a book in beta currently for Drew Neil's "Practical Vim: Edit Text at the Speed of Thought".

To be honest, I picked this up just yesterday, so I'm only a few chapters in, and this book is still being written, so to give a full review is premature, but I like what I'm seeing so far.

The book is currently split into six parts. The first one gets the user up to speed with the various modes in Vim and also gets the user to wrap their head around the various Ex commands that make Vim's command line experience so expansive (and occasionally maddening).


Part 2 deals with manipulating and using files.

Part 3 focuses on speedy navigation within and between files.

Part 4 focuses on registers and macros, and the ability to string together complex commands to massage files and their contents in ways you may not have imagined possible in the visual or command modes.

Part 5 deals with Search and Substitution commands, and ways that you can do massive edits of sections of data.

Part 6 deals with useful tools that can be called from within Vim and add to the ability to rapidly pull in text, edit text or delete text, as well as some cool tips on how to work with and maintain source code.

As this book is still under development, and I expect more will be added, don't take this review as a definitive one, but if you like the idea of beta testing books, this one would be a good one to do it with.

Again, I want to state that I like RubyMine and think it does a number of things quite well, but if you decided that you do not want to have to pay for an IDE and would like a flexible alternative that delivers many of the benefits and opportunities of a dedicated IDE, these three books will definitely give you plenty to consider and ways to get proficient with little cost (just the cost of the books themselves; the software is FREE :) ).

My Current Dilemma: Resolved (Sorta)!

Yesterday, I mentioned that i had some issues with making my tests for Cucumber be totally random if I wanted them to be. I also asked the test community out there to chime in with their thoughts and their approaches to how to handle this. I received a number of replies through Twitter and email, and it even got the attention of one of my team's developers, who when I told him what I was aiming to do, did some digging of his own... and here's what he found:

Basically, if you add this to your env.rb file, it will shuffle your feature file.

I've tested this, and it does indeed work. No tweaks, no file name or directory changes needed. The only thing is that it's either on or off, so my next step is to see what it will take to set this as a flag to rake. It would be sweet to just say something like "

rake cucumber:tag:machine:random


To have randomized runs, and not include the random tag to have them run in standard, alphabetical order.


I'm not 100% of the way there, but this is pretty good so far :).

My Current Dilemma: Randomizing Cucumber Tests

I'm working on a situation where I am trying to describe how to balance out activities such as Acceptance Test Driven Development, GUI automation and exploratory testing, and explaining where we can take ideas from each and work with them to help us get a balance between the three. This is the subject of a talk I'll be giving and am currently writing (which also explains my being more quiet than usual on here :) ).

One of the ideas I discuss, and that I actually do, is that I put a little bit of "What if" into my acceptance level tests. I have a suite of tests that I run to check and verify basic functionality for every build that we make and push to our respective machines (development --> demo --> staging --> production). All of my tests are written so that they can run on any of these environments. These are Cucumber tests, running on top of Ruby in a Rails environment.

One of the limitations about running Cucumber as an acceptance testing tool is the fact that the tests all run in alphabetical order in the feature directory. This is assuming you run your tests using rake; my setup is configured so that I can run a suite of tests with "rake cucumber:[@tagName]:[machineName]". For some added analysis and review, I currently have a bash wrapper script that allows me to tee the output to a log file, parse the log file for errors, set up a new suite of tests, and then rerun them. The goal is to get to where I can run these tests in a single pass and have no errors (legitimately, of course :) ). Usually, though, that doesn't happen. I typically have to make three passes before all of the tests pass and there's no more errors to parse in the log file.

In a pinch, that's OK, but the nerd in me doesn't like the fact that I have to tweak things like this. This caused me to start asking "What if"... What if there's a dependency I'm not aware of? What if there's something about the way that the tests are run and the way that we authenticate certain accounts that might leave "rat droppings" in the state condition? What if I tweaked with the order of the tests? What if I totally randomized the test order every run?

I've been able to address the first three, but the fourth has been a bit of a mystery. How can I set up a process where, without going in and renaming directories or files every time, can I make it so that the sixty or so scenarios tests that I run are always in a different order? I've seen different ideas, but most of them require making a weight for tests (which isn't really random), or setting up some kind of  permanent table with file name and line number to designate the test to be run (again, has to be manipulated each time, and adding tests creates overhead), or using bash's $RANDOM option, but again, this is getting me into doing bash gymnastics, which isn't really my goal here.

So I ask my fellow testing friends, especially those who use Cucumber and Rails, what do you do?

TWiST turns 100!!!

It's been an interesting ride. Over true past two years, I've had the opportunity to produce, sequence, edit, and format Software Test Professional's 'This Week in Software Testing" podcast. We've changed up the format a few times, explored a number of different avenues, and seen our collective fortunes change considerably from when the idea was first proposed back in 2010, and when I signed on to actually produce the show.

Some things I've discovered along the way:

1. Perfection is asymptotic and impossible to achieve, but just a little bit of clean-up can reap tremendous benefits. The problem comes when we try to go beyond the basics. Stray "ums" and long spots of dead air are easy to achieve, and make a big difference when they are removed, but doing more advanced editing (re-sequencing, cutting phrases to make a more coherent flow, etc.) is really hard to get right. Voice inflection has a rhythm and a flow, and when that rhythm is broken, it's noticeable, possibly even more noticeable than the stray ums or stutters would be. Thus I've learned that, unless it's necessary (audio drop-outs or other actual "damage" or "distraction in the recording), "leave well enough alone" is a good rule of thumb.

2. Remote podcasts are the biggest headache. On one hand, it's great to get recordings of live environs that would be lost to time otherwise, but in some ways, it's tricky because it's hard to get a room balance unless you can plug into a sound board to record. Sometimes that's easy, sometimes not. Usually, Matt or I bring a portable MP3 recorder and we place it in a spot where it can pick up the audio. Sometimes we can extend them from a tripod or a stalk to get a live room feed, but more times than not, the answer is to place the recorder on the podium or table. Positive, it gets the center of the room and when the speaker is lined up, it's crisp and clear. If they pace the room (common with live speakers), we lose them when they are off-axis. Most frustrating is when they "palm the table" or place their hands on the podium. Yep, the recorder picks all that stuff up. If I'm lucky, they are between breaths or at pauses, meaning I can filter them out. If they are during their speaking, and it's an important point, there's nothing I can do but leave it in there and let the bumps and noises be.

3. We do our group meeting calls on Skype, and most of the time, everyone comes in at a slightly different volume. That means that I have to do separation and mixing (really time consuming), or I do track segment amplification, trimming, leveling and normalization. While I haven't gotten to the point where I can do a totally automated "clean and level" with one take, it's gotten to the point where, after I do a course re-leveling of the audio and get most of the audio into a rough volume range, then I can run a number of scripted actions on the file and get the sound as level as possible. This used to take me 30 minutes on a given podcast. I've shortened this down to about ten minutes now.

4. I've experimented with five microphones since this process started, and I've concluded that the Blue Snowball and the Blue Yeti make for the best podcast microphones. They sound warm, they allow for different configurations, and the Snowball in the "Ringer" just plain looks cool. It reminds me of doing a radio show in the 1950s. Also, along with using the Blue Snowball mic, I have decided that 4:00 a.m. really is the best time to record my voice. It sounds way deeper and more sultry (like a real announcer) at that time of day, so it's become a habit to just record my vocal part then when possible. Later in the day, I'm a lot more high pitched and reedier.

So what do we have in store for the next 100 shows? I'm guessing a lot of topics that you all will find interesting, a mix of presentation styles, and hopefully an evolving and cleaner presentation, one that you will enjoy listening to for the next 100 episodes, or more :).

Book Review: Poke the Box

As someone who has quoted and talked about Seth Godin quite a bit here, it's taken me a bit of time to get to "Poke the Box". It's a short volume, so it doesn't take a lot of time to read, but it does offer some interesting and quick insights, encapsulated in the format that Seth does so well on his blog.

The entries are short, and really, they can be read in any order. Picture it as sort of a "Lessons Learned in Software Testing" for your motivation and emotional focus. The metaphor for the book is a story about a friend of Seth's who was an engineer, and who made a large electric box that had lights, switches and buzzers that would do different things when played with. He stuck this big box into a  baby's crib. What did the baby do? He played with the knobs and the switches, he saw the lights and heard the buzzer. He laughed as he played and interacted with it. In short, he "Poked the Box".

It's a long form way to say "you have permission to experiment. You have permission to not be ordinary. You have permission to take control of your goals and your dreams, but once you do, you have to actually do something with it."

"Poke the Box" is less a cohesive book than it is a series of exhortations and pep talks. Again, its format allows you to skip around and read the sections that interest you at any given time. You can pop it open to any page and read something that will get you fired up. That's the intent, and Seth has the passion and the drive to get that across. His main goal is to get people to start things, work at it, fail early and often, and learn from the mistakes and try again. Much like in Linchpin, he focuses on the language of the Lizard Brain and the Resistance, two concepts that were key to the material in that previous book. They are back in force here, and they are meant to help give everyone the motivation to shout them down and prevail over them.

A good quote to sum up the purpose of Poke the Box:

"Please stop waiting for a map. We reward those who draw maps, not those who follow them."

Test First, Then Lesson

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 :).