Workroom Productions

The Irrational Tester - video and new version of paper

2009-12-13T22:46:00.002Z

Here is version 1.06 of my paper "The Irrational Tester". SQE have kindly posted a video of (one version of) the talk that goes with it; keynote at STARWest 2009.

TestLab stuff coming soon...

TestLab Followup - not yet...

2009-12-09T23:57:00.000Z

Bart Knaack and I ran the "TestLab" at EuroSTAR. I've got lots to write about it - but unfortunately (or fortunately) I came back to an unexpected job in the UK. I'll post conclusions, bugs, pictures and more in a day or two. I've not yet submitted the bugs to OpenEMR, either. It will all happen, but not immediately!

For now, read Michael Bolton's blog postings Bravo! and Best Bug, or Rikard Edgren's Notes.

Cheers -

James

Oh for goodness sake

2009-10-11T23:14:00.002+01:00

The estimable Association for Software Testing isn't exactly approachable via Google, is it?

As it happens, it's reasonable on Bing.

The AST is an association for testers, run by testers. Perhaps it works on their machine.

I shouldn't be so sarky. I've sponsored their conference before now, in 2006 and 2008. I recommend you go.

(now, let's see if my journal-to-blog tool manages picture attachments properly. Expect to see an edit if it's still bust.)

Exploratory Testers - London 3 July - Prince Arthur, Euston.

2009-06-29T23:01:00.000+01:00

As you may know from a previous posting, Michael Bolton and I are going to bring the participants of our separate Exploratory Testing / Rapid Testing classes together, after our classes finish on Friday evening. Please join us!

Date: Friday 3 July, from 5:30 pm
Place: The Prince Arthur pub, near Euston station. Reviews from Beer in the Evening and Fancy a Pint. Here's Google streetview, which should help you get there. Being just next to Euston, it's good for tubes, trains, bicycles and other rational London transport.

I think this is a remarkable opportunity – I hope to see you there!

Cheers - James

London, 3 July – Exploratory testers in a pub

2009-06-18T11:42:00.000+01:00

Tentative plan: Michael Bolton and I are (separately) teaching in London in July. Our courses, mine on Exploratory Testing, his on Rapid Testing, end on the same day. We've talked about bringing the participants together in a London pub at the end of the course. Yesterday, at the SIGiST, we slipped into an announcement.

We don't yet have a pub set, and one or both classes will have to travel (my course is in the City, Mike's is in Westminster). We hope that we will have an enthusiastic, engaged, but not-too-exhausted group of exploratory/rapid testers, and that by bringing the participants in our classes together, we'll all have a lovely time, and learn some stuff.

Details will be posted closer to time, but are, so far: A group of exploratory testers will be meeting in London sometime in the early evening of Friday 3 July. It will be a unique event. Please join us.

PS - a few places are still available on my course. Details here, book here.

More testers in a pub

2009-06-16T00:29:00.000+01:00

If you're interested in testing and based in London, you'll want to be in the Washington pub in Belsize Park tomorrow (Tuesday) night.

http://blogs.imeta.co.uk/RLambert/archive/2009/05/19/the-testing-revolutions-first-meeting-london-tuesday-16th.aspx

The Wash is, funnily enough, only 15 minutes wobbly walk from the LEWT pub (and five minutes by steely steed from Workroom Towers). However, you'll have to tell me all about it – one of my other lives has precedence tomorrow pm. Have a lovely time.

Designing Experiential Exercises

2009-06-03T18:08:00.003+01:00

Readers of this blog may already know that I prefer to learn/teach by doing. If your preferences match mine, you'll be interested to know that Jerry Weinberg and Esther Derby are running a public workshop in Albuquerque on the Design of Experiential Training, from June 22-25 (or 26, depending on which web page you read). Details from Jerry, from Esther.

Jerry is, in addition to his other stuff, the master of the experiential exercise. Or so the people I trust tell me. I'm hugely excited to be going to the workshop. Heaven knows why I've not mentioned it here before. Anyway: I'll be in Albuquerque for midsummer, doing fun stuff.

Have I mentioned my class? Getting a Grip on Exploratory Testing, in London. 2-3 July? Looking forward to that, too. It's all very hands-on and participative – and I imagine I'll still be full of the joys of ideas, and just past my Albuquerque jetlag.

