A few years ago, I noticed that the majority of projects I finished had at least one of the following two characteristics:

1. They were broken down into small, unambiguously-finishable tasks
2. I paired while doing them

Stories, ATDD/BDD, pairing. These practices turn me into a “finisher”

Here’s a story that illustrates one way I have been of help:

One company asked me to complete a small set of interview programming puzzles. The first question involved writing a set of SQL queries and updates. The second, to take a set of csv files representing inventory and orders and report how much inventory was left after all the orders were filled.

Since I already had the environment set up, and mostly for amusement value, I implemented the solution to the second problem in SQL. (LOAD DATA LOCAL INFILE …)

SQL not being known for its ease of implementing exception processing, I did eventually switch to a scripting language. But I kept the SQL solution around, and showed it to a few of the folks in my network.

One of those folks, when we talked about this, had a bit of an “Aha!” moment. He said something like, “Wow! Maybe I don’t have to use [complex technology stack and various programming languages] to solve [problem involving loading and processing big chunks of data]. I could load the data into a database and run a much simpler set of SQL against it. Thanks Dave!”

This kind of thing happens a lot. As part of my work style, I learn things from and about the people and systems around me, and I share that learning with others. Often, what I share helps someone realize a new or better solution to a challenge they have been working on.

Bring me in, and let me help you learn what your organization already knows.

Fast-forward to today, where I was pointed at the wiki and the pages referencing ‘New Engineer’ and ‘New QA’ necessary information, giving the lead of my new group time to figure out what to do with me. (I’m in training for the next 3 weeks)

I can speed-skim with the best of them, and I noticed an interesting pattern. Clusters of last-modified dates.

Bunches of pages were updated in the past week. Another clump in the past 2 months. Then another cluster 6 months ago. More clusters at 2 years and 3.5 years in the past.

The clusters seem to be thematic, too. Almost like they correlate with starts of new approaches, or changes in approaches.

Hmmmm. Cultural archaeology can be such fun.

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”.

Other attendees included Dale Emery, Chris Sims, Jeffrey Frederick, Ken Pier, and Kevin Lawrence.

We chatted a bit about test automation philosophy, told war stories, and played with the tools.

I watched Elisabeth set up a RobotFramework test for some ATDD work she is doing with a new website. When she showed the “fixture” code and the interface capabilities of the tool, I was hooked. I’m going to write up some tests for the big-app-at-work next week.

Kevin Lawrence gave a demo of what he accomplished after 10 minutes of playing with CubicTest. It reminded me of the graphical workflow test for rails Brian Marick was working on.

Last night, I managed to get seleniumrc up and running on my MacBook, then this morning I got cubictest installed and running in eclipse. I think I’ll use it to write tests so I can refactor my ip address validator (the one with the interesting bug I’m keeping in, but the annoying bugs I want to fix).

Finally, Elisabeth shared a pointer to UISpec4J as a good unit test library for Swing.

Lots of other tool goodness happened, too.

Thanks again, Elisabeth, for calling and hosting the event.

Does the application under test rely on a large central database?

If so, is that large central database backed up on a regular basis?

If so, can you get access to the backup files?

For some testing tasks, it might be easier to just load a new database instance from those backups than to create and populate a database from scratch.

In one case, we dropped, truncated, and pruned a number of tables from the backup, then created a new backup file. A much smaller backup file. One that loaded in one hour instead of many hours.

• I like to know what I am doing, and why I am doing it. (mindfulness)
• I like to know what we are doing, and why we are doing it.
• I like to know what we did, and why we did it.
• I like feedback. Fast feedback, and close feedback.
• I like creating affordances.
• I like precision and accuracy.
• I like to tell my audience when I am compromising precision or accuracy in order to better reach another goal.
• I like people who are hungry to learn. (they make me a better teacher)
• I like french vanilla ice cream.

• I’m evaluating it as a self-study guide for a co-worker who wants to learn java.
• While I’ve read plenty of java, and made small modifications to existing java programs, I’ve never written a major java program from scratch, nor have I ever set out to systematically learn java. So I’m learning java. yay!
• While I’ve written plenty of tests, and I’ve modified some existing tests, and I’ve written tests before I’ve written code, I’ve never written a major program using xunit-style tests and doing TDD. So I’m learning TDD. yay!
• I’m also taking the opportunity to immerse myself in eclipse and intellij

I’ve had some interesting experiences (thoughts and feelings) doing this, and I’ll write up some details in separate posts.

I just finished lesson 12. Earlier, I wrote the following in my notes:

I’ve gotten through the end of lesson 6, and I’m very impressed. I feel confident that I can recommend this book to my coworker, and he’ll be better off going through it than not.

I’ve been using eclipse more than intellij for lessons 5 and 6, and I’m steadily becomeing more comfortable with it.

I found and installed the EclEmma plug-in, and very much like using code coverage to identify code I can delete after some refactoring. And I’m duly impressed that I get 100% code coverage when I run my tests*

*actually, almost 100%. the gaps are things like assertTrue not being called with a false condition (duh), never calling the constructor of a utility class, and not testing the default methods for enums. I can live with that, for now.

One thing I did not expect was that my brain felt like it filled up and overflowed, and I kept forgetting what I was doing, as I got towards the end of the lesson 6 exercises.

more on that last bit soon.

In the Navy, when they have a “bad ship”, they disperse all of the crew throughout the fleet, then assemble a completely new crew and try again.

Applying this lesson in our context – if you have a “bad team”, break it up and assign the team members to other teams. Then staff the project with a new team and try again.

Just like breaking up a great team and assigning the members to other teams won’t necessarily turn those other teams into great teams, doing so with a bad team won’t necessarily turn the other teams into bad teams.

This lesson is not license to turn your brain off. Bad team != bad people, and sometimes there are people who would find a better fit at some other company or pursuing some other career.