Mike Kelly’s blog

“Instead of focusing on training for a complex task, how can you make the task easier to perform?” -Influencer

Among other things, I’ve been leading a performance test team for the last couple years now. It’s been an uphill battle trying to find and develop the right talent, tame the performance testing environments, and deliver consistent results for the application teams we support. I now think I have one of the best groups of performance testing talent in the Midwest, but there is still so much we don’t know! It’s not for lack of trying, but the problem with performance testing (like anything else) is that you can never know it all: databases, protocols, mainframes, web servers, application servers, load balancers, driver upgrades, data center moves, AJAX, programming languages, performance test tools, performance testing methodology, changing user populations, coordinating deployments and monitoring, and oh yea, application functionality that just won’t stay the same from month to month.

Even for the best and the brightest, the problem of learning becomes overwhelming.

Last year I read Influencer: The power to change anything. It wasn’t as good as Crucial Conversations (by the same authors), but it was still a good read. The quote at the start of this post really hit home for me. It got me thinking about the learning problem for complex tasks. How can I structure the work to make it easier, instead of structuring the training to address the most difficult tasks? It’s a great question. It challenges you to recognize that sometimes, we don’t simplify the things that we do, simply because we already know how to do them. Then sometimes go about training others in what we know how to do, without ever asking if that’s the best way to do it.

Tool vendors understand this principle (I think). They develop tools that make it easier to perform our tasks. If a tool is well designed, it takes something complex and simplifies it. Many of the tools I’ve seen for performance testing, web service testing, and exploratory testing do this. I also think checklists (formal, heuristic, or taxonomies), simple scripting (Ruby, macros, or AutoIT), and simple lean process principles can play a large role in simplifying the work to make it easier.

On a cautionary note, I’m not saying better tools are a substitute for training. I remember Goranka Bjedov once saying, “A fool with a tool is a faster fool.” I’m not suggesting you don’t need to continue to train. I am suggesting that when you think about the never ending problem on training people for complex tasks (which testing is) that simplifying the tasks can be one way to help cope with the complexity.

As we continue to grow and learn as a team, I’m planning to remain focused not only on how we can improve our training but also on understanding how we can change the work to make some of the more complex tasks easier to perform. Right now I’m big on checklists, I’ve always been big on scripting (I like to go back to my roots), and I think we can do more if we start looking at what tools we use, how we manage the work, and what processes we currently use. (Note, I’m not talking about the documented processes, but the actual processes - how the work happens today.)

How do you deal with this on your teams? How do you make complex tasks easier to perform?

Another long day at the office, a crashed hard-drive at home, the wrong version of Windows Vista media (who knew you had to order the 64-bit version after you opened the version you purchased?), and estimates for a new driveway stuck in the door when you get home… It’s all ok now. I’m smiling thanks to Geordie Keitt’s new song, Black-Box Testing.

Mr Keitt, thank you vey much!

Last night I read a Fast Company article by Dan and Chip Heath titled Heroic Checklist. Now, I normally like everything these guys write because I like their writing style, but this one really resonated with me because at work we’ve been talking about building out some checklists to support our performance testing. We could use some checklists for environment configuration and coordination, modeling and calibration, and for execution and reporting.

I like the article because it addresses many concerns that I think testers have when they hear “checklist.” If you’re already a fan, not much new here. If you’re a checklist skeptic, give it a read and see if it gets you thinking about how you might use a checklist or two.

The very talented Geordie Keitt just released his first software testing song. I say first because I hope there will be more. The song is “I’m Gonna Be a Rapid Tester Someday” and you can find it here.

Rock on Mr. Keitt!

The December issue of Writer’s Digest has some great articles on creativity in it. One in particular caught my attention: Blinded by the Light by Leigh Anne Jasheway-Bryant. In the article Leigh Anne provides tips for overcoming Too Many Ideas Syndrome. It’s a problem many testers face. I think all nine tips can be applied to testers who have to deal with managing all the test ideas they have in their head.

Meeting of the Minds by Michael J. Vaughn and Mapping Out of a Block by Greg Korgeski are also very applicable to what we do as tester. Three great articles for that look at techniques for generating/elaborating, roughing/refining, and refocusing.

Pick up the December issue if you don’t already get Writer’s Digest. (And of course, what tester doesn’t already get Writer’s Digest?)