I was testing a method that did some validation of a 2 character state. It’s legacy code, very few tests so I’m learning about how the code really works as I go along. I was writing a test for the following line:

else if (!BasicUtils.isState(state.trim()))

I wrote a test set the state property to “AA” and asserted that the validation failed. Problem was the validation passed and the test failed. OK, I found a weird defect. I took a bit of digging through layers until I got to the EJB layer where I found my answer:

stateValue.add("Armed Forces the Americas");
state.add("AA");

Turns out “AA” is a valid state code defined by the US Post Office.

When you do Agile development you really need good people otherwise things won’t work. And my answer is have you ever seen a waterfall project delivering good software by putting baboons on it and giving them bananas.

This average thing is completely wrong. To produce software you anyway need good developers no matter what. You choose whatever methodology you want you are not going to deliver anything.

— Giovanni Asproni

Scrum – Getting Started without Getting Burned

At the end of the day the best predictor of any project success is the people. Scrum can help good people work better, but you actually need the good people or you need to grow them.

We’re still using Fitnesse and its coming in quite handy for testing over 100 edits on some code we inherited. I still wonder how much it will catch on. Jeremey Miller has been thinking along the same lines:

Long term, all the testing gurus I know of seem to be driving towards scripting tests in Ruby and I’m thinking of moving in that direction in the future. I’ll still use Fit tests for set-based logic where it excels, but otherwise it just seems, I don’t know, clunky.

What do you guys think? Does Fit have a future, or is it just a little blip that’s never really going to take off?

I think FIT/Fitnesse gets a lot less use than your average JUnit framework, but the download numbers suggest Fitnesse is catching on:

• fitnesse20070619.zip 2551
• fitnesse20060719.zip 78608
• fitnesse20050731.zip 17551

The numbers for the 2006 version show some real promise. Hopefully the idea of automating acceptance tests is becoming a more widespread practice.

Every QA person uses a bug tracker. I had thought all our teams used bug trackers religiously. Turns out some of our QA people have adopted the idea that they should just walk over and talk to the developers and show them when they find a bug. Often those bugs get fixed quickly and never enter the bug tracker. If it’s going to be a significant effort to research and fix only then does it go into the bug tracker.

Another sign that our Agile adoption is taking a deeper hold. The point of QA is to improve the quality of the code. Fixing a bug when you find it is a better practice. Bug trackers can still be handy, but for a collocated team they’re less important.

It’s been about 7-8 months since we started to serious pilot Fitnesse on a project. Looks like its turning the corner. Instead of developers driving it, the QA staff are starting to build out acceptance tests and add scenarios. It’s coming in very handy for testing a huge number of edits based on a positional file format.

I still wonder if we’ll evolve to tools beyond Fitnesse, but it’s starting to prove it’s value.