Thursday, September 27, 2007

actual code: create vs. sort

Grig and Simon are both still suspicious, so here is an example from the test itself:

This is Selenium RC in a keyword-driven framework where test data is in the wiki. Take a look at the "code" below and I hope you agree that an explicit test for creating a record is not worthwhile.

Any of these could fail in the setup, even though there is no explicit assertion about success:

| clickAndWait | link=Accounts | |
| type | name | 0sort1account%%start_time%% |
| st-submit | | |
| clickAndWait | link=Accounts | |
| type | name | 0sort2account%%start_time%% |
| st-submit | | |
| clickAndWait | link=Accounts | |
| type | name | 0sort3account%%start_time%% |
| st-submit | | |

and even if those didn't trigger a failure, these other assertions about sorting would fail in a really obvious way if any of the three records were missing:

| open | /nlw/control/account | |
| text_like | qr/sort1account.+sort2account.+sort3account/ | |
| clickAndWait | link=Name | |
| text_like | qr/sort3account.+sort2account.+sort1account/ | | |
| clickAndWait | link=Number of Workspaces | |
| text_like | qr/sort1account.+sort2account.+sort3account/ | |
| clickAndWait | link=Number of Workspaces | |
| text_like | qr/sort3account.+sort2account.+sort1account/ | | |
| clickAndWait | link=Number of Users | |
| text_like | qr/sort3account.+sort2account.+sort1account/ | |
| clickAndWait | link=Number of Users | |
| text_like | qr/sort1account.+sort2account.+sort3account/ | |

Wednesday, September 26, 2007

don't test for blocking conditions: an example

Matt Heusser quoted me on this at the Google Test Automation Conference. I've had this idea for some time, that many tests both manual and automated waste time explicitly testing for conditions that don't need tests.

I ran into one of those today. Or rather, my boss did. (He's not really a boss so much as he is an experienced colleague who has more conversations with management than me. Socialtext has very little hierarchy. )

We have a lot of automated tests that we created very quickly. Many of them have TODOs left over. I've been cleaning up the tests and implementing the TODOs.

One of the tests had a whole list of TODOs that had already been done, so I deleted the TODO list. My boss saw this and asked me why. In particular, one of the TODOs had been to create a record of a particular type, and my boss didn't see a test for this.

I pointed out that I had written an explicit test for sorting records of exactly that type, and three records of that type were created in the setup for the sorting test.

Had the record-creation failed, the tests for sorting would have failed. It's a nice economy of effort.

Friday, September 21, 2007

sysadmin week in QA

Go on, click the link, read the blog post, then read the source. Socialtext's REST API is pretty great.


Wednesday, September 19, 2007

Luke Closs/Distributed Agile/Agile Vancouver

If you're near Vancouver, you should be there.

I'm interested in what Luke's going to say, and I work with him.

Wednesday, September 12, 2007

Joe Zawinul

Joe Zawinul died today. He was 75. He wrote "In a Silent Way", and one of my favorites "Mercy Mercy Mercy" (hard to find an original version on teh internets), a hit for Cannonball Adderly.

He played in Miles' Bitches Brew band. He founded Weather Report and dealt with Jaco.

Bring on the artists.

Sunday, September 09, 2007

Become a better software artist

There's been an interesting discussion on the software-testing mail list about the failures of Six Sigma and other process-quality religions to map effectively to software development. I think you might get better software the same way that you get better music.

Practice.

Almost every musician starts by playing along with recordings. After that, playing along with the radio builds improvisation skills. After that, playing along with other people broadens and deepens the communication spectrum. Throughout all this, work on the basics like scales and chords and tempo don't stop. The conscientious musician practices as many styles of music as possible. The professional musician may not enjoy blues, or orchestral works, or jazz, but there are certain forms that all professionals master in order simply to be professional.

Rehearse.

Music is constructed for listeners. Rehearsal is where the details of the performance are designed and implemented. Rehearsal is not where musicians improve their skills; it is where musicians, together, plan to present their work to an important audience.

Perform.

Real artists perform. They create music for real listeners, who pay for the privilege of doing so.

Trying to apply Six Sigma or Lean or CMM in order to get better musical performance doesn't seem very smart. But humans have been performing music for our entire time on the planet. We know pretty well how to go about getting good performances. If it's software:

Practice.

Work the exercises in the books. Then make up your own exercises, or look for interesting questions. (My first serious program was to throw the I Ching in Perl, using the instructions from the back of the Wilhelm/Baynes translations as an algorithm. The script also calculated the changing lines, and printed both hexagrams to the console. I learned a lot.) Learn the basics, and keep expanding: conditionals, loops, objects, design patterns. Learn other languages, even if you don't like them much. (I've started Head First Java 3 times, I'm slack.)

Rehearse.

Share your programs, work with others to improve theirs. Publish your code as a demonstration or a work in progress. Get feedback, and read and comment on others' work. Join an open source project. Or a couple of them. Write documentation-- if you can't write it down clearly, then you don't understand it well enough.

Perform.

Real artists ship. -Steve Jobs
Make stuff for users. As often as you can. All kinds of users, all kinds of products.