Busses and Exploratory Testing classes

2009-05-28T09:11:00.000+01:00

You wait for ages, then two turn up at once.

I'm running my course in Exploratory Testing in London on 2-3 July. Details here. This is the course I've taught at Nokia, Google and around the world. It is a limited size, practical, hands-on class, and it is all about testing – specifically, how to uncover problems in working systems in a disciplined and efficient manner. I really enjoy teaching this class; lots of lightbulb-on moments for all.

To our mutual frustration, my colleague Michael Bolton is teaching 'Rapid Software Testing' at the same time, also in London. It's a great class, too. The scheduling problem is ours - but the choice is yours!

There's more to say here, but I've got a lovely on-site hands-on testing gig until the end of the week, and the daily stand-up happens in 35 minutes, at the other end of a 30-minute tube ride. Scrums wait for no man, or, at least, no tester...

Best Paper at STAREast

2009-05-10T22:01:00.002+01:00

I'm pleased to announce that The Irrational Tester won "Best Paper" at STAREast. * ** ***

The paper is currently at version 1.0. I'm adding stuff (and sorting out the prose) for version 1.1. Please read it - if you've got any comments, I'd be very interested to hear them.

* The presentation got 9.something out of 10, too.
** In 2002, my paper Adventures in Session-Based Testing (written with Niel vanEeden) won "Best Paper" at STARWest and at EuroSTAR.
*** Three Best Paper prizes! Three! Wahey! ... shutting up now ...

London Exploratory Testing, 2-3 July 2009

2009-04-28T13:15:00.000+01:00

Getting a Grip on Exploratory Testing will happen in London, on 2-3 July.

We're at the lovely Royal Statistical Society, near the Barbican, just north of the City.

I've kept close to last year's prices, and even managed a small reduction (you get a buffet lunch in 2009...), so it's £630+VAT. There's an early-bird discount, so if you book and pay before June 8th, you'll get 10% off (£567+VAT). Email me to register, or get into the online registration here: Online registration

This is the course I teach at corporate clients (recently Google and Nokia). It's very hands-on, with exercises and discussions driving the workshop. You'll discover:

The test design skills to probe a system and trigger a bug
The analysis skills to model the system and understand a bug
The discipline to manage your exploration and sustain your bug rate

Exploratory testing is a disciplined approach used to uncover risks and surprises in real systems. It's a great complement to the massive confirmatory testing found on agile projects, and a necessary skill for agile testers, and for any other tester who needs to do more than simply verify that a system is working as expected. Test managers find this course useful for reconnecting with their test skills, and for understanding the challenges of effectively managing a team that is making good use of ET.

Help me work out when to run the next Exploratory Testing class in the UK.

2009-03-24T17:50:00.000Z

I tend to run an Exploratory Testing course in London once or twice a year. A bunch of people have recently asked me when the next one would be.

Rather than set a date and see who can come, I thought it might be better to gather suggestions for dates. I've set up a survey to help you tell me, and I'm giving contributors a discount. It's a two-minute job, if that. Click here to help.

Note - if you're in mainland Europe, I'll be running a class in Berlin, June 4-5. Details in the most recent Testing Experience.

Cheers - James

Firehose

2009-03-21T18:33:00.001Z

Gotta love* Safari Books Online.

Every book I was about to buy this afternoon, I find I already have**. It's not the first time, either.

No*** Kaner, no Bach, no Whittaker, no Weinberg, so I still need my library. But for everything else**** – from visualising data to Ableton Live, from Python to a guidebook for a 2-versions-old iDVD, there's Safari.

* I agree that it has a frustrating interface, clunky search, single-source issues, is slow for page-flipping, and the 'tokens' make me cross - but I can read those books right now. And there's no new money to find. And I can search. And copy/paste.
** Or, rather, have access to, while I'm online, while my subs continue, and while the service yet lives.
*** I understand the reasons for all these authors not being on SBO, but pure-testing books are generally under-represented. Use this to see the books in the Testing and Debugging section.
**** Of a technical bent.

Funny bug

2009-03-09T01:01:00.001Z

Facebook. Hardly unusual, but made me smile.

