A Test Guy

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

• Zen and the Art of Motorcycle Maintenance
• I Heard the Owl Call My Name
• Never Cry Wolf

I read these books because they were required for one of my high school English classes. I suspect each has many lessons for testers, or at least stuff I can put forth as what I think would be a worthwhile lesson for a tester.

I’m not sure what I would do with A Tale of Two Cities, though.

I no longer have the corner office. Neither does my boss, so it’s ok.

We moved earlier this month into the reconfigured cube farm on the other side of the floor. I do have a window seat, and can see the bay without craning my neck. The little things are important.

The new guy started earlier this month. Now that I’ve got time to bring him up to speed, I can bring him up to speed. I’m glad the next two weeks have the potential to be quiet, so the world might not change too much while I’m explaining it.

Testing is a good idea. I believe in it. QA is a good idea. I believe in it, too. Testing and QA are so much easier to do, and provide so much more value, when the following things are managed well: people, process, and projects.

“Managed well” does not necessarily mean managed centrally. Nor does it exclude that possibility.

I now have a USB rocket launcher, and I know how to use it. This may relate to my comments about stuff being managed well.