Archive for January, 2008

Build a list of all files in a directory structure in Ruby

Friday, January 25th, 2008

When testing web services it’s often nice to be able to process a set of XML files. In other automation it can be nice to process batches of files as well. For some reason I can never find the following code when I need it and I always have to re-code it from scratch. That’s always good practice, but it’s annoying when I need it quickly.

def getFiles(directory)
returnFiles = []
Dir.glob(directory + ‘/*’).each do | file |
if File.file?(file) then
returnFiles.push(file)
else
returnFiles.push(getFiles(file))
end
end
return returnFiles
end

So there it is. Google can now help me find my code whenever I need to build a list of all files in a directory structure.

Here is an example of how I might use that:

getFiles(”C:/Regression Files”).each do | testCaseFile |
resultsFile.puts(testCaseFile.to_s.split(’/')[-1].chomp +
‘, methodName, ‘ + object.methodName(testCaseFile))
end

Please tell me when I’m being James Taggert

Thursday, January 17th, 2008

Last year, I read Atlas Shrugged by Ayn Rand for the first time. I wanted to relate a specific conversation from the book, why it resonated with me, and why I think it’s relevant to software testers.

(There will be no plot spoiler here, so read ahead with confidence even if you haven’t read the book but someday plan to. Also, some people have an allergic reaction to Ayn Rand’s politics; that’s outside the scope of this post.)

Towards the end of the book, there is a conversation between Jim Taggert and his wife Cherryl. It’s close to the story’s climax and Jim is frustrated that life isn’t going his way and that his wife keeps asking him questions about what he wants. In the conversation Cherryl asks her husband, “Jim, what is it that you want to be loved for?” (What an absolutely fantastic question.)

The conversation is long. I’ve selected relevant clips from Jim’s response(s):

“If you don’t understand it, I can’t explain.”

“‘How could I have explained it to you?’ he said in the tone of abandoning hope. ‘It’s all so big and so complex…’”

“His shoulders sagged, relaxing. He approached her and dropped wearily down on his knees, slipping his arms around her. ‘You poor little fool,’ he said affectionately.”

Jim’s ego is very large. He is also very afraid. He’s afraid of who he has become, what he doesn’t know, and he’s afraid of all his shortcomings. He doesn’t know how to deal with those fears in a healthy way, so he lashes out when challenged and belittles those who disagree with him. It’s the only way he can “win,” and winning is everything.

Here’s why this is important: It’s easy for otherwise smart and well intentioned people, who have a lot of their personal identity invested in an idea, to lash out at those around them when their ideas are challenged.

What I found so compelling when I read this is that I saw myself in Jim. I’m not proud of that (note that this post is filed under I’m an idiot). I’m positive I’ve said my own versions of “If you don’t understand it, I can’t explain.”, “It’s all so big and so complex.”, and “You poor little fool.” Sometimes I say them in my head. In my lesser moments as a human, I say them aloud.

As someone who blogs, writes, and sometimes speaks; I generate a number of ideas (some of them even kinda good) and I get a lot of feedback on those ideas. For example, while reviewing a forthcoming article on performance testing, David Christiansen gave me some difficult feedback and I again felt my blood pressure going up. “How dare Dave tell me my approach is wrong? Doesn’t he know how smart I am? It will take me hours to explain to him why I’m right and he’s wrong.”

I noticed my allergic reaction to Dave’s difficult feedback and I took corrective action. I calmed down, told myself to shut up, focused on how much I respect Dave, and tried to put my ego aside. I got a lot of great feedback and the next morning re-wrote the first 750 words of the article.

I’m not alone. I imagine that almost anyone who maintains a blog, has written a book or an article, has gotten an advanced degree, or has some other specialized knowledge goes through this struggle at some level. (In a sick way I hope so, because I don’t want it to just be me.) Most people in software development have some kind of specialization; even if their specialization happens to be becoming a generalist. Most of us want other people to think we are smart.

In software testing, we have arguments about the value of certifications, certain practices and approaches to testing, which tools to use, which books to read, and which process models to use. I think those arguments are good for our industry, and I’ve found them to be good for me as an individual trying to learn more about my field and about myself. However, as certain arguments unfold I’ve found it to be relatively easy to find the Jim Taggert’s in our industry. I don’t think the challenge is finding the people who will tell you “it’s too complex, just trust me.” I think the challenge is in not becoming one of them.

The people I respect most in software testing, whom I collaborate the most with, and whom I try to learn from, help me face up to that challenge. Whenever I’m defensive about something, I know I’m not learning. Not only does my learning suffer, but those around me suffer as well if I withdraw or I lash out. If you catch a glimpse of my inner Jim Taggert, please tell me I’m being an idiot.

Rapid Tester Song

Wednesday, January 9th, 2008

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!

Building Trust as a Consultant

Wednesday, January 9th, 2008

Quardev recently posted an article I wrote on building trust as a consultant. The main points include:

  • Delivering value
  • Helping build the bigger picture
  • Turning down work
  • Talking the right language
  • Building up those around you

I really enjoyed writing this short article and wanted to thank Jon Bach for asking. He’s someone I’ve grown to trust over the last few years and I’ve learned a lot from him.

Late nights, early mornings, too many projects, and Hyperion IR Web Client

Wednesday, January 9th, 2008

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