I’m getting some responses (in comments, and email) that paint ofthewolves.com — or at least my description of it — as segregating the community around software testing. Although I could entertain this perspective (Why have two playgrounds?), I get the impression that the young software testing community is underrepresented, and could use a place where information is targeted specifically to — and possibly from — them. This doesn’t mean the whiz kids will go off on their own and create new testing techniques that we won’t share with the older generation; instead, it’s specifically targeted toward sharing our ideas and cultivating information that may be interesting to us — that is, cultivating it because I’m not sure it exists elsewhere. This could be: What to look for in an entry level testing job. What troubles occur transitioning into the software testing workplace. What skills are needed when beginning a career in the testing world. I’m not sure I can answer all these questions from my experience, but I think there’s value in putting them all in one place.

In some sense, this idea is an attempt on my part to find out if there actually is an “us.” My impression of most people in the software testing world is that they were thrown into it unexpectedly, yet have since chosen to make it a career. I rarely see people who have chosen it early on, or have recently graduated and have found it to be their passion. In my experience, I often get confused looks when I tell people I want to be a tester after having such a rich programming background in school. With ofthewolves.com, I not only want to share this experience with the world, but I want tell others teetering on the edge that this decision is okay, that there are others like you and that it is something you can make a career out of. To me, this is recognition, not segregation, and will eventually help the community as a whole.

Now. Behind this dramatic exterior is an implementation that still needs to be crafted. It may be that this blog presents informal case studies of the troubles new testers face. It may be this blog targets information toward nervous graduates who don’t have the testing equivalent of “Programming websites with Rails.” It may be that this blog inspires highly experienced testers to reflect back on their transition and spotlight the things they went through. I’m not sure, at this point, as the idea is still very young. Yet, I think it’s important to get others involved, to see if this idea has any value and to see if something good can come of it.

Lastly, as a more personal interest: I refuse to believe I’m one of the only up-and-coming software testers in my generation. If there are more out there, I want to give them the spotlight as these are the people I’ll be working with in the future.

I have an idea, and decided to simply “throw it out there.”

I’ve owned ofthewolves.com for a while, with the intention of making a community blog that aims content toward recent graduates interested in software testing. The idea, in general, would be to get younger rock star bloggers who are willing to write (hopefully) awesome stuff for their own crowd, and their soon-to-be crowd (recent graduates). If it has a niche, we could use it to cultivate the young testing community who likely don’t even know they exist. I know of two other community members my age. Hi Rebecca, Mel.

It would also let me create the “wolf” testing brand, a badge passed down to me when I first received the title.

Is this a good idea?

EDIT, 12/17/08: Followup here.

Wow. That title almost crosses the line.

I wrote the following at about 2:30 a.m. the other night so I wouldn’t forget it the next morning:

• A boundary is a theoretical division between two entities.
• All boundaries are theoretical. Those that mask themselves as physical can always be viewed more closely, to the point where the whole of the boundary is divided into sub-boundaries. Where there’s this division, there’s a theoretical boundary.

For instance:

Draw a line in the sand. The line is a physical boundary, right? Zoom in, as if with a camera, until the edges of line are outside of your field of view. What do you see now? Sand, right? Tiny pieces of sand. Each with its own boundary, distinct from the others. Zoom in more. Now you see a grain of sand. And even more. Atoms. And now, what boundaries are there?

Is it safe to say a physical boundary is really boundary of boundaries, that in itself is a boundary of boundaries? If not, then where do we draw the line (no pun intended)? To me, we draw that line when we make a theoretical division between the items that make up the boundary. At this point, we care less about what’s really physical — each piece of sand, each atom — and instead care about the theoretical: i.e., the line you shouldn’t cross. That’s the boundary.

Part of me now wants to replace the word “theoretical”, above, with the word “cognitive,” though I’m not sure the effect is much greater.

I have a feeling the basis for this view of boundaries is rooted in one of the major philosophies. Something like, “We can not properly understand the utility of a chair unless we recognize that the physical object is in fact a chair.” In other words: until we give that physical object boundaries, hence the theoretical.

Note: This probably isn’t an orignal thought. Recognition goes to the original attendees of WHET with whom these musings started.

Good news! The Association for Software Testing’s scholarship SIG has just released their first scholarship. They will be giving out money, free registration to next year’s CAST, and free memberships in AST to outstanding undergraduates who show excellence in software testing.

Are you an undergraduate? Do you know bright students who may be interested? We are currently taking applications and encourage all to apply. Deadline is November 30th!

http://scholarship.associationforsoftwaretesting.org

I’ll admit I could be reaching a little far on this one. Even so, I think the relationship is there.

I’m in Oregon new helping my dad recover from a broken hip. While chasing someone out of his backyard, he jumped a fence and broke his hip upon landing. Though the circumstances of me being home are less than ideal, I was able to gain some insight while driving with him.

