James Thomas' blog
Updated: 19 hours 24 min ago
This month's Lean Coffee was hosted by Redgate. Here's some brief, aggregated comments and questions on topics covered by the group I was in.
What benefit would pair testing give me?
- I want to get my team away from scripted test cases and I think that pairing could help.
- What do testers get out of it? How does it improve the product?
- It encourages a different approach.
- It lets your mind run free.
- It can bring your team closer together.
- It can increase the skills across the test group.
- It can spread knowledge between teams.
- You could use the cases as jumping-off points.
- I am currently pairing with a senior tester on two approaches at the same time: functional and performance.
- For pairing to work well, you need to know each other, to have a relationship.
- There are different pairing approaches.
- How long should you pair for?
- We turned three hour solo sessions into 40 minute pair sessions.
- You can learn a lot, e.g. new perspectives, short-cuts, tips.
- Why not pair with developers?
Do you have a default first test? What it is? Why?
- Ask what's in the build, ask what the expectation is.
- A meta test: check that what you have in front of you is the right thing to test.
- It changes over time; often you might be biased by recent bugs, events, reading etc to do a particular thing.
- Make a mind map.
- A meta test: inspect the context; what does it make sense to do here?
- A pathetic test: just explore the software without challenging it. Allow it to demonstrate itself to you.
- Check that the problem that is fixed in this build can be reproduced in an earlier build.
How do you tell your testing story to your team?
- Is it a report, at the whiteboard, slides, a diagram, ...?
- Great to hear it called a story, many people talk about a report, an output etc.
- Some people just want a yes or no; a ship or not.
- I like the RST approach to the content: what you did, what you found, the values and risks.
- Start writing your story early; it helps to keep you on track and review what you've done
- Writing is like pairing with yourself!
- In TDD, the tests are the story.
One thing that would turn you off a job advert? One thing that would make you interested?
- Off: a list of skills (I prefer a story around the role).
- Off: needing a degree.
- Interested: the impression that there's challenge in the role and unknowns in the tasks.
- The advert is never like the job!
- Interested: describes what you would be working on.
- Off: "you will help guarantee quality".
- Interested: learning opportunities.
- Interested: that it's just outside of my comfort zone.
After I blathered on and on about how much I'd enjoyed Ron Jeffries' Extreme Programming Adventures in C# the Dev Manager offered to lend me his copy of Extreme Programming Explained by Kent Beck.
Some background from Wikipedia:
Extreme programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Beck became the C3 project leader in March 1996 and began to refine the development methodology used in the project and wrote a book on the methodology (in October 1999, Extreme Programming Explained was published).So I took the book (it's the first edition) and I enjoyed it too, but differently. I might say that if Adventures is a road trip, Explained is a road atlas.
One of the things I liked about Explained (that it shares with Adventures) is the suggestion that only you can really decide whether XP can work in your context, and how. Also that Beck is prepared to offer you suggestions about when it might not.
But the world probably doesn't need any more reviews of this book so instead I'll note that I was a little surprised at the degree of upfront formality (which isn't to say that I don't think formality can license freedom to express yourself); sufficiently surprised that I mapped it to help navigate the rest. (And, yes, that's a map from an atlas.)
Houghton Mill is an 18th-century water mill, full of impressive machinery and, last weekend, actually grinding flour by the power of the river Great Ouse. Although I am not knowledgeable about these kinds of buildings or this technology I found myself spellbound by a small, but crucial, component in the milling process, the slipper.
The slipper is a kind of hopper that feeds grain into the millstones for grinding, Here's a short film I took of it in operation when I was there with some friends and our kids:
It has a system of its own, and also it is intimately connected to other systems.
It has inputs: a gravity feed brings grain into the top of the slipper; energy is supplied by the vertical axle which is in turn driven indirectly from the water wheel.
It has outputs: grain is dropped into the centre of the millstones immediately below it.
It is self-regulating: as the flow of the river varies, the speed of the wheel varies, the rotation of the axle varies, and the extent to which the slipper is agitated varies. Slower water means less grain supplied to the millstones, which is what is required, as they are also grinding more slowly. A second form of self-regulation occurs with the flow of grain into the slipper.
It has balance: there is a cam mechanism on the axle which pushes the slipper to the left, and a taut string which pulls it back to the right, providing the motion that encourages grain to move.
It can be tuned: the strings that you can see at the front provide ways to alter the angle of the slipper, and the tension of the string to the right can be adjusted to change the balance.
Tuning is important. If properties of the grain change (such as size, or stickiness, or texture, ...) then the action of the slipper may need to change in step. If the properties of the millstones change (e.g. they are adjusted to grind more coarsely or finely, or they are replaced for cleaning, or the surface roughness alters as they age, ...) then the rate of delivery of grain will need to adjust too.
Although the system is self-regulating, these are examples of variables that it does not self-control for. It has no inherent feedback mechanism for them, and so requires external action to change its behaviour.
Further, beyond the skilled eye and ear (and fingers, which are used to judge the quality of the flour) of the miller, I could see no means of alerting that a change might even be required. In a mill running at full tilt, with multiple sets of stones grinding in parallel, with the noise, and dust, and cramped conditions, this must have been a challenge.
Another challenge would be in setting the system up at optimum balance for the conditions that existed at that point. I found no evidence of gauges, or markers, or scales that might indicate standard settings. I noted that the tuning is analogue, there are infinite fine variations that can be made, and the ways in which the system can be tuned no doubt interact.
The simplicity of the self-regulation is beautiful to me. But I wondered why not regulate the power coming from the water wheel instead and so potentially simplify all other systems that rely on it. There are technologies designed to implement this kind of behaviour, such as governors and flywheels.
I wondered also about the operational range of the self-regulation. At what speeds would it become untenable: too slow to shake any grain, or too fast to be stable? There didn't seem to be scope for an automatic cut-out.
So that was an enjoyable ten minutes - while the kids were playing with a model mill - to practice observation, and thought experiments, and reasoning in a world unfamiliar to me.
I doubt you'll find it difficult to make an analogy to systems that you operate within and with, so I won't labour any points here. But I will mention the continual delight I find in those trains of thought in one domain that provoke trains of thought in another.