A Test Guy

Inspired by a tweet from “utahkay” where she stated

Organizations that still use the term “test plan” don’t get it yet.

Maybe call them “done plans” since they help us determine when something is done.

As an aside, I’m finding twitter an attractive outlet for writing.

a quick, partial list of stuff I’ve installed, and use, on my mac:

• Aquamacs emacs
• Backdrop/MenuShade/Mousepose 2 (for screen casts)
• Carbon Copy Cloner
• Chicken of the VNC
• Colloquy/Snak/Adium (IM/IRC stuff - take your pick)
• Firefox 2
• Firefox 3
• Gizmo
• Growl
• iStat Menus (iSlayer.com)
• iTerm
• JungleDisk
• Minuteur
• NeoOffice
• Nocturne
• Parallels
• Plot (http://plot.micw.eu)
• Quicksilver
• Remote Desktop Connection
• Skype
• Spamsieve
• SSH Agent
• Twitterrific
• VLC

From Brian Marick, on the agile-testing list:

Simon Baker’s written a nice short summary of testing in his Agile project. It pretty much captures my biases. (That’s what “nice” means.)

link

I am inspired by a recent blog entry by Ben Simo.

To me, software testing is what happens when someone asks me to tell them something about some software system. They might ask me to find problems or bugs. They might ask me if I think the system is any good. They might ask me if I think it is fit for use in a particular situation. They might ask me if the system meets a set of requirements.

I really like it when they make my job challenging. It’s no fun to find lots of bugs or lots of missed requirements very quickly and very easily, or to discover that adding the third client session locks up the server. Instead, I’d much rather have to work harder and smarter to reveal useful, previously unknown information to the person who is asking.

I can use software tools to help investigate software systems, and I can help others use software tools, like automated tests and executable specifications, to help them do their jobs better.

But I don’t know how to help someone answer the question “Tell me something about this system that I should know, but didn’t know that I should ask” by using a tool. Answering that kind of question needs a tester.

Answering that kind of question needs me.

There is no subtle way to carry a hula hoop on public transportation.

I got the purple one.

I was reading Reader’s Digest, and noticed a quote attributed to Brendan Fraser:

Everybody has bad hair decades.

I’ve accepted that 2000-2009 is mine.

Other ideas I’ve had to work at accepting in the past include

• Not everybody is as passionate about work stuff as I am
  • some are more
  • some are less
  • some are passionate about different aspects of work
• This is ok
• Sometimes I should slow down because I’m not giving people enough time to learn what I’m doing
• Sometimes I should not slow down because going fast is a good example to set
• Sometimes I know which one applies for a given situation
• No email reply is so urgent that I should send it without review and at least 5 minutes reflection on how the recipients might interpret it.

Well, that takes care of one counter-example. What other exceptions can you think of?

Jonathan Kohl is right. Often.

I suspect when he’s not right, he’s wrong. Which is a good thing.

First thought:

One of the software development teams I work with has been using xp-style iteration planning and velocity measuring, with cards and points and walls and such.

I was standing in front of the wall, talking with one of the coaches, when the following dawned on me:

I can tell a product owner that by investing x points into making legacy code more maintainable, the team could subtract 1 point from the estimate on each of the cards for stories in that code area.

So if there are, or will be, more than x cards of that type, then it might be worth it to invest the time to improve the code.

Second thought:

Corey Ladas posted:

There are no a priori best practices

There are only the practices you are using now.

And practices that are better than the ones you are using now.

I’m always impressed by the simple revelations.

Testing. What do you mean by testing, or tests, or testers . . .

With a hat tip to George Dinwiddie and a post of his on the agile-testing mailing list, I have a few more context-establishing questions:

• Am I testing in the context of building something, or in the context of evaluating something that has been built
• Am I testing something I am building or have built, or something you are building or have built
• Am I testing something we are building or have built, or something they are building or have built