Just back from Amsterdam and Copenhagen; enjoyable classes, nice feedback, new contacts. Took the train from A to C - lovely.

Common programming errors (in the news recently)

2009-01-14T12:11:00.000Z

Seen this? 25 Dangerous Programming Errors

It's from SANS, a training provider. I've removed the words "Top" and "Most" to reduce unnecessary hyperbole.

It's culled from this: MITRE's Common Weakness Enumeration. Interesting stuff.

I don't have an opinion on it, yet - but I'd be interested to know who, in the software testing community, does. Answers on a postcard, please. Or a comment here, if it's easier.

XPDay

2008-12-05T00:28:00.000Z

I'm going to XPDay!

Wahey!

Coders, Unit Tests, and Testers

2008-11-28T19:00:00.000Z

On the QAGuild group on LinkedIn, Prasad Narayan asked "Does the Dev team in your organization indulge in Unit Testing? I would appreciate some details, if the answer is in the affirmative.".

Here's my response:

I've worked in plenty of teams where the coders have written unit tests. Typically at organisations which explicitly care about coding. Less so at banks, service or entertainment organisations. On a reasonable proportion, and most especially on agile teams, the coders have written very large numbers of unit tests that act as a scaffold to the code (that is, very large as compared to the expectations of teams that don't use unit tests, so perhaps this is tautological) . More than a simple framework, the tests also act as a way to frame thinking about the code, to consider it before it is made, and to experiment with it when it is under construction.

Such teams are (in my experience) universally proud of their unit tests, and actively show them off. Their code tends to be better, too. When I've worked with teams who are shy of showing me their unit tests, and shy of letting me review them, then (in my experience) the code is universally duff. I'd rather work in a team that has no unit tests than a team that says it does, but won't show me (as a project member who is interested in testing) the tests.

I have worked with teams that write unit tests, but don't run them. This sounds bizarre, but tends to be a problem that creeps up on teams. I've seen it as a result of commenting out unit tests that break because of a non-code-related change (without replacing the test). Be aware also of unit tests that don't test anything important, or which pass with or without the code in place. I have heard of (but not worked on) teams where the testers wrote all the unit tests, and the coders wrote the code. I guess I'd hope that the two groups work closely enough that tests and code could be written together.

It's all to easy to let good unit testing and the resultant relatively-clean code lull one into a false sense of security about the viability of the system as a whole. If I work with a team that is using lots of unit tests, I (very broadly) take this approach:

reviewing the existing unit tests

being sure they're run regularly

trying not to duplicate them too much with my own / the customer's / other team's confirmatory scripted tests

using exploratory / experimental / diagnostic approaches to pick up and dig into all those unexpected risks and surprises

working closely with the coders to enhance, streamline, and otherwise improve their unit tests

Exploration

2008-11-24T11:57:00.000Z

"Do not go where the path may lead; go instead where there is no path and leave a trail"
Ralph Waldo Emerson

Can you start using Exploratory Testing without needing an expert?

2008-11-22T12:29:00.000Z

On Software Testing Club, Anna Baik asked "Can you *bootstrap* your team into using a more exploratory testing approach without needing in-house expertise? Or are you likely to have problems unless you have either a consultant or an already experienced exploratory tester on staff?", which struck me as a reasonable question. Here's my answer (also posted as a reply on Anna's blog, mostly).

You can do exploratory testing without an experienced exploratory tester. Indeed, that's what all exploratory testers do with a new system / technology / customer etc.; start from a position of ignorance and get exploring.

There are a couple of ideas that I'd recommend keeping in mind:

one of the things you'll be doing is gaining experience, and (through reflection) expertise. This is part of all exploration, but it's particularly true when getting going on something new. Expertise will help you find more/better information – and you'll find fewer/poorer without expertise – but it takes time to build. However useful it is, it is neither necessary, nor sufficient, and even expert teams explore better with a newbie in the numbers. This is because...
if a few of you are exploring, there will be great diversity in your approaches. Learn from each other - and try to take those lessons in a way that doesn't flatten that diversity.

