Anthony Panozzo's Blog

OK, here's the plan. Anyone who wants to answer the following question with a comment is eligible for the prize. The winner will be chosen at random from valid, thoughtful answers starting on Tuesday evening. The prize will be your choice of:

• The Mythical Man-Month by Fred Brooks
• More Joel on Software by Joel Spolsky
• Peopleware by Tom DeMarco
• Rapid Development: Taming Wild Software Schedules by Steve McConnell
• Leaving one (and only one :) ) celebratory bragging comment saying that indeed, you are simultaneously a talented and lucky person

If you don't want to leave your full name, just make sure that I can get back to or identify you via the email you put down (which is not shown on the page.) I think this will be an interesting exercise to see where potential delays are and to start a dialog on where we can try to remove delays in our processes. The description talks about code, but your answers don't have to be limited to it.

I've recently been doing some ad-hoc testing at work, and it seems like my process could be improved somewhat. I'm tasked with testing a web application that I'm not exceedingly familiar with. At first, I am just going through the application with IE6 and trying out various functions or details and making sure that things look and behave appropriately with strange inputs. When I see something anomalous or a particular page that looks complicated or strangely laid out, I dig a little deeper and try to see what I can break. I figure that it's these sections that are the most likely to contain bugs. Taking screenshots of likely bugs has been helpful in entering them accurately into our bug tracking system and will hopefully avoid ambiguity in what I'm seeing for whoever tries to fix the bug, which will then require less communication overhead for me.

I heard Mike Kelly talk a bit about exploratory testing, and it seems like what I have recently been trying is similar to this technique. Essentially, exploratory testing is ad-hoc testing's bigger, more refined brother. Instead of just willy-nilly testing things, you have a designated goal and you create a plan that you try to stick to. When you see something interesting or have a clever thought on how to test that things are well done, you can venture off of the path for a bit and explore that idea. In this way, you can use your intuition as well as having a way to document and hold yourself accountable for the testing that you are doing.

Passing along some information from Mike Kelly regarding the 2009 schedule for the Indianapolis Workshops on Software Testing (IWST.) It's pretty short and dense, so I'll just copy from his blog (link no longer available):

We've posted the 2009 schedule for the Indianapolis Workshops on Software Testing. We're looking for people willing to share experience reports and people who just have a general interest in the various topics and would like to attend and ask questions.

Software development analogies are sometimes fun and potentially revealing. With that being said, I wanted to throw out a small nugget I thought of.

Growing up, I watched a fair amount of sitcoms until I realized the basic plot device. Essentially, something happens where a character on the show makes a choice, is worried about the ramifications of that choice, and is then somehow deceptive. They keep having larger and larger miscommunications and problems as the show goes on, and more problems (and hence hilarity), ensue due to keeping the problems under wraps. Eventually the characters realize the mistake, and the show ends with everyone having learned a valuable lesson.

• Note: I am not affiliated with any of the sitcoms mentioned below, nor do they support me financially. :)

Full House

At some point, I got pissed because I just thought "Why doesn't Stephanie just tell Danny Tanner that she wrecked the car instead of trying to hide it for like two more days? I'm pretty sure Danny's going to flip out and kick Comet and ground you, but at least you get it out in the open. There's definitely nothing to be gained from hiding it. Why would any rational person do this?"

A majority of open source projects have a paucity of documentation. However, they still have value as a working system. I argue that improving the documentation of a codebase intended for general use is one of the highest value activities that a developer can do. Although documentation may not be directly contributing to the codebase, the writer provides a valuable service by understanding the code and imparting that knowledge to others.

I would go so far as to say that there should be open source technical writers. They look for interesting projects to write basic documentation for. While there are a smattering of tutorials for certain frameworks, they are not condensed, are not authoritative, and are often misleading because of changes to the framework or convoluted examples. When the core developers move at the speed of the forum or even IRC, it's tough for a new person to have anywhere near that amount of knowledge. A centralized wiki with pertinent and up-to-date examples is quite useful.