We went to the doctor’s office. Dad had to get his sutures taken out — for those who don’t know, metal stitches — and he led me there turn by turn. I didn’t think at all about where I was going, he just told me the way.

A week or so later, we went again, this time for a prescription refill. Dad was fully prepared to lead me there again, but unexpectedly after a couple turns, he received a phone call from an important person. Because his focus was elsewhere, I was on my own.

What I realized from these two driving trips was how related memory and attention are to cognitive engagement. Because there was no need for me to pay attention the first time (Why should I? I had Geeves in the passenger seat.) I had trouble getting there the second time. I did end up at the right place, but I had to rack brain for the slightest amount of recall.

And here’s where the possibly far-reaching transfer comes in: Geeves represents a very detailed manual test script. I don’t think, I just do exactly what it says. Driving directions a la Google, however, are more like a checklist: With Google, I have to pay attention to all the idiosyncrasies of driving not needed when there’s someone else leading me. Questions like,  Have I gone too far? Have I not gone far enough? Where am I in relation to where I need to go? Did I make the right turn? — all unneeded questions when your only task is to “keep going straight until you’re told to turn again.” And again. And again. Now jump through the door.

Quick side note: A GPS device got me across country a year ago, although the only thing I remember is getting pulled over.

Author’s note: This post is wildly overdue.

I’ve been meaning to write this post for a while. I was thinking about how I’d write it — how creative I could be while introducing it — to the point where I never actually got to writing it. And you know what, ladies and gentleman? That’s simply atrocious, considering how absolutely awesome CAST 2008 was.

I enjoyed this CAST more than the other two previous CASTs. Though CAST 2007 sported a fun and enlightening certification debate, and CAST 2006 paved ground with an interesting but heated discussion after the first keynote, this CAST seemed different.

The biggest difference, I think, was that I wasn’t a student.

Rob Sabourin likes to talk about people going out in the world and being “blooded” after many years experience. I am by no means a blooded professional — I’m still getting dirt under my nails — but in the last year, I’ve gained a new appreciation for the “people” aspect of our industry. Whereas in college I focused on code, exams, homework and text books (to the greatest degree of perfection I had time for), in the real world I can focus on people.

At this CAST, I made an effort to talk to as many people as I could. Not only would I talk to them, but I did my best to find something interesting about what they had to say. Though I could have simply shied away or given into nervousness or not even cared, I met so many interesting people that I’d argue meeting people was the single best part of CAST.

Though the “people” aspect was likely the part of CAST I enjoyed the most, it definitely wasn’t everything. Here’s a few bullets that highlight my CAST experience:

• Getting on a plane with absolutely no sleep, making it to Toronto in good spirits and then exploring the city.
• Meeting people that I met at previous CASTs (shout out to Henrik, who was the first recognizable face I saw).
• Going to Jerry Weinberg’s tutorial, and meeting him for the first time.
• Being told I look Irish.
• Being told I look like Wolverine.
• Being given a staff badge by Paul Holland, making me feel as if I was part of the group (though I’m sure he just wanted to make me available to help ).
• Seeing Cem and Becky again.
• Going to a small Irish pub to see Michael Bolton & Nick Wolf play traditional Irish music.
• Getting tested by Ben Simo through his use of children’s toys.
• Seeing RobSab and his wife Anne’s presentation. (Absolutely beautiful, and even more beautiful that they can do it together.)
• Having a new analogy for manual test scripts that deals with diseased rats.
• Meeting the Dorset House Publishing people, who literally work right across the deck from The Open Planning Project in New York City.
• Being gently pushed to give a lightning talk. (Dawn, thank you for that.)
• Noticing as people took notes when I gave my lightning talk.
• Getting handshakes afterward when people told me it was a good lightning talk.
• Getting told that I could have a quarterly Tim-bits column in The AST Update (or another soon-to-be named AST magazine).
• Getting told by Scott Barber and others that I should publish a book of Tim-bits a few years down the road.
• Being told I look Irish, again.
• Being told I look like Wolverine — again.
• Going out to a pub with Michael Bolton and many others, and teaming up with Louise Perold for his bouncy-ball testing game.
• And finally, Hanging out with Carsten, Louise, Henrik, Ben and Chris during most of my CAST off-time.

And there’s more items I can list. Much more.

Overall, this CAST was a great experience, and I want to thank everyone who shared in that experience with me. Thank you, all.

This is gonna be a quick one, because, well… I gotta go spend my Loonies!

I’ll be in Toronto tomorrow for CAST 2008. For those that don’t know, CAST is the Association for Software Testing’s annual conference. On the docket this year is Jerry Weinberg, Cem Kaner, RobSab and many others. I’m excited.

Among the coolness of hanging out with Testing aficionados this week, I get to use the flight from NY to Toronto and back to further my testing history lesson. A few books mentioned to me finally made it to my doorstep, and the flight will give me a great time to read them. So much better than the subway.