With those thoughts, here are a couple of recipes. Adapt as you see fit. For both, you'll need to set aside some time. Regard this time as a gamble, and assess its value when you're done. If I was doing this, I'd prefer to work in a group (so for a 3 person-hour recipe, schedule 2 people for 90 minutes). I might assess value by looking at whether I'd changed my bug rate, or found any particularly useful information / nasty bugs.

1 Exploring via Diagnosis: 3 person-hours

Pick out some current bugs that aren't clear, or that aren't reproducible. Doesn't matter if they're in your bug tracking system or not, but they should be already known, and not yet fixed.
Explore those bugs, seeking information that will clarify them or make them more reliably reproducible. Keep track of your activity.
Review what you've done, collate the information gained. Log new bugs, update clarified bugs.
If you can generalise from the investigative approaches you're used, then do so.
Tell the whole team your results.
Schedule another 3 hours on a different day and repeat!

2 The Usual Suspects: 2 person-hours + 10 minutes preparation

Spend 10 minutes writing down lots of different ways that bugs manifest / get into your software (Use any or all of cause, effect, location, conditions, etc.). Aim for diversity and volume, not completeness or clarity. This might be fun as a whole-team exercise.
Leaving enough time for the review+generalise+share steps at the end, split the remaining time in two.
In one half of the time, pick out problems that you've not yet seen in this release, and look for them. Keep track of your activity.
In the other half, pick out places that haven't yet seen many problems, and look in those for problems. Keep track of your activity.
Review, collate, log, update.
Generalise and tell the whole team your results.
Schedule another chunk of time on a different day and repeat!
Make your trigger list publicly accessible. Invite people to contribute, share, refine etc.

That said, ET is a skilled approach, and it's easier to get those skills into a team with a bit of reading / taking a class / involving a coaching consultant. There are plenty of sources around about getting started with exploration. Niel vanEeden and I wrote a paper called Adventures in Session-Based Testing which may help. It's here: http://www.workroom-productions.com/papers.html. For pithy heuristics, Michael Bolton has recently blogged the results of a fine EuroSTAR workshop here, and you'll also want to check out Elisabeth Hendrickson's cheat sheet, James Bach's mnemonics, Jon Bach's questioning approach, James Whittaker's tours (hopefully turning up on his blog soon).

If you have a favourite bootstrapping-into-exploration source, post it here or on Anna's original posting.

Note - I have an upcoming, no frills, public class on Exploratory Testing, in London, December 8-9. Lots of exercises, discussions, and learning by example.

Checklists

2008-10-30T23:51:00.000Z

A regular correspondent (hello, thanks for triggering this) asked me about checklists and testing. I had a half-written blog entry on some checklist rules of thumb, and shared it with him. Here it is:

Personal

Checklists I make are typically more useful than checklists I get. I expect this is more closely-related to ownership than quality.
I tend to do items at the top first, so ordering may become important even if it isn't meaningful.
I can't take in more than around 20 items on a list without giving it some structure. To help make a list comprehensible, I use outliners, item codes etc, and group items into categories.

General

Laundry-type lists are different from shopping-type lists. Laundry lists tend to be set up as general resources, tend to be long, many items don't apply to current circumstances and so one picks a few, can be inspiring. Shopping lists are often made for a specific need and discarded later, one tries to cover everything on the list. I can use each type to enhance the other, but it's generally a bad thing if someone else uses one of my laundry lists as a shopping list and vice versa. Testing Example: "All my charters" is a laundry-type list. "All my charters for today" is a shopping-type list.
The value given to a laundry-type list can come from an assumption that it is exhaustive, and that its items are mutually exclusive. Few lists are either – there are often missing items, and existing items overlap. Testing example: Lists of non-functional testing qualities. The real value in this laundry-type list is often that it inspires a shopping-type list.
When categorising, it's important not to use categories as proxy items. Even if the list is exhaustive, many items can be re-categorised – so doing none of, or all of, a category can be more arbitrary than it seems. Testing example: charters grouped in a hierarchy.

My correspondent indicated I might be interested in a not-so-recent New Yorker article by Atul Gawande about checklists in medicine. Surfacing briefly into the rolling boil of tester blogs, it turns out that the article has triggered a gentle meme-ripple through the industry.

