blog.mattwynne.net

One of the several great things about working for my current client is that their high public profile means it’s reasonably easy to get interesting people to come and visit us from time to time.

Last week the mighty Martin Fowler dropped by to talk to us.

(more…)

My notes on DanNorth and JoeWalnes‘ session at Spa 2008.

Five artefacts:

• Automation - the glue that binds the tests to the code
• Vocabulary - the language that the tests are expressed in
• Syntax - the technology that the tests are expressed in (C#, Java)
• Intent - the actual scenario being tested
• Harness - the thing that runs the tests and tells you if they passed

Four roles. People might fill more than one, or more than one person might be in a role:

• Stakeholder
• Analyst
• Tester
• Developer

Taking a requirement, the Stakeholder and the Analyst have a conversation:

• what does that requirement mean?
• how can we create a shared understanding?

Then the Analyst and the Tester have a conversation:

• what is the scope of (’bigness’) of this requirement?
• how will we know when we’re done?
• => Scenarios (examples)

Tester then ‘monkeyfies’ the scenarios, using the following template:

Given … - assumptions, context in which the scenario occurs.

When … - user action, interaction with the system

Then … - expected outcome

e.g. Given we have an account holder Joe and their current account contains $100 and the interest rate is 10% When Joe withdraws $120 Then Joe’s balance should be $-22

The tester and the developer sit down and write an automated test to implement each scenario.

You might chain these up, but you can always categorise test code into these three partitions. This really helps how you look at test code.

Consistency Validation Between ‘Units’

See the Consumer Driven Contracts paper on Martin Fowler’s website.

Tooling for Automation

Consider extending / creating the domain model to cover the application itself - the UI, the back end.

Loads of tools are availlable. Use whatever works and build on it.

Building a Vocabulary

Ubiquitous Language - Start with a shared language. It becomes ubiquitous when it appears everywhere - documents, code, databases, conversations.

You will use different vocabularies in different bounded contexts. A context might be your problem domain, testing domain, software domain, or the user interface domain.

Beware which roles understand you when you’re talking in a particular domain. Often terms will span domains.

e.g. NHibernateCustomerRepository <– 1 –><– 2–><– 3 –>

1 = 3rd Party Provider Domain 2 = Problem Domain 3 - Software Domain

Make your tests tell a story - make it flow. Don’t hide away things in Setup methods that will make the test hard to read. If that means a little bit of duplication, so be it. ‘Damp not DRY’.

Syntax - Implementing Your Tests

• write your own
• keep it simple. don’t fart around writing too fancy a DSL. you’ll be surprised what testers / analysts / stakeholders will be prepared to read.
• great way to learn
• Jbehave2
• training wheels?
• rspec
• very nice.
• create templates for each given / when / then which you can plug together with parameter values into scenarios
• fit
• concordion
• nbehave - joe ocampo

Basically what you need is a way to assemble different permutations and combinations of Given / When / Then with different parameters to make different scenarios.

Expressing Intent

Think in terms of narrative, flow. Think in terms of bounded contexts, and who the audience (role) is for that context. Who will understand that vocabulary?

Make sure the intent is clear - that’s the main thing.

Harness

Do you want to hook into continuous integration build?

Which version of the code is it going to run against?

Keep the tests in two buckets: * in progress * done

Those which are in the ‘done’ bucket, should always work, those which are in progress are allowed to be failing, until you make them pass.

Getting Started

Things you can do today.

• Try it for your next requirement
• Given When Then helps guide the tests
• It’s a collaborative process - get people involved
• Works for bug fixes
• a bug is a scenario that you missed in the first place use the tools you’re most comfortable with
• doesn’t have to be perfect

Down The Line

What to aim for.

• ALL requirements have acceptance criteria specified up front
• helps with estimation
• acceptance tests are automated where appropriate
• just having thought about it helps - you may come back to automating it later.
• Push button, availlable to all.
• helps build trust with stakeholders

Advice

• Automate pragmatically
• Don’t try to automate what you can’t do manually
• Testing is validating an outcome against intention
• Non functional requirements
• Plan for false positives
• Quality is a variable
• doesn’t mean you don’t go test first
• doesn’t mean low quality code
• does mean how complete is the solution? - how many scenarios / edge cases are you going to try and meet?

Summary

• Have a shared understanding of done
• There is no Golden Hammer
• Be aware of the five aspects of test automation
• Automation, Vocabulary, Syntax, Intent, Harness
• Start simple, then you can benefit now

I facilitated our regular end-of-iteration retrospective last week, and although the feedback from the team was positive, I was left with a feeling that something wasn’t right.

With our second major live release looming large on the horizon, I focussed the session on the theme of ‘Success’. My aim was to give the team a blueprint for a successful iteration to keep in mind when things were tough, and to help ensure that we were all pulling in the same direction by agreeing as a team what constitutes success for us.

(more…)

Karl Scotland has posted a great description of how his team solved some issues they were having within their Scrum team by moving over to using a lean-thinking or Kanban system, based on a short buffer or Queue of Minimum Marketable Features (MMFs). It’s probably the clearest explanation I’ve seen yet of why and how to employ this emerging technique, and Karl certainly makes a compelling case for considering this as a progression for teams who are experienced with Scrum and need to be able to adapt rapidly during the development of a story or feature.

One of my key questions about Kanban is how it’s possible to predict long-term delivery dates for specific features, and although Karl goes some way to answering those questions, it looks as though you need, as well as a mature agile team, a fairly mature and trusting organisation to make this work.

I guess you also need to be working on a product that’s already in production and being updated regularly.

Brian Marrrick makes a good point that ‘incremental’ and ‘iterative’ just look and sound way too similar to make the decent brand-names for ‘evil’ and ‘good’ software development practice respectively.

Note to self: say ‘incremental assembly’ (boo!) and ‘iterative growth’ (yeah!).

The more I think about it, the more I like the growth vs assembly metaphor for software: creating a fertile environment etc… nice.

How important is it to measure how long something took?

Well, so the received wisdom goes, by comparing how long it took you to complete your a task against the estimate you made before starting it, you get an idea of how good your estimate was. So far, so good.

But what if your estimate turned out to be wrong? What are you going to do about that?

One of the culture shocks I think scrum introduces it the idea that we almost always just look forward. I don’t care how long you’ve spent on a task, I just want to know how long you think it will take you to finish it, based on what you know right now.

Tomorrow, if you turned out to be wrong, that’s OK. All we need to know is how much longer it’s going to take to get it done.

Except it’s not OK.

Because if your task, which you originally estimated would take 2 hours has taken you two days, and it’s still not done, then something is impeding you.

Fortunately in a team practicing scrum, we have a daily 15-minute meeting where impediments like this are made visible to the entire team, and someone takes away the action to resolve the impediment.

Rather than having to retrospectively scan reports of esimates vs actuals in a spreadsheet, the problem can be highlighted as it’s happening, and hopefully resolved.

Agile teams also have a second line of defence against more stubborn impediments: The retrospective.

With these two facilities in place, it becomes unnecesary to track the details of estimates vs actuals. The administrative overhead on developers is reduced, and they can get back to writing solid code.

Some people find this difficult to accept - there’s a familiarity to the recording of the numbers. We’ve allways done it. It makes me feel safe. Somebody will ask us for them.

If someobody asks you how good your estimating is - show them your burn-down chart.

It’s bloody obvious from the shape of the chart if your estimating is any good. And if they want figures, measure the difference in area beneath your real curve (blue line) and your ‘ideal’ diagonal curve (red line). Every hour above the diagnoal line is an under-estimated hour. Show this to your team. Get them to look at it and reflect on how realistic they’re being when they estimate tasks.

If somebody asks you why your estimates were too low - listen to people. Look at your impediments log, and the write-up of your retrospectives. You need a culture where impediments get surfaced quickly from the team, where it’s OK to say things aren’t going well, and where problems raised get solved and cleared out of the way.

The stand-up meeting has had quite a lot of attention on my team over the last week. At our last retrospective, it was brought up as a problem that we nearly always had at least one person missing when we started the meeting. Obviously this hampers us reaching the goal of having a rich and motivating exchange of information throughout the whole team. We still get a chance to adapt the plan, but not everyone’s going to know about that if they weren’t there. I also feel it really drags down morale when the same one or two people (and it’s nearly always the same ones) appear not to be as committed as the rest.

So, like all good self-organising teams, we got together and talked about it. Yep, we had a meeting about a meeting.

During this, at times heated, discussion it became clear that we were talking about two separate issues. As well as using the stand-up to synchronise our work, we were using it as our starting-point for the day. Those who like a lie-in will tend to get themselves in just in time for stand-up, and thus their day begins.

So while the first and most obvious issue for debate was what time to have the stand-up meeting, lurking in the background was the much more thorny issue of how late it is acceptable for a team-member to turn up for work.

Fortunately we spotted this pretty much in time before the mud-slinging between the early-risers and the alarm-clock-o-phobes began. On reflection of the benefits of the meeting as a whole, we judged that providing a start-point for the day was not as important as the other benefits about communication which require every member of the team to be present. So we decided to abandon the use of the stand-up as our start to the day.

So that we can still harness the motivation that comes out of a good stand-up, we decided to hold it at 2pm, when everyone should be back from lunch and ready to blast through the afternoon.

All we can do is try it and see how it works.

What time do your team have their stand-up, and why?

I just came across an article written five years ago by Richard Gabriel proposing a university course run along the lines of his own Master’s in Fine Arts in poetry. The idea evidently gathered some momentum at the time, but now seems to have come to a halt.

What a shame. I’ve had an idea to get back to university on a ’some day’ list for a while, and this would have been pretty much exactly my thing, I think. Seems to me like it was just an idea ahead of its time… I wonder how popular something like that would be now, with the increased focus on Quality that is sneaking in the back door behind the noisy razzmatazz of agile adoption.

I just bumbled into a great post by Raganwald on the subject of certification for professional software developers.

It’s something I’ve been giving some thought to lately. I coach my team informally on a daily basis as we work together and more formally at the end of each iteration during our retrospective. I’ve also been asked to start a process of coaching other teams too.

In my other life, I teach people to snowboard. BASI, the organisation who taught me to teach, have developed a clear progression from complete novice through experienced recreational riders, right up to instructor trainer. Similarly, I just took the PADI Open Water Diver course, and again there is a clear progression where you learn the skills required to dive safely on your own.

Like Raganwald, I feel that certifying people for technical skills like expertise in coding a particular language is really missing the point. I thing he’s on to something by wanting to prove that a person knows how to produce a bullet-proof product - after all, that’s the whole point isn’t it?

I’m interested in the series of learnings that people go though in their time at work that take them to the point where they do a lot of these things as second nature. Where they don’t claim something is ‘finished’ when they first manage to get some data up on the screen; where they know exactly when to step away from the keyboard and make a cup of tea to mull something over, or when to ask for some help instead of thrashing themselves, quietly, into a rotting hole. The things that make people valued members of my team are much more the ’soft’ skills that mean they spend their time at work as effectively as possible, like confidence, humility, and empathy.

In a way it’s a good thing that we don’t just have a simple scale to measure people against, we’re dealing with real human beings, after all. On the other hand, it might be handy to have a map to help us all along the way.

As with most stupid questions like this, the answer is “neither”. There are times when integration tests really help, and there are times when they can be a pain in the neck.

I was prompted to write this post when a colleague pointed me towards this page on the behaviour-driven wiki, which mentions the disadvantages of integration tests, which usually involve some complex (and often slow to run) procedure to set up an expected state in the system your code is integrating with. This tight coupling with the external system reduces agility and makes the test code brittle.

The page does point out that “even in this state the code is often much more robust and a much better functional fit than code developed under more traditional methods based on large-scale up-front design”

I agree with the principles in the article, and I believe BDD is a great way to think, but I do think as long as the integration tests are well-factored (and hence easy to change) then the problems highlighted don’t apply – you’re still going to be quick on your feet if requirements change.

The question is whether you’re going to spend more time fixing your unit tests than you would debugging the code – if you’re confident you can write it correctly first time and anybody needing to change it is highly unlikely to introduce bugs in the area you’re coding, it’s a waste of everybody’s time to write a unit test – the test just becomes baggage for the team to drag around.

Conversely, if there’s a risk that future changes could break what you’re coding, or you’re bored of hitting F5 in the browser to test some subtle tweak in a function way down deep in a subsystem, thinking of an imaginative way to write a lightweight unit test that isolates that function and proves that it works as you want it to, is probably going to save you some dull debugging time.