Gojko Adzic

The next meeting of the UK agile testing user group is on the 3rd of August in central London. Here are the details of the talk:

Dan Leong on Clean Acceptance Tests

This presentation discusses how our agile team renewed our focus and understanding of our acceptance tests when the team members changed. Our group found some core shared values in the context of acceptance testing which we expressed in the style of the agile manifesto. We then looked at our existing tests to find bad test smells that we could learn from. The whole exercise was a good experience and we encourage you to try something similar in your teams.

Dan Leong is a team lead at Sky Network Services, where they have been using agile/XP techniques for over 4 years to deliver the company’s broadband and voice provisioning system. He has over 10+ experience working in companies ranging from small .com start-ups to global advertising and media companies. Like the rest of us, he’s trying to figure out how to do things better.

The event is free to attend, but up front registration is required. Register now

The Unite union (of the let’s screw BA travellers for several weeks every few months fame) created a
Facebook group to stop jobs in the technology department being outsourced and offshored at Guardian News Media Ltd, publisher of the Guardian, the Observer and guardian.co.uk. According to the group web site, the board of Guardian News Media is meeting tomorrow to make a decision on outsourcing a large part of their IT department.

Without taking a position on who’s right or wrong in this case, I’m very interested in how this whole thing is going to play out. A recent major rewrite of their flagship web site is one of the most publicised apparently successful IT projects in the UK. Continue Reading »

Creating an Executable Specification from existing manual test scripts might seem as a logical thing to do when starting out with Specification by Example and Agile Acceptance Testing. Such scripts already describe what the system does, and the testers are running them anyway, so automation will surely help. Not really — this is in fact one of the most common failure patterns. Continue Reading »

Why do people complaining that they can’t do agile development with 50 crap developers not see that the problem is in the second part of that statement, not the first? I got an e-mail last week that shows the point perfectly:

We discussed whether an agile approach is right, and I concluded that not everyone can work that way.

Quite true. I find it self-evident that not everyone can do software development, agile or any other way. That requires brains, knowledge, experience is a plus, and hopefully some talent as well. And of course, there is no generic approach that works in every context.

We think that an agile approach asks programmers to be much more engaged than when they’re just being served what to do

It’s hard for me to make a comparison to answer this. I’ve always tried to be very engaged in my own work and I expected the same from everyone else working with me, even before I ever did anything resembling agile. I’ve never seen a project where people were asked not to be engaged into what they need to do, but out of general principle I would refuse to participate in one.

If your programmers aren’t engaged and they get everything served to them, your problem is right there. It is not in a process, agile or non agile.

Which means the choice of people is very important

I completely agree. Once again, this isn’t particularly specific to agile software development approaches – or even software development at all. This is important for any craft. My former colleague Relja Jovic, who was the executive editor at PC World Yugoslavia when I worked there, used to say “From shit, you can only make a shit pie” whenever we were asked to get someone unqualified to write an article (“how hard can it be?”). That holds true for programming, testing, analysis, project management and anything else to do with delivering software. With crap people, you get crap output. Tough luck. Maybe hire people who know how to deliver software instead?

The long term benefits of agile acceptance testing come from live documentation – a description of the system functionality which is reliable, easily accessible and much easier to read and understand than the code. In order to be effective as live specification, acceptance tests have to be written in a way that enables others to pick them up months or even years later and easily understand what they do, why they are there and what they describe. Here are some simple heuristics that will help you measure and improve your tests to make them better as a live specification. Continue Reading »