Gawande's article describes shopping-type lists, to aid memory and set out minimum requirements. It describes how those lists were used by medical professionals to help them do their jobs more reliably. The checklists covered the simple stuff, and called for no judgement or skill in their use (of course, plenty of skill is needed in their construction, and in following whatever comes next to the little tickety box). The results were impressive – but just as impressive was that the medics actually used the simple things.

It seems that the people involved were responsible for making their own lists (perhaps collectively rather than individually) and also for finding out if the lists were working. They were supported at multiple levels – nurses checked that the checklist was in use and the boxes ticked off, executives made sure that necessary supplies were available for the tasks on the list – so that there were few reasons not to actively use the checklist.

I'll add another note to my 'General' list above:

When you're doing a difficult job under pressure, checklists help you concentrate on the job, by allowing you to expend less attention on avoiding mistakes. Testing Example: a list of possible input means (type, mouse, paste, drag in, cause default, undo delete, refresh).

The trick in this counter-intuitive heuristic is the difference between concentrate on, and do. A checklist can let your mind work more freely because the standard stuff isn't going to be forgotten. Indeed, I make shopping lists to go shopping with so I can multitask (for which read listen to The Goons on my iPod).

The article doesn't deal with two important ideas;

Change; when+why do items come off a checklist (important for shopping-type lists).
Use; what kinds of situation are most amenable to lists.

Aside from recommending regular reviews, I have nothing to say here about changing checklists.
Checklists generally help in situations which are:

well-known
busy (in the sense of being dense with stimulus)

It's clear that the massive confirmatory unit tests (and 'acceptance' tests) that characterise agile development can be seen as shopping-type lists, and are all the more powerful for it. The subject is well known (and the tests describe that knowledge) and the environment busy (in the sense of very many tests being run in quick succession). As a list, it helps exactly because it allows one to expend less attention on mistakes. The great (though arguable) strengths of massive confirmatory tests are, however, a special case.

Software development is certainly busy, but much of it is not all that well known. From a test point of view, often we're looking for the unexpected. From an engineering point of view, it's often hard to know what is reliably effective, sufficient and harm-free. Partly as a consequence of this, we tend to start out with laundry-type lists rather than shopping-type lists.

To pick out a few busy+well-known areas specific to testing, one might look at test environment setup, and the list of information on the top of a session form. Both these have a kinship with pre-flight checklists, and if you're not already checklisting in these situations, I expect you would find it valuable.

However helpful checklists are, they are frequently resisted as 'dumbing-down' a skilled task. As one who has resisted in the past, and who is likely resist in the future – I feel this is an entirely fair criticism. Perhaps the best bet is to take an approach similar to that taken by Peter Pronovost, the article's protagonist:

