A classic bottom-up approach to solving a problem. Partial test automation as a start to save time, then build on it. I’ve done it myself without even thinking of it as being a valid approach to use in any situation.

But, you’re very right that when a team is trying to catch up on all the tests they never automated before (pre-agile, I hope) then finding 20% of the tests that deliver the 80% of the value should also be that team’s goal. I haven’t seen Hexawise before but I checked out your site and the product seems very promising. Good luck with it.

Great post. I really liked Brian Marick’s suggestions in particular.

Two self-interested (but nevertheless very true) points:

1) An additional point to be considered is the importance of ensuring that the tests you’re running are achieving as much coverage as possible in as few tests as possible. Proven, scientific approaches (refinements on pairwise testing) to test design are now easier than ever to implement with tools like our Hexawise tool and/or James Bach’s AllPairs tool.

2) When it comes to automatically populating databases with data that has a broad mix of data ranges, data types, different combinations of multiple categories of data to be associated with an individual account, etc., the same considerations with point 1 are true. See Hexawise and/or AllPairs.

(Disclaimer: My firm created Hexawise).

Technical Debt, is something that is the stakeholders job to address at their discretion. Thats the whole point of the metaphor, and the basis of the solutions. There are times when the stakeholder would prefer a spike approach to meet business needs (you accrue TD, to meet immediate tactical business goals) vs consolidation where the team devotes more effort to servicing the technical debt (via refactoring and building up the test suite).

A stop the line approach undermines the whole concept of the ‘Debt’ metaphor. Its a bit barmy – deciding when to accrue or service debt, real or metaphorical, is always the responsibility of the wallet holder.

The problem with TD has not been with the fact that it is accrued, or serviced. Its problem has been with its visibility.

Tobias: I like the fact that you tag features/backlog items as being ‘tainted’ by TD. It adds much needed context – a stakeholder may prefer to route around tainted features rather than service them, but they will see it accruing. A responsible stake holder can then plan their maintenance periods around them.

Vinny Ly: The Ruby community are very advanced on acceptance level automated testing (i.e. automated testing for QA professionals and stakeholders), there are a lot of very powerful tools in this field, such as Watir, and Cucumber. IME Watir is most accessible to QA professionals (and is very well documented).

Mike: I am a recent convert to your blog, and its great stuff. Don’t know how I got referred to it (probably Lisa Crispin/Brian Marick on twitter). Great stuff.

They have a place where they have posted those annoying problems which they encounter but which they do not want to touch right away. Each time they find themselves touching this sore spot in the code, they tag the sticky with a dot. That way when they want to negotiate for a refactor or to reduce some technical debt they can easily identify what has been hurting them the most, most recently.

It’s a nice low tech way of tracking technical debt which translates into a BVC in the team room.