What’s also coming out of the pipe (hopefully) soon is a personal project aiming to give a bit of stability to the crazy world of Javascript. I’ve spent the last year writing Javascript for The Open Planning Project, and after a bit of reflection, I feel like I, we, and the collective Javascript writers around the world are back in the relative stone age. Put bluntly and likely inappreciatively, Javascript is the C of browser languages. That’ll change soon, but in the interim — I’d guess four years before it reaches critical mass — we need a bit more stability.

Oh, and let me plug some Obama volunteerism real quick: If you’re interested, a couple volunteers and I are creating voter demographic maps using OpenLayers and Geoserver for Obama’s campaign in North Carolina. You can see a quick (and recent) hack-job here, though it will be password protected soon to accommodate sensitive data. If you’re interested in helping this mapping effort, or you know Obama campaign workers who could benefit from their own instance, feel free to join the OpenPlans project here.

And with that: CASTaways, I will see you tomorrow. Everyone else, goodnight!

I sent a small note to the software-testing Yahoo! group asking, “What are some iconic books in software testing that paint a good picture of its history?” I got a huge response, and figured it’d be beneficial to others to duplicate it here.

(I’d link to the thread if there was a public archive, but you must be a member of the software-testing list to see it. Email me personally if you’re interested in joining.)

The list:

• Weinberg, “Fundamentals of Computer Programming (1961)” (Read chapter on testing. Whoohoo! I got the last one!)
• Hetzel, “Program Test Methods (1972)” (Looks like I got the last of this one too!)
• Myers, “The Art of Software Testing (1979)” (This one’s in the mail; it looks like they’re out now, though I remember a different URL…)
• Beizer, “Software System Testing and Quality Assurance (1984)”
• Kaner, “Testing Computer Software, 1st Edition (1988)”
• Beizer, “Software Testing Techniques, 2nd Edition (1990)” (Was recommended the first edition as well, though can’t find info on it.)
• Marick, “The Craft of Software Testing: … (1994)”
• Beizer, “Black Box Testing: … (1995)”
• Schulmeyer, Mcmanus, “Handbook of Software Quality Assurance, 3rd Edition (1998)”
• Kaner, Falk, Nguyen, “Testing Computer Software, 2nd Edition (1999)”
• Kaner, Bach, Pettichord, “Lessons Learned in Software Testing (2001)”
• Weinberg, “An Introduction to General Systems Thinking (2001)” (This book was written much earlier, though it was republished in 2001. I’ve linked to the 2001 version since I can’t find information on the original version.)
• Jorgensen, “Software Testing: A Craftsman’s Approach (2002)”
• Copeland, “A Practitioner’s Guide to Test Case Design (2004)”

This is a daunting list. Some of these — wink, wink — I was supposed to read fully in college. I can’t honestly say I did that, so I’m going to go back to them now.

Just a note: I get the impression some of these books contain ideas that are “obselete” or “out of date,” and may not be directly helpful today. This is a history lesson, and I’m specifically interested in how the thoughts in the industry have changed.

Thanks all for the responses, and I hope the reading list is beneficial to others.

I am happy to announce that my organization, The Open Planning Project, has released version 1.0 of the Livable Streets Network.

The Livable Streets Network is a conglomeration of five websites: NY StreetsBlog, LA StreetsBlog, StreetFilms, StreetsWiki, and LivableStreet’s Groups. All together, they help urban planners and community members alike work together to make our city’s streets a better place to live.

Applause to all for a great run!

After two days of managing — though one day of actually focusing on it — I’m realizing that this time, I’m keeping my hands clean.

It’s different than before. Last time we did this, I kept a close watch of the people I was managing, had long and detailed debriefings, and coached as much as possible. This time, it’s more: “give them what they need up front, and let them go off on their own.”

I can’t say I have enough information as to which approach I like more — so I won’t even begin to hint as to which approach we should do — but I’m gaining some insight here.

Without long and detailed debriefings, I’m seeing:

• A higher bug-duplicate rate than before.
• A lower understanding (in my head) of what’s actually being found.
• Less drive on my part to jump the information hurdle.
• And more of a desire to let bug reports speak for themselves.

On the same token, I’m seeing greater personal drive from testers to self-manage, which could be a big plus.

Though there’s good and bad here, it’s important to note the context changes:

• I have all new testers (i.e., they haven’t worked with me on testing before).
• Reports that they write are going directly to the manager I was supposed to report to, meaning there’s no apparent need for any “high level” reporting.
• Managing is lower on my totem poll time-wise, as I’m only supposed to spend two days a week doing it.

Although it pains me, in general, to not be as involved as I’d like, the outcome of this could be very informative. In simple terms: I think we’re on our way to finding our sweet spot, and by the time this is all over, we’ll have some good insight to share.