Hiccupps

Another of the capsule insights I took from The Shape of Actions by Harry Collins (see also Auto Did Act ) is the idea that a function of the value some technology gives us is the extent to which we are prepared to accommodate its behaviour. What does that mean? Imagine that you have a large set of data to process. You might pull it into Excel and start hacking away at its rows and columns, you might use a statistical package like R to program your analysis, you might use command line tools like grep, awk and sed to cut out slices of the data for narrower manual inspection. Each of these will have compromises, for instance: some tools have possibilities for interaction that other tools do not have (Excel has a GUI which grep does not) some tools are more specialised for particular applications (R has more depth in statistics than Excel) some tools are easier to plug into pipelines than others (Linux utilities can be chained together in a way that is apparently trickier in R ...

In our reading group at work recently we looked at Are Your Lights On? By Weinberg and Gause. Opinions of it were mixed but I forgive any flaws it may have for this one definition:   A problem is a difference between things as desired and things as perceived. It's hard to beat for pithiness, but Michael Bolton's relative rule comes close. It runs:   For any abstract X, X is X to some person, at some time. And combining these gives us good starting points for attacking a problem of any magnitude: the things the perception of those things the desires for those things the person(s) desiring or perceiving the context(s) in which the desiring or perceiving is taking place Aspiring problem solvers: we have a  lever . Let's go and make the earth move  for someone! Image: Wikimedia Commons

You are watching me and a machine interacting with the same system. Our actions are, to the extent that you can tell from your vantage point, identical and the system is in the same state at each point in the sequence of actions for both of us. You have been reassured that the systems are identical in all respects that are relevant to this exercise; you believe that all concerned in setting it up are acting honestly with no intention to mislead, deceive, distort or otherwise make a point. The machine and me performed the same actions on the same system with the same visible outcomes. Are we doing the same task? This is a testing blog. You are a tester. You have been around the block. More than once. You perhaps think that I haven't given you enough information to answer this question with any certainty. What task is being performed? Are the visible outcomes the only outcomes? To what extent does skill and adaptability form part of the task? To what extent does interpretation...

Aleksis Tulonen  recently asked me for some thoughts on the future of testing to help in his preparation for a panel discussion. He sent these questions as a jumping-off point: What will software development look like in 1, 3 or 5 years? How will that impact testing approaches? I was flattered to be asked and really enjoyed thinking about my answers. You can find them at The Future of Testing Part 3  along with those of James Bach, James Coplien, Lisa Crispin, Janet Gregory, Anders Dinsen, Karen Johnson, Alan Page, Amy Phillips, Maaret Pyhäjärvi, Huib Schoots, Sami Söderblom and Jerry Weinberg. Image:  https://flic.kr/p/pLsXJh

Postel's Law - also known as the Robustness Principle - says that, in order to facilitate robust interoperability, (computer) systems should be tolerant of ill-formed input but take care to produce well-formed output. For example, a web service operating under HTTP standards should accept malformed (but interpretable) requests from its clients but return only conformant responses.  The principle became popular in the early days of Internet standards development and, for the historically and linguistically-minded, there's some interesting background in this post by Nick Gall . On the face of it, the idea seems sensible: two systems can still talk - still provide a service - even if one side doesn't get everything quite right. Or, more generally: systems can extract signal from a noisy communication channel, and limit the noise they contribute to it. The obvious alternative to Postel's Law is strict interpretation of whatever protocol is in effect and no talking -...

This month's Lean Coffee  was hosted by Cambridge Consultants. Here's some brief, aggregated comments on topics covered by the group I was in. What is your biggest problem right now? How are you addressing it? A common answer was managing multi-site test teams (in-house and/or off-shore) Issues: sharing information, context, emergent specialisations in the teams, communication Weinberg says all problems are people problems ... but the core people problem is communication Examples: chinese whispers, lack of information flow, expertise silos, lack of visual cues (e.g. in IM or email) Exacerbated by time zone and cultural differences; lack/difficulty of ability to sit down together,  ... Trying to set up communities of practice (e.g. Spotify Guilds) to help communication, iron out issues Team splits tend to be imposed by management But note that most of the problems can exist in a colocated team too Another issue was adoption of Agile Issues: lack of desir...

After Neil Younger's talk on Lean Coffee for team meetings at the Cambridge Tester Meetup last night, we ran a Lean Coffee session. These are my notes on the topics we covered: How do you teach testing? The question was set up on the premise that "you can teach/there is a lot of available material for software development, but not so much for testing".  This was disputed: was the assertion confusing (availability of material for) learning programming languages with being able to program or being a good developer? When teaching or coaching testing, particularly to non-testers, a detective metaphor is useful. Testing is about a problem-solving mindset ... but so is programming, right? How do you keep up with technology? When your product uses or interacts with some new technology, how do you get up to speed with it? How do you get sufficient depth to be able to talk to experts on your team? Testing is about learning, whether it's your product or some...

Neil Younger spoke about using Lean Coffee for his test team meetings at last night's Cambridge Tester Meetup . Inspired by the Cambridge Lean Coffee meetings - which are also part of this meetup and which he has hosted at DisplayLink since the earliest days - he replaced a failing monthly team meeting with Lean Coffee. And he hasn't looked back. Here's a few bullet points pulled out of the talk and subsequent discussion. The monthly test team meeting was failing for various reasons, including: As the company transitioned from waterfall to agile there were other forums for people to report status ... and these were generally more timely ... and the monthly meeting became mostly repetition. With a cross-site team the physical constraints of the meeting rooms - round a table at each end, with a monitor onto the other team - seemed like a barrier to interaction. They changed the Lean Coffee format in several ways, including: Cross-site means that post-its a...

Some time ago, maybe even a year ago now, one of my team said that she had been watching me. I acted cool - although that may have been the onset of a cold sweat - but fortunately my dark secrets remain mine and her observation was simply that, to her mind, I am always testing. She gave a couple of examples: When the test team were being given an expert-level product demo, I took notes not only on the functionality but also on the way that that information was being communicated to us, verbally and in slides, and I fed that back to the business because what we were watching was similar to the content of our customer demos. When I set a piece of work - for myself or others - I will frequently have a secondary aim other than simply getting the piece of work done, and that aim often has an evaluation or assessment element to it. And on reflection I think she's right. This is something that I have done, and do do. These days, I...

My second eBook has just been released! It's called Your Testing is a Joke and it's a slight edit of the piece that won the Best Paper prize at EuroSTAR 2015 . Here's the blurb: Edward de Bono, in his Lateral Thinking books, makes a strong connection between humour and creativity. Creativity is key to testing, but jokes? Well, the punchline for a joke could be a violation of some expectation, the exposure of some ambiguity, an observation that no one else has made, or just making a surprising connection. Jokes can make you think and then laugh. But they don't always work. Does that sound familiar? This eBook takes a genuine joke-making process and deconstructs it to make comparisons between aspects of joking and concepts from testing such as the difference between a fault and a failure, oracles, heuristics, factoring, modelling testing as the exploration of a space of possibilities, stopping strategies, bug advocacy and the possibility ...