Hiccupps

Time flies, they say. This is the 720th post on Hiccupps and I'm publishing it fifteen years after the first, to the day. I've often used blog birthdays as a chance to step back a little and reflect but fifteen feels like a big number so I thought I'd step all the way back. --00--   I use the blog as a reference, to recall what I did or what I thought, but I don't have strong memories of a lot of the material, so I decided to sample it by reading the post published closest to its  anniversary  for every year of its existence. 2011  Sign Language Phew. The first post is not too cringe and it makes a reasonable point about the audience for our work being wider than the people who we hope will pay for it. I think I've jumped to a conclusion about who made the sign though, or there was some evidence that I failed to mention in the post.  2012  Flotsam or Jetsam? Internet Explorer 6. Yikes! But I can see how I would have laughed out...

You know The Law of the Instrument in one form or another. Wikipedia attributes this version to Maslow: I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. Which is insightful, but it belongs to a simpler, slower era.  Today the problem is not whether you have a range of tools. It's still less whether you know how to use them, and it's not remotely about knowing when.  No, today the problem is that we don't have to bother, and many of us don't.    I suppose it is tempting, if you have an enchanted hammer, to treat everything as if it were a  who-cares-just-hit-it-for-me. And if that's who we are now, what's happening to our craft? Image: Geronimo Giqueaux on Unsplash

Maaret Pyhäjärvi gave a talk, Exploratory Testing Reimagined , last week.  There's a  blog post  to go with it, so I won't say much on top of what's in my sketchnotes above, just pull out a few reflections. I don't have the data or wide range of experience reports that Maaret does, but my own anecdotal results from using AI tools for testing align closely with what she says in the talk. I have created skills to assist me, and my colleagues, in our testing work. For example, I used the contents of this blog and five years of test notes in my current role to distil a conversational workflow, facilitated by Claude, which runs through risk identification, test idea generation, and test mission creation. All four skills (the facilitation is its own skill) are backed by a fifth, on general testing theory and practice, and a sixth about how I like to interact with the AI: which notably includes that I want it to be concise, evidence-backed, well-structured, and critical. I st...

After reading a couple of my posts on AI that invoked comparisons with technologies in the rural environment ( Hedging Your Bets on AI ) and the music industry ( The Needle and the Damage Done ) a friend suggested that The Shock of the Old by David Edgerton might be interesting to me.  It was. The key theme of the book is that we tend to be beguiled by the invention, possibility, and novelty of technology rather than by its value, usage, or availability. This leads to some warped perspectives. For example, we lose sight of technology long before it becomes obsolete, we  devalue the old whatever its longevity and residual value in favour of the potential of the new, and we focus on the rich, modern, industrialised elite, rather than the day-to-day reality of most of the world's population.  The adoption and availability of technology is not uniform in time, society, or geography. William Gibson famously captured the essence of this idea in his pithy ...

The latest episode of the Vernon Richard Show, New QA Job? How We'd Decide Where To Start , answers this question from a listener, Shady: When joining a new organisation, how do you decide which QA domino piece to tackle first for the rest to easily fall into place? For example, you might find flaky test automation, poor testability in user stories, no integration tests, limited test management tools, missing test data, and an ever growing regression suite. With so many improvement opportunities, how do you prioritise what to fix first? As usual the conversation ranged freely and I've picked out some of the key points with a little commentary here: It Depends : usually the right answer or, rather, a small part of the right answer. The rest should be what it depends on and how that affects your answer. Investigate the Context First : exploring to understand the context is a reasonable default in a new job. You'll want to understand the key ...

I deliberately make tiny investments in learning opportunities for me and my colleagues.  Yesterday I was reviewing a PR which had a large number of edits to data using a few patterns applied in many places. Unfortunately, the edits were embedded in non-trivial contexts which made the diffs less easy to eyeball than I might have hoped. Here's an invented example that gives a flavour of the problem. The first line is an original, the second an edit: - (ab)38458345023421-5-7345234D  + (ab)038458345023421-5-7345234 Actually I haven't quite set that up right: the diffs were easy to eyeball, especially given coloured highlighting, but I know from experience they're also easy to wave through after a cursory skim which misses something. And this data is important to get right for regulatory reasons. Fortunately, I know a thing or two about quick checks, so ... I pulled the branch and, at the terminal, applied the expected change patterns to the ...

This post is part of a series showing my working through the 2025 Advent of System Seeing exercises set by Ruth Malan. For background see the introduction .  Days 1-5 Days 6-9 Days 10-16 Days 17-19 Days 20-24  As we reach the final few days of exercises we're into reflection and consolidation of ideas.  Day 20 Task : (1) Look across the past 19 days and draw out concepts related to systems (2) Consider what else you'd like to add (3) Jot down some questions (4) What topic would you like to add, as the focus of another page on your System zine? Components: parts, relationships, boundaries, effects, feedback, change over time, inputs and outputs, failure modes, context, constraints. Tools: zoom in/out, follow a specific path, take actor perspectives, use multiple models, identify needs (and who they belong to), identify causes (and the causes of the causes), focus on the parts of the system that matter today,...

This post is part of a series showing my working through the 2025 Advent of System Seeing exercises set by Ruth Malan. For background see the introduction .  Days 1-5 Days 6-9 Days 10-16 Days 17-19 Days 20-24 This set of exercises is concerned with the location of a technical system within a social system. Spoiler: it only adds complexity. Day 17 Task : (1) Considering the situation you’re exploring: identify systems and their interrelationships. How far out do we zoom? What heuristics do you use? (2) Pick a (socio)technical system to focus on. Write a brief description of its primary purpose. I found the questions in the exercise the most interesting part of it this time. How far out do we zoom? This is the perennial problem in my world; I am always trying to find ways to judge whether I have gone far enough in the dimensions I have identified as relevant and hoping that I identified more or less the correct se...

This post is part of a series showing my working through the 2025 Advent of System Seeing exercises set by Ruth Malan. For background see the introduction . Days 1-5 Days 6-9 Days 10-16 Days 17-19 Days 20-24 This section of the Advent series is largely concerned with material I can't share in much detail,  a practical exercise exploring a real-life scenario at work. I've done the exercises and given at least a little commentary on the value of them here. Day 10 Task : 1. Draw an organization that you have been part of  at least 3 different ways (2) Jot down reflections  (3) Go "meta” and think about the views you drew.   As the task suggests, it's well known that org charts are, at best, an approximation of the way that work gets done in an organisation. The kind of diagram to draw depends on the perspective you want to obtain.  Many of my colleagues don't like Miro, but I love it ...