get whoever is making the {mistakes you're trying to avoid} to put together their own mnemonic/minimum standard list

get them to measure themselves with and without the list in use

provide strategic support to help ensure that there's no practical reason why something on the list can't be done, tactical support to help ensure that the list is actually used and used honestly.

Applied Improvisation

2008-10-13T21:23:00.000+01:00

I just got back from the "First in a series of Applied Improvisation Network (AIN) London Events", and thought I'd share some impressions.

The AIN describes itself as "Spreading the Transforming Power of Improvisation". At this particular event, AIN founder Paul Jackson was going to "use improvisation activity to introduce a business theme ... [using] complexity/emergence as the business theme example". I decided to go along because it sounded fun. Re-reading this, I wonder if perhaps my taste for fun has become a little over-sophisticated. Never mind.

The evening was pretty much as described. Just under a dozen people turned up to the usual oddly-shaped room in a re-purposed building. We talked, interacted as individuals and as a group in a set of well-structured exercises, and pushed off for a pint/meal. All was fine and dandy, and I'll go again. I found the exercises interesting, and may adapt* some for my own consultancy and groups - LEWT people, expect to gather in self-selecting groups sometime soon.

However, in this evening's exercises, there was a frustrating focus on game over content. I was reminded of peer events I have attended which degenerate (and I mean degenerate) into good teachers swapping their favourite lessons. Enjoyable and informative, but I took much more away about facilitation exercises and ways to get people to engage in improv than about the structures and ideas of improvisation. Emergent behaviours were discussed, but as personal lessons emerging from an exercise, rather than as properties emerging from a system. Business was discussed, but in terms of getting business people up and interacting in workshops, not in terms of translating improvisational skills into their working environments.

Reacting to this, I revisited some of the ideas about improvisation that I was playing with over the summer, and present them here, tidied and decorated for your amusement.

I'm interested in the improvisation involved in exploring a city, making an extempore speech, singing harmony to an unfamiliar tune. We improvise when we cook a meal with whatever is in the fridge, when we need to get a USB key from behind that hotel radiator, when someone falls off a ladder in front of us, when we get lost - especially when we get lost. To be expert is to be able to improvise with confidence.

It's clear that my interest in improvisation is, in particular, the improvisation we do as individuals under pressure from external circumstances. Perhaps I'm just not a team player; after all, my sports are/were skiing, swimming and fencing. Ask the Choir if they agree before you jump directly to any conclusions...

Improvisation as AIN addresses it is useful, interesting, but seems (on the strength of a single meeting and a swift half) to be biased towards shortform group improvisation under circumstances imposed by the group. This is more complex in at least two ways, and a wonderful field of study - but the interests I list above would be poorly served if this was where improvisation stopped. Conversations indicated that, perhaps, improv was the only improvisation the group could discuss with engagement. I think there's more, and I look forward to interacting with the group and its approaches.

One-line summary: improvisation ≠ improv. Who knew!?

* at the workshop, no ownership was claimed, and no attribution given. One could use the viral meme (pace GPL) and apply the same rules when passing it on, or apply one's own standards if more stringent. I choose to apply my own standards - these exercises were facilitated, and may have been devised, by Paul Z Jackson. However, if it is the practice within this industry to change and neither claim nor attribute, I many yet adjust those standards to fit the context. For those interested in improv exercises, http://improvencyclopedia.org/ is a resource with more than enough (500+) to tickle your fancy.

Decisions and responsibility

2008-10-13T15:10:00.000+01:00

There's plenty of mileage in group decisions, and in the wisdom of crowds. I presume that, as technology enables the convening of groups, we'll see more decisions made collectively. I hope - and believe - that in general those decisions will be better.

However, making a decision is not the whole picture. There is a degree of responsibility that goes with a decision, and I'm coming to the conclusion that a group decision is worth nothing if the individuals in the group are not prepared to take individual responsibility for their decision.

One-line summary: watch out for decisions made by groups whose members are disengaged

Agile2008 (and Glasto 2008)

2008-10-07T10:49:00.000+01:00

Under the inspired guidance of Rachel Davies, Agile2008 modelled itself on Glastonbury Festival. I found myself performing at both, which came as a bit of a surprise.

Aside: I'll leave the muck and general debauchery of Glasto to your imaginations - suffice it to say that I was entirely sober, stayed at my Mum's, and was on-stage with my wife*. With 25 stages and 150000 revellers spread across a Somerset valley, Glastonbury's scale is as staggering now as it was when I first went in 1987 (no wife, no sleep, not sober). It turns out I'm no less impressionable at 40 than I was at 19. I loved it.

With 1500 people, Agile2008 was a couple of orders of magnitude smaller than Glastonbury. Like Glastonbury, it was as fascinating as it was overwhelming. Attendance was about as big as a relatively-technical hotel conference gets, but the truly staggering element was the 25 concurrent tracks. Being a power-law thing, this of course did not mean 60 people in each session, but hundreds in a few, and a small handful of patient listeners in most others. It meant that nobody saw more than a tiny fraction of the material on offer. However, the keynotes** were attended by a vast majority of participants, and served to align the subjects of conversation. With this, and the attention given to breakout areas, triggers for discussion, and informal entertainment/events there was a clear feeling of community.

Performing or not (unless you're headlining), these events are at least as much about going and being with the crowd as they are about seeing the stars. You're as likely to love an act you stumble upon as an act you've waited years to see. I'm perversely proud of wandering away from the mighty (and very favourite) Massive Attack at the height (depth?) of their Other Stage thunder and into the elderly groove of the wonderful (and utterly new to me) Ethiopiques. I'm happy to have voted with my feet in Ron Jeffries / Chet Hendrickson's surprisingly artificial Natural Laws of Software Development and just as happy to have made the temporary acquaintance of that embittered sage, Brian Foote. I crossed paths with Toby Mayer half-a-dozen times, each time coming away with insight and inspiration.

The most interesting element for me was the degree to which the (formal) practices of Agility were not only reinvented by each team, but to a significant extent rejected. Two talks highlighted this particularly well:

Bob Martin's keynote gave the most visceral example, as he asked everyone in the room to put their hands up if they were involved with an agile project, then read a list of common practices and asked people to put their hands down as he listed practices which they did *not* do. By the time he had got about five items down his list, 1500 hands in the air had reduced to just one group, and a couple of dozen isolated hands across the hall. His next point; 'keep your hands up if all your tests are automated' took out the group (oddly enough, a gang of testers from Menlo Innovations) and only very few individuals remained in the game.

Scott Ambler's talk (which packed the 'Questioning Agile' stage/room) put real numbers on this phenomenon with a survey from Dr Dobbs in February. You can read his conclusions ("Agile in Practice: What Is Actually Going On Out There?") on his site, but better yet see a video of the talk (from about 5 feet from where I was squashed in) on InfoQ. You might be interested to know that he's made his data available for analysis. I've been looking through it from a testing point of view for a financial client, and his conclusion seems supported: "The easier practices, particularly those around project management, seem to have a higher adoption rate than the more difficult practices (such as TDD) ... For all the talk about TDD that we see in the agile community, it’s nowhere near as popular as doing a bit of up-front modeling, which we rarely hear anything positive about.". Indeed, I'd be tempted to say that the numbers indicate that practices related to testing are typically among the less-likely to be used. None the less, 80% of respondents felt they had better quality and happier customers.

For those of you who are interested, my own talk (also on the Questioning Agile stage) went well (rather better than the Guardian Stage at Glasto), captured a good audience and generated some fruitful discussions. I took my slightly-jetlaggy part in the pre-conference "functional test tools" workshop (a physical extension of the ongoing discussion on yahoo group aa-ftt) which was worthwhile, but not terribly conclusive.

An excellent event - great for new perspectives, for new people, and for fun. I'd certainly go to Glastonbury again - and with any luck, Agile20xx.

~ o ~

* she leads, and I sing in, the London Bulgarian Choir. The lovely British Sea Power lent us part of their acoustic spot in the Guardian tent, and the girls sang with them for songs on the John Peel stage and the Left Field stage.

** James Surowiecki on diversity/wisdom of crowds, Alan Cooper on engineering user experience and iterative/incremental methods, Bob Martin on a 5th line to the Agile Manifesto ("we value craftsmanship over crap" - although I think there are efforts to make this more boardroom-friendly)

Fun for explorers

2008-09-21T20:37:00.000+01:00

If you like physics, or playing with stuff, you'll like this: FantasticContraption

A perfect example of exploring solutions, alternatives and refinements. For those of you who have been on my exploratory testing course, I couldn't teach ET with it, but I urge any readers interested in exploration to watch themselves - or someone else - working towards solutions, general applications, principles, components. I've just lost a chunk of time myself in a gentle whirl of levers and engines. Reminds me of Meccano, but it's fast, flexible, and never runs out of bits (or seizes up with friction). Must get AquaForest back on to the iPod Touch.

Not every revolution is part of an evolution.

2008-09-17T08:49:00.000+01:00

Evolution is always revolutionary to those caught up in it. Only hindsight makes a revolution part of an ongoing evolution.

If you're not part of the revolution, you won't evolve. If you don't evolve, you're stuck in a dead end of ever-decreasing resources.

Of course, this is to confuse the individual and the tribe.

An alternate way of putting this - no individual survives (Darwinian) evolution. Thank goodness culture is Lamarckian.

Exploration and experimentation

2008-09-15T13:07:00.001+01:00

I thought I'd share this, from The Economist:

In the 19th century it was commonplace to do an experiment simply to see what would happen. That was, in part, because experimenters were often amateurs who were spending private money. In these days of taxpayer-financed science, most experiments are executed with a pretty clear idea of what the outcome ought to be, especially when they are part of wars and campaigns against this or that. The paradox is that, although such efforts do not eliminate Becquerel-like discoveries, they risk limiting the chances of making them.