Hiccupps

  I've just finished reading Thinking in Systems: A Primer by Donella Meadows. It's not a new book but I'd managed to be unaware of it until recently when Marianne Bellotti mentioned it on her podcast, Marianne Writes a Programming Language .  Bellotti is writing a programming language (duh!) for modelling system behaviour using the concepts of stocks and flows, inspired by Meadows' book. The image at the top gives an idea of how such models can work, notably making explicit the feedback relationships for resources in the system, and allowing modellers to reason about the system state under different conditions over time. I have been aware of systems models similar to this since I first saw Diagrams of Effects in in Quality Systems Management Volume 1: Systems Thinking by Jerry Weinberg. Weinberg's book, and other reading I was doing early in my career as a tester, inspired me to look deeply at the systemic context in which the software I'm working on sits and...

This week I listened to a Ministry of Testing podcast on exploratory testing .  After the intros, as the panelists  attempted in turn to give their definitions of exploratory testing, I realised that I didn't have one for myself. It's not that I don't know or haven't seen definitions. Here's one I've heard a few times, from back in 2008, in A Tutorial in Exploratory Testing by Cem Kaner:  Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project. It's not that I think The Exploratory Elders like Kaner got it right back in the day and their words should be carved on monumental stones and polished on Sundays, or that I'm not interested any more. I was readi...

Last night I attended Influencing Quality & tackling the problems that come with it... , a panel webinar hosted by Burns Sheehan and chaired by Nicola Martin . The panellists were: Marc Abraham , Head of Product Engagement at Asos Antonello Caboni , Engineering Coach at Treatwell Marie Drake , Principal Test Automation Engineer at NewsUK Pedro Vilela , Engineering Manager at Curve As you might guess from that line-up the material covered was broader than simply testing, taking in subjects such as quality, value, hiring, and the delivery process across the engineering organisation. The signal to noise ratio was high, so my sketchnotes capture only a few of the points made on each topic. The idea that quality is a whole team responsibility came up several times. Quality is a notoriously slippery and subjective concept, so in the Q&A I asked whether any of the speakers had ever tried to create a Definition of Quality for their team, something like a traditional Definition of Done...

The other week I found myself locked out of our shed and subsequently learned more than I ever expected to about Yale locks, or night latches as I now know they're called. The image at the top is a pretty standard night latch. It is opened from the outside with a key and from the inside with the handle. The latch (the gold tongue on the top left image) is sprung, which means that simply closing the door will push the latch onto the striker plate and into the box (both top right), locking it.  A deadlock which stops the latch from moving can be applied from the inside using the button (or, more correctly, the snib ). Night latches are an old technology, insecure, and make it easy to accidentally lock yourself out. The snib helps with the last of these by being able to hold the latch back inside the body of the lock. This means that even if the door closes, the latch can't engage and the door remains unlocked. Which is nice to know, but my problem was that I couldn't get in ...

The other week, I tweeted this: I want to make a list of @JerryWeinberg recordings. I've found around 35 so far, mostly interviews from podcasts and youtube. If you know of any, or any existing lists, can you send me links? I'll share the whole list when I've curated and tidied it. The response was bigger than I expected so I put a very quick and dirty list on this page initially. I've now replaced it with a Google spreadsheet: Jerry Weinberg Recordings If you know of other recordings, please tell me via Twitter or in the comments here. Thanks! Image: Agile.FM via Pinterest

We've all been there: frustrated by a request from a stakeholder for what we take to be significant new work without regard for the scale of it, the time it would take, or the current backlog. Recently, a colleague in that situation and ready to scream "NOOOOO!!!!" asked for my advice. What I said boiled down to this: Step back and think of at least three ways that the request could be interpreted. Sketch rough ideas for how you could do each of them, at what cost, with what compromises.  Share them with your stakeholder to clarify their desires and help them to guide the next steps. This is essentially Jerry Weinberg's  rule of three  and orange juice test  so I claim no great novelty here. What I do claim is that I feel a lot better when I follow these steps than when I instinctively reject some request based on poor assumptions and no conversation, landing myself in a needlessly defensive position. P.S. just to make this harder, don't forg...

The Line. As a model there's not much simpler than a single horizontal line but, for Jim Dethmer, Diana Chapman, and Kaley Klemp, it's sufficient in any quest to become a more conscious leader: at any given moment, a person is either above the line and conscious , or below it and unconscious .  In their book, The 15 Commitments of Conscious Leadership , they elaborate. Being above the line means being open, curious, and committed to learning while being below it means being closed, defensive, and committed to being right. To operate above the line is to have a By Me state of mind (to take responsibility for being in any situation, to let go of blame) while below it is To Me (to believe that external factors caused the situation, to have a "victim consciousness"). Above the line leads to healthy and trusting relationships while below the line leads to toxic and fear-based relationships. Shane Parrish, interviewing Dethmer on the Knowledge Project podcast , sug...

Jerry Weinberg died yesterday . I never met him, except virtually by video and email, but I can't think of anyone outside of my immediate family who has influenced who and how I am as much as he did. I forget when I came across him, but the first post on Hiccupps that references his work is back in February 2012, just a couple of months after I started blogging.  Since then I've tagged around 30 posts with his name , moving from testing (my gateway drug) through problem solving, software development, systems thinking, management, and interpersonal relationships. Every single day I use tools that I took from his workbench, tools like these: the rule of three the definition of a problem congruency the definition of quality caution around feedback I can't begin to put into words the feelings I had when he was extremely generous with his expressions of enjoyment for my essay, Your Testing is a Joke , and how overjoyed I was that my words had sparked something...

