In this month’s issue of Software Test and Performance, Michele Kennedy shares a great experience report on troubleshooting performance issues. It includes some great tips, recommends some free tools, and includes some real examples. It’s a good read. I wish more performance testing articles were written this way - real examples.
The third and final article in my SearchSoftwareQuality.com Testing for Performance series posted. The complete series can be found here:
“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?
Article one of a three part series just posted on SearchSoftwareQuality.com. Along with some heavy references to some PerfTestPlus materials (hey it’s where I learned performance testing), it’s got some tidbits from my experience and I think accurately reflects how I approach most of the projects I work now days. I welcome feedback.
Now all I have to do is write those other two parts… *sigh*
I’m no stranger to work. I’m what some might call a workaholic. However, recently I’ve been working too much. Between my day job, writing, and AST I’m a bit frazzled. One of the nice things I’ve found about our community is that when the going gets tough, people are there to help.
In AST, Scott Barber and Cem Kaner have picked up some of my slack, and I’m very appreciative. In my writing, my now long-time co-author has been patient and encouraging as we work through (yet another) dry spell. And at work I’ve recently had the pleasure of interacting with Alex Podelko as I’ve tried to struggle through too many projects (often at odd hours).
I’ve been doing a lot of multi-project multi-tasking (read more about that here). It’s kinda like putting your brain in a blender. A couple weeks ago I remember interacting with one of my team members and them stopping the conversation because I couldn’t focus long enough to process the information they were giving me. Not good…
Recently, these behaviors became manifest as I was working with one of our performance testers to create some performance scenarios for Hyperion IR Web Client. We couldn’t see traffic in the recording for the scenarios once the Web Client was loaded. Thinking we had an incorrect setting, like all performance testers we turned to Google for the answer. You can’t throw a rock and not hit Alex’s name if you Google performance testing and Hyperion. I’ve ready plenty of Alex’s writings, so I figured this was as good a time as any to introduce myself.
Alex was incredibly helpful in helping me work through my problem. He asked questions, sent me code, and looked at my screenshots. At one point Alex very gracefully took at step back and asked me what exactly was I trying to record. I think he figured out that I clearly wasn’t thinking, and he very nicely pointed that out. Web Clients run on the client side (hence the nifty naming convention); after you load a document nothing is communicated to the server until you request data. Data conversion, building graphs, filtering, etc… all happen on the client side.
I was trying to record client-side activity with a performance test tool. I would like to think that on a good day, I would know better. As I continue in my transition from technical leader to manager, I wonder if this is one of the common ways in which managers lose their ability to contribute productively to technical solutions. It’s not that I don’t still possess the technical skills; I’m sure I do. It’s that I can’t focus on anything long enough to get the clarity of thought one needs when solving difficult technical problems. I’m sure Rothman’s written about this phenomenon extensively (and I’m sure I’ve read it – I just can’t remember right now).