A test guy

snuffleupabug – a bug that is ignored because you think the reporter (who you consider less sophisticated than you) is making it up.

In a recent post, I mentioned that I was planning on writing a test in CubicTest to help refactor an IP address validator web page.

I finished the test, and fixed the script. My overall impression is that CubicTest is fairly straightforward, and I have not yet used it to its strengths. I still want to play with subtests, test suites, and custom test steps.

Now for the pictures:

The IP Validator looks like this:

IP Address Validator, initial view

When you enter a possible IP address and click the button, the server-side script returns a nifty table with the result:

Validator after entering a good address

Unfortunately, there was a bug in the script. After the third address checked, the display looked like this:

Validator showing display bug

That bug is not the interesting bug I wanted to keep. Here’s the quick test I came up with, using the CubicTest plugin:

Test for validator

During the test development, I added id attributes to the result table elements. That made the common contexts much easier to specify. And I had a few go rounds with eclipse editor weirdness switching the sense of the last check from “text on the page” to “text not on the page”.

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.