Four lightning talks at the Cambridge Tester meetup at Linguamatics last night, four topics apparently unrelated to one another, four slices through testing. Yet, as I write up my notes this morning I wonder whether there's a common thread ... Samuel Lewis showed us the money. Or, at least, where the money is held before being dispensed through those holes in the wall. He included some fascinating background information about ATMs (and a scary security story) but the thrust of his talk was the risks and corresponding mitigation strategies in a massive project to migrate the ATMs for a big bank to a new application layer and OS (more scariness: many are still running Windows XP). Much of the approach involved audit trails of various kinds, with customer and other stakeholders sharing their road maps and getting a view of the test planning and strategy in return. I enjoyed that the customer themselves was considered a risk (because they had a reputation for changing their mi...

To celebrate its 25th anniversary, EuroSTAR asked 25 testers who have played a big part in its history for a "top tip or piece of advice" that has returned value to them across their career and compiled the answers into a short (in length and height) publication, The Little Book of Testing Wisdom . Sales from the book raise money for the Saving Linnea campaign. We put the book on our Test team reading group agenda at Linguamatics for this week with the mission to "read all or some, but bring one (or more) articles you liked!" I decided on the strategy of reading the start of every article and continuing only with those that grabbed me immediately. I didn't seek (and haven't sought) to understand why some grabbed me and some not, but I did think about whether there was any commonality to the set of four that I particularly liked by the end and took to the meeting ... For me, advice that will stand the test of time must have inbuilt sensitivity to con...

Jerry Weinberg's definition of quality is well known. It is generally applied to encapsulate a relationship between a person and a product, at a particular time, and goes like this: Quality is value to some person It is intended to be a practical tool, and I think Weinberg would agree with something like this as a gloss for it: theoretical assessments of quality — perceived quality — are less important than those which are motivated by action. For example, a property is worth what someone actually pays for it. Without the action, it's just philosophy. What someone is willing to pay, or sacrifice, determines the quality (to them) at that moment. I've thought about this definition a lot over the years. In particular I've found myself speculating about the granularity of the definition. Back in 2012 I was wondering whether it was interesting to consider quality in terms of the aggregation of a set of qualities ;  more recently  I was thinking about the way that p...

Good Products Bad Products by James L. Adams seeks, according to its cover, to describe "essential elements to achieving superior quality." Sounds good! As I said in my first (and failed) attempt to blog about this book, I'm interested in quality. But in the introduction (p. 2) Adams is cautious about what he means by it: Quality is a slippery, complex, and sometimes abstract concept ... Philosophers have spent a great deal of time dealing with the concept of quality. This is not a book on semantics or philosophy, so for our purposes we will simply assume that quality means "good." But, of course, that leaves us with "good for whom?" "good for what?" "good when?" "good where?" and if you really like to pick nits, "what do you mean by good?" I won't go there, either. My bias is towards being interested in the semantics and so I'd have liked not to have seen a concept apparently so fundamental to t...

The Fieldstone Method is Jerry Weinberg's way of gathering material to write about, using that material effectively, and using the time spent working the material efficiently. Although I've read much of Weinberg's work I'd never got round to Weinberg on Writing until last month, and after several prompts from one of my colleagues. In the book, Weinberg describes his process in terms of an extended analogy between writing and building dry stone walls which - to do it no justice at all - goes something like this: Do not wait until you start writing to start thinking about writing. Gather your stones (interesting thoughts, suggestions, stories, pictures, quotes, connections, ideas) as you come across them.  Always have multiple projects on the go at once.  Maintain a pile of stones (a list of your gathered ideas) that you think will suit each project. As you gather a stone, drop it onto the most suitable pile. Also maintain a pile for stones you find attracti...

Managers. They're the light in the fridge: when the door is open their value can be seen. But when the door is closed ... well, who knows? Johanna Rothman and Esther Derby reckon they have a good idea. And they aim to show, in the form of an extended story following one manager as he takes over an existing team with problems, the kinds of things that managers can do and do do and - if they're after a decent default starting point - should consider doing. What their book, Behind Closed Doors , isn't - and doesn't claim to be - is the answer to every management problem. The cast of characters in the story represent some of the kinds of personalities you'll find yourself dealing with as a manager, but the depth of the scenarios covered is limited, the set of outcomes covered is generally positive, and the timescales covered are reasonably short. Michael Lopp, in Managing Humans , implores managers to remember that their staff are chaotic beautiful snowflakes ....

I'm enjoying the way the Test team book club at Linguamatics has been using our reading material as a jumping-off point for discussion about our experiences, about testing theory, and about other writing. This week's book was a classic, Lessons Learned in Software Testing , and we set ourselves the goal of each finding three lessons from the book that we found interesting for some reason, and making up one lesson of our own to share. Although Lessons Learned was the first book I bought when I became a tester, in recent times I have been more consciously influenced by Jerry Weinberg. So I was interested to see how my opinions compare to the hard-won suggestions of Kaner, Bach and Petttichord. For this exercise I chose to focus on Chapter 9, Managing the Testing Group. There are 35 lessons here and, to the extent that it's possible to say with accuracy given the multifaceted recommendations in many of them, I reckon there's probably only a handful that I don't...

This week's Cambridge Tester meetup was a show-and-tell with a theme: Is there a thing that you can't do without when testing? A tool, a practice, a habit, a method that just works for you and you wouldn't want to miss it?  Thinking about what I might present I remembered that Jerry Weinberg, in Perfect Software, says "The number one testing tool is not the computer, but the human brain — the brain in conjunction with eyes, ears, and other sense organs. No amount of computing power can compensate for brainless testing..." And he's got a point. I mean, I'd find it hard to argue that any other tool would be useful without a brain to guide its operation, to understand the results it generates, and to interpret them in context. In show-and-tell terms, the brain scores highly on "tell" and not so much on "show", at least without a trepanning drill . But, in any case, I was prepared to take it as a prerequisite for testing so I tho...