We use Exactor to automate acceptance/regression testing for our web application. This is fine for most things, but once we started introducing DHTML and AJAX features, we found that Exactor (or more specifically the version of JWebUnit that it uses behind the scenes) couldn’t handle testing them.
The obvious candidate for testing these enhanced features was Selenium, which uses a real browser to perform its tests. We wanted to stick with Exactor though, for a few reasons:
An excellent post on Kill the Meeting, pointing out the insane amount of bureaucracy you end up with when writing code is treated as an unskilled production line activity.
On one recent project, the software development managers insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.
The code in question? Five lines of SQL.
Yes, a 2-hour project took over a month.
Some of that sounds horribly familiar from past projects. What’s the betting that the people writing and reviewing the documents could have written the code themselves in a fraction of the time they spend ‘saving money’ by contracting the work out, if only writing code wasn’t treated as a menial task to be discarded on promotion?
One issue with the conclusion though:
Unfortunately for me, I don’t think this is a process I can change here. It turns out that outsourcing development to India is so much cheaper that even if it takes four times as long, it’s still a net savings.
Even pretending that the offshore developers were free, that only holds true if the time spent in-house doing all the design, documentation and reviews was no more than eight hours, which sounds unlikely. To my mind, outsourcing software development to release your own people for ‘higher value’ work only costs in if you outsource the lot, from requirements to delivery. Otherwise you end up employing the same number of people just to keep the cheap developers on the right track.
Hot on the heels of the presentation for ‘best overall application of the agile manifesto’, we’ve just heard that we won ‘best overall application of the agile values’ for quarter two. BT’s agile values, incidentally, are the same as the values of of XP, ie communication, simplicity, feedback, courage and respect.
We had a team trip down to London yesterday to pick up our BT agile award for ‘best overall application of the agile manifesto’. We got a certificate each, a trophy for the team and a card signed by the top bods in BT’s IT division.
A colleague recently posted (on an internal wiki, so unfortunately I can’t link to it) about the problem of people thinking that common agile “tools” such as whiteboards, index cards, freehand burndown graphs etc are a bit “Blue Peter,” and therefore not professional. He made a good suggestion, which was that you provide teams that are new to agile with official branded materials (story cards, pre-printed blank burndown charts and so on). They will accept these more readily, and will then embrace the underlying ideas and start using any old flipchart or whiteboard.
Here’s another argument for simplicity – admittedly from the world of TV fiction – which I’d put to people who think low-tech solutions are somehow not fit for purpose.
The Dharma Initiative hatch clock reproduces the countdown clock from the second season of Lost, complete with sound effects and a terminal to type the numbers into to reset it. For the full experience, you can even set it to disable system sleep, so you really do have to “press the button” every 108 minutes (although as far as I can tell it doesn’t actually do anything dreadful if you let it run down!)
Utterly pointless, but nicely implemented and strangely compelling.
[Update] It does become slightly less compelling when you accidentally shut a cat in the room, it walks over the keyboard waking the machine from sleep, and you get woken at 4.30 AM by the “one minute to go” klaxon.
I’ve just come across an old Agile Chronicles post about burndown patterns, which makes the following observation:
Flat-line (i.e., zero net progress) – a flat-lined burndown chart may have a number of explanations:
- The team may have been pulled to work on other projects or priorities (i.e., another project, support and maintenance) and has left the current project helpless to succeed.
- The team may be completing work at an expected rate, but new features and/or tasks are being added to the iteration or project as fast as work is being done.
- Defects and rework may be preventing real progress from being made.
We looked a while ago on our project at how to make at least the second of those possibilities explicit on the graph, and came up with a simple solution, which I thought I’d share here. I’m sure it’s not original, but it doesn’t appear to be all that common either, so someone might find it useful.
Some people tend to raise their eyebrows a little when people talk about agile software development being more “fun”, and question whether something you’re paid to do can, or should, be fun.
I’m a convert to Behavior-Driven Development, or BDD, as championed by people like Dan North and Dave Astels. As a first step, I wanted to be able to generate a report from an existing collection of JUnit tests which read more like a set of specs (this would be in addition to the normal success/fail/error report), which would in turn be an encouragement to think in terms of behaviour specification when writing tests for new functionality.
To begin with, TestDox looked like just the job. Unfortunately, when I tried it I came across a few things that weren’t quite perfect for my situation:
I like low-tech prototyping solutions, and here’s a simple (some might say trivial) one that worked well at a recent release planning meeting, for discussing some minor GUI changes with the users.