My friend Per Otto Bergum Christensen has created a great too for agile software developers called BDoc. The purpose of the tool is to generate documentation from your unit test code which is linked to requirements in your user stories. This is one of the reoccurring problems I have experienced in agile projects and BDoc is a step in the right direction.

BDoc generates documentation from the test code in a natural language which anyone can read, with a link to the user story. This enables the customer or other non-technical personnel to see whether the requirements in the user stories are fulfilled or whether there are still some pieces missing. This solves one of the issues frequently encountered in agile software projects with user stories becoming outdated and out of sync with what developers are creating.

There is a great article up on The Server Side which gives a great overview of how BDoc works. If you understand Norwegian you can see his talk about BDoc at the agile conference Smidig 2008 in Oslo, Norway.

October 22nd, 2008 | work | No comments

The other day I read an interesting posting on the Object Mentor blog called Observations on Test-Driving User Interfaces by Dean Wampler. He makes quite a few good points as to why applying TDD to rich internett application user interfaces is very hard. There are two reasons why TDD is not being performed when building user interfaces:

• a wrong perspecktive on the purpose of testing
• lack of good tool support with the correct perspecktive on testing

The purpose of testing

Most developers and test tool makers have a perspective of testing as an exercise where the object is to find defects. This is a perspective on things which led us to where we where a couple of years ago. With the introduction og eXtreme Programming and agile methods the perspective developers had on testing changed. Testing became an exercise which purpose was to prevent defects from entering your code base.

Testing as a way of preventing defects is a view shared by Lean Software Development and Mary Popendieck goes into details about this in her book Implementing Lean Software Development: From Concept To Cash. If you fail to convince your developers that this is the purpose of testing, I think you are going to fail at successfully working test driven. Testing to prevent defects is something which comes natural for interface developers as we have always been forced to continuously test our applications in numerous browsers while writing code. If this comes natural, how come test driven interface development is so hard?

The Tools

I agree with some of Dean Wampler’s points and I do think that lack of good tools might be part of the reason why test driving user interface development is hard. However I think the reason why the tool are inadequate is that they are created by people who don’t know enough or care enough about their target audience (to all of you who have written tools I apologize, but this is what it looks like from my point of view. If you are offended, just let me know and we can settle it off line). The tools for testing user interfaces tend to be intrusive, expensive and just too complicated to use.

Monster tools like Quick Test Pro are so complex (just installing this monster is a pain) that they exclude some users. Not to mention the ridiculous price tag on this software. However these things aside the tool itself is just not good enough to make it worth while for the people actually implementing the user interface. They do not want a tool where you write some code in some macro- or script language. They do not want a 3 GB tool to install with a limited number of licenses.

What they do want is a simple, free and easy tool to help them work faster and with better quality. A testing tool which not only helps in finding defects, but a tool which prevent defects from entering their code. A tool which is none intrusive and can be used while writing code.

This is where most tools get it wrong too. They are tools created to finding defects and errors in an application. Usually you record a test script and then run that script later on in order to find defects. What these kinds of tools fails to do is to give developers a way of working which prevent defects from entering their application.

One shining star

During my time as an interface developer I have only found one tool which actually allow you to work Test Driven and which enables the developer to work with preventing defects. The tool in question in is the free tool Selenium.

What makes Selenium so great is that it through it’s Selenium IDE provides developers with an actual tool which enables you to work test driven. By using the default view you can easily create simple test fixtures up front before coding and then run the test until the test passes. The Selenium IDE is a Firefox add on and hence fits naturaly into a user interface developers portfolio of tools. It’s small, portable and available on all platforms.

The way forward

I think the future for test driven interface development is very promising. Iterating and continuously testing is something which is in the blood of all experienced interface developers and I am certain that tool vendors will be capable of building tools which encourage test driven interface development.

June 27th, 2008 | work | 2 comments