Hiccupps

I bought a belt recently. Unexpectedly, it came with a tool for making holes and the notice above. My initial reaction was to chuckle and think "yeah, we could probably all learn something from that." But, honestly, that's just lazy. That's the cheap laugh. That's this misguided thinking:  DO NOT OPEN THE EDITOR BEFORE YOU FINALISE THE REQUIREMENT And I am so over that.  When asked what advice I would give to the early-career me I've often answered: get comfortable with uncertainty.  In the spirit of today's post, I might rephrase that as DO NOT HALT THE WORK BEFORE YOU ENCOUNTER THE BLOCKAGE Of course, this is what iterative development is predicated on. By the time we've coded what we can, and shown it to our customers for feedback, we might find that we understand the problem space well enough to not need answers, or that we were asking the wrong questions. What I like these days is to understand t...

It was my wedding anniversary recently. The picture at the top is the front of the card I got for my wife. Yeah, I know. Somehow she still loves me. I asked my family which bean out of the couple they thought I was and everyone chose the one on the left, including me. Surprised, I showed the picture to my work colleagues and they also unanimously went for the left-hand bean. Why? Here's some of the reasons I was given: the legs it's spilling its drink, like a man would the light reflecting off the top of the head  the man always stands on the left in wedding pictures  it looks like you I don't want to go deep into this, especially that last point, so I'll just observe that despite strong surface agreement there was significant hidden misalignment in motivation. Like so many projects I've bean on. 

In Obliquity , John Kay argues that success may be best achieved indirectly. When the goal is non-trivial, the environment unpredictable, and the system in which we are operating is complex, then top-down working, planned to completion, is fragile. He recommends that we instead proceed obliquely , taking small steps, making choices opportunistically, and accepting that we do not have all the information or all of the control we might feel we want. Kay presents numerous examples of people and organisations that have done well with the oblique approach and some that have suffered when their indirect strategy straightened up. That's not to say the direct approach can't work or that it is a mistake to apply it to some situations, just that the set of real-world scenarios where directness is a good first choice is pretty constrained. It doesn't take much imagination to see the strong parallel between obliquity and agile software development. Likewi...

Brian Marick  recently launched a new podcast, Oddly Influenced . I said this about it on Twitter: Boundary Objects, the first episode of @marick's podcast, is thought-provoking and densely-packed with some lovely turns of phrase. I played it twice in a row. Very roughly, boundary objects are things or concepts that help different interest groups to collaborate by being ambiguous enough to be meaningful and motivational to all parties. Wikipedia  elaborates, somewhat formally:  [boundary objects are] both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites ... The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds. The podcast talks about boundary objects in general and then applies the idea to software development specifically, casting ...

At CEWT 3 I offered a definition of testing up for discussion. This is it: Testing is the pursuit of actual or potential incongruity As I said there , I was trying to capture something of the openness, the expansiveness of what testing is for me: there is no specific technique; it is not limited to the software; it doesn't have to be linear; there don't need to be requirements or expectations; the same actions can contribute to multiple paths of investigation at the same time; it can apply at many levels and those levels can be distinct or overlapping in space and time.   And these are a selection of the comments and questions that it prompted before, during and after the event, loosely grouped: Helicopter view it is sufficiently open that people could buy into it, and read into it, particularly non-testers. it's accurate and to the point. it has the feel of Weinberg's definition of a problem.  it sounds profound but I'm not sure whether there is a...

I regularly listen to the Rationally Speaking podcast hosted by Julia Galef. Last week she talked to James Evans about Meta Knowledge  and here's a couple of quotes I particularly enjoyed. When discussing machine learning approaches to discovering structure in data and how that can change what we learn and how we learn it. James suggested that  In some sense, these automated approaches to analysis also allow us to reveal our biases to ourselves and to some degree, overcome them.  Julia asked whether there wouldn't  still be biases built into the way that we set up the algorithms that are mining data. James responded that  When you have more data, you can have weaker models .  And on ambiguity's impacts on collaboration: I have a recent paper where we explore how ambiguity works across fields ... the more ambiguous the claims ... the more likely it is for people who build on your work to build and engage with others who are also building on yo...

While there's much to dislike about Twitter, one of the things I do enjoy is the cheap and frequent opportunities it provides for happy happenstance . It's not interesting that you can fool a computer. The whole art is how to *not* accidentally fool the computer. — Noah Sussman (@noahsussman) July 27, 2016 @noahsussman Only computers? It's easy to put people in incongruous situations. The art is in not doing it accidentally. — James Thomas (@qahiccupps) July 27, 2016 Without seeing  Noah Sussman 's tweet, I wouldn't have had my own thought, a useful thought for me, a handy reminder to myself of what I'm trying to do in my interactions with others, captured in a way I had never considered it before. Image: https://flic.kr/p/a341bn  

We've been building software for decades. And testing it for pretty much the same length of time . Over the years we've built up expertise and methods and approaches and heuristics and skills and theories and practices and communities and schools and courses and accreditations and conferences and blogs and, well, all the kinds of things you associate with a profession. So why isn't testing easier? Tongue somewhat in cheek, I've asked this question of other testers on several occasions recently, including at both the EuroSTAR 2015 and Cambridge Lean Coffee s. Here's a selection of answers I received: Testing is easy. You just find out what the system is supposed to do and see whether it does it. (I loved Rikard Edgren's take on this .) The environment in which we test is constantly changing; perhaps at a rate faster than many testers are prepared to change. Testing is always bespoke to the particular software in its context. Interestingly, althoug...

The current issue of The Guardian's Weekend magazine includes the transcription of a conversation between the authors Marlon James and Jeanette Winterson . This extract struck a chord: MJ : What I find, particularly with young writers and readers, is that they don’t want complicated feelings.  JW: But they’re young. And I feel sympathy with that. I’m happy to not know what I think about stuff; I’m happy to change my mind. But it’s relatively recently that I’ve been able to apply that to feelings. I used to like to know what I felt. I didn’t want those feelings to be complicated or muddled or clashing. I've been young (yeah, really, I had hair and everything) and I feel like these days I've made the transition they're talking about in writing, reading, feelings, work and life. And while I see that I also referred to age when I wrote about something similar a couple of years ago  I don't believe the opposition here need be about that, although the expe...

I've found it interesting to read the recent flurry of thought on the testing/checking question, thoughts referring back to Testing and Checking Refined , by James Bach and Michael Bolton, in which the following definitions for the terms are offered: Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modelling, observation, inference, etc. Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product. The definitions are accompanied by a glossary which attempts to clarify some of the other terms used. These chaps really do sweat the semantics  but if I could be so presumptuous as to gloss the distinction I might say: testing is an activity which requires thought; checking is simply a rigid comparison of expectation to observation. There has been much misunderstanding about the relationship between the t...

Extracts from How Complex Systems Fail   by Richard I. Cook: [it is] impossible for [complex systems] to run without multiple flaws being present. Because these are individually insufficient to cause failure they are regarded as minor factors during operations ...  complex systems run as broken systems.  Organizations are ambiguous ... [and that] ambiguity is resolved by actions of practitioners at the sharp end of the system. Safety is an emergent property of systems ...  continuous systemic change insures that hazard and its management are constantly changing. ... all practitioner actions are actually gambles, that is, acts that take place in the face of uncertain outcomes ... after accidents ... post hoc analysis regards these gambles as poor ones. But ... successful outcomes are also the result of gambles ... Image:  https://flic.kr/p/7TxmXk

Display caption:  Any resemblance to software development activities, living or dead, is purely coincidental. [Fade from black to bright sunshine.] The Test Manager was out of the office looking after his kids at half term. They were on what they called an adventure walk where he'd made a list of stuff for them to find on the stroll down to the river for a picnic. Their favourite on this journey was the window of wheels which they worked out in the end was a bike shop. (No, really, they actually asked for this.) When he returned to work the following week, nominally refreshed, the Test Manager found a jumper neatly folded and smelling freshly laundered on his desk. Tester 1, who sits behind him, said that BD, a member of the BizDev team, had left it there for him. The Test Manager was flattered. It was a tracksuit top affair, snazzy, and just the kind of thing he'd like. BD was quite a sporty chap and bigger than him, so perhaps it had got a bit tight and BD, ...

One of the names I considered for this blog - and one that made it right to the final cut - was There's no F in Spec . It appealed to me for several reasons, including: The literal correctness. There really is no letter "f" in the string "spec". The indirect contradiction. "Spec" is short for "specification" and there is an "f" in that. The implied rudeness. See also There's Only One F in Fulham . The pun on the rudeness. As Homer says , it's funny cos it's (so often) true. The metaphorical contradiction. Even if there is no f-ing spec, or story, or whatever, there's  always   something  you can base an investigation on. The number of interpretations and nuances I could find in it. Part of our job as testers is to be able to recognise this kind of potential for ambiguity and multiplicity, maintain contradictory interpretations for as long as it's useful but then tease apart what can and should be se...

The other day Michael Bolton tweeted this "Art" is the activity of directing attention to things and providing affordances for interpretations. Which is why testing IS an art. I love this tweet not least because it itself affords so much opportunity for interpretation. I'm intrigued by its possibilities. I found myself picking at it, perhaps even  factoring it. A few thoughts ... "Art" is quoted. Are these  scare quotes ? Do they suggest some uncertainty, disagreement or ironic intent? Or are they merely an alternative to some stylistic markup such as bold font that you might see in a dictionary definition? "Is" is emphasised in the second sentence. On that verb, that kind of marker might signify a refutation of some other assertion. Could that be the case here? What else might it be contributing? Both "art" and "an art" are used. The former is frequently defined in terms of beauty whereas the latter is usually applied ...

Honestly? I usually find non-fiction books hard work but I'm reading The Complete Plain Words like a thriller (see also Long Time Gone ). I've only just started but I love quotes like these on clarity: What appears to be a sloppy or meaningless use of words may well be a completely correct use of words to express sloppy or meaningless ideas.  Mistiness is the mother of safety. We need to choose the right words to make our position clear. If we don't, the words will make clear our position. Image: http://flic.kr/p/627MJn   Sounds: If I Could Only Remember My Name  

Humpty Dumpty was a big fat egg . Or he wasn't. He was a cannon . Perhaps. He represents King Richard III, some say . Maybe, others say. Whichever, if any, it's fitting that Lewis Carroll has him saying this: When I use a word it means just what I choose it to mean — neither more nor less. Recently during a team-wide festival of testing I was listening to Research-based pop, the new album by The Durds . I say festival of testing  and you have no idea what I'm on about. (I  am  in management.) I'd really like to say  testival   (yeah, let's innovise and neologate in a blog on lexical matters!) because that kind of thing appeals to me  but it would take us even further from a common understanding. What I actually meant and could easily have said is that the test team set aside a day to address a backlog of verifications without any distractions. To aid my own concentration and discourage interruptions, I was listening to Research-based pop, the ...

A good report is knowledge shared clearly, correctly, comprehensively, consistently and concisely . As testers, we spend a lot of our time dealing with reports that lack some or all of those and it should be important to us professionally, and also in our selfish interests, to maximise the signal/noise ratio of our own writing. But it's easy to forget to think about it and even when reviewing reports before submission it's easy to not notice issues, given the full context of the situation is usually uppermost in the mind at the time. Here's a few of the common traps I've fallen (and fall) into: "In a meeting it was decided that we should ..." Meeting with who?  Were there alternatives, are there minutes to link to? "It all goes wrong", "It just doesn't work" In what way, what do you see, why is that unhelpful? "It is not possible to ..." Are you sure? Just what did you do to try to make it happen? "We observe A, ...

Oh yes, this test manager knows how to make his team have fun  and my annual Christmas event has become legendary for the enjoyment level of its participants. Not least because I haven't yet repeated the cake testing task of that very first year. And if you'd like to join in the good times, here's the most recent instalment. After reading the latest management BS (that's Brilliant Science, y'know) book the QA manager mailed round the following to the product development team, convinced that in doing so he'd be making informed staff happy staff. He was also secretly beginning to use the third person to refer to himself in order to increase their level of respect for the QA manager. (That's psychology, that is.) The Dev Manager and QA Manager watched the team progress with Bugzilla statistics by using the XML API biweekly. They should be against bug fix data which does not provide quality insight.  Unfortunately, the QA manager hasn't spotted that ...

The older I get the miser I become. By which I mean that I more jealously guard the resource that I have and do my best to avoid spending it where I don't want or need to. Amongst my pet peeves (and I've collected a lot over the years) is the way in which unresolved upstream decision points can impact downstream. That's not to say I think all choices have to be made instantly (although there is theory on efficient decision-making e.g.  satisficing ) but I do think that clarity is imperative. When I'm waiting for a decision to license some further action on my part I don't want to have to expend energy and resources keeping possible options - and their dependencies - open, keeping resource on hold ready for an always impending decision - and perhaps compromising my other missions - and remembering to look up periodically to see whether the decision has arrived. When I'm waiting for a decision, I want the decision maker to be open about (a) what the chose...

If extracting feature motivations, requirements and priorities from stakeholders is an art, presenting the analysis requires artfulness. The MoSCoW method suggests using English words M ust, S hould, C ould and W on't as an alternative to purely numeric priorities to make it more transparent that not everything listed will be delivered. But reversing the MoSCoW rules can help to obtain  the implicit prioritisations. You'll frequently hear "we must have a solution to X" or "Y should be improved in this release" or "we'd like to get Z into the payload if we could ". Key verbs like this  can be mapped to prioritisations, e.g. P1 (must), P2 (should), P3 (could). We use these clues to bootstrap priority discussions and, perhaps surprisingly, I often apply it to my own bug reports to get an idea of my intuition on an issue. You ought to beware that there will not b e a 1:1 mapping between key word and priority, and negation does not help. Fo...