Skip to main content

Sign of the Times

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 loud when I saw that page. It's one of those Aha!/Haha! moments that of discovery/comedy that I dove headfirst into later with Your Testing is a Joke.

2013 How-abouts and What-ifs

Yeah, this still resonates: "As a tester, as someone who invests time trying to balance the cost of applying effort, and where, against the risk of not applying it, it is humbling and worrying to think that the results of my work may be as much, or even more, down to luck as to anything I do or did."

2014 McElligot's Rule

Dr Seuss remains a favourite and I'm just now reminded that I invoked another of his books, possibly my favourite, in Be a Which-What-Who? a few years after this. I love finding inspiration and connections in unexpected places, and I love following the threads that those unprompted ideas throws up.

2015 Practitioner Makes Imperfect

I got a lot of value from Twitter around this time, mostly as a cheap way to be exposed to things I wouldn't otherwise find, things that make me think. This post gives one example and I still follow GeePaw, although on Mastodon these days. 

2016 Cambridge Lean Coffee

Also valuable at this time, the local testing community ran a monthly morning Lean Coffee, an evening meetup, and the CEWT peer conference. I typically summarised points from the Lean Coffee conversation I was in, and this post covers these topics: exploratory testing, flaky legacy automation, starting strategies, and Death to Bug Advocacy.

2017 Where Did All The Women Go?

I took my two daughters to the Centre for Computing History's exhibition on women in computer gaming. I wasn't trying to encourage them into computing but instead to reinforce an idea I've tried to instil in them forever: that they should feel free to try anything they want to. On a personal level I enjoyed this line particularly, then and now: "Karen Spärck Jones ... a pioneer in Computational Linguistics ... was often quoted as saying computing is too important to be left to men." 

2018 Dublish People

My first conference keynote was at SoftTest in Dublin and this post collects my sketch notes from the other talks and a letter from my youngest daughter detailing her research into the local population. Seeing her work again brings me a lot of pleasure.

2019 What About Business Value?

Business value is a long-term interest of mine and this post is my notes from a talk at the Cambridge Agile Exchange that proposes adding business value points to work tickets. The question I posed there still fascinates me today: "can we assign a value to the pieces of work, and prioritise and order work such that we deliver the (perceived) most valuable pieces at the (perceived) most valuable times?" 

2020 Context-Driven or What?

This one is me reflecting on an interview I did for Testers' Island Discs. Writing my thoughts down and exploring them is a valuable tool for me, it allows me to work through angles in a way I find hard to keep track of in my head. Favourite quote here: "Where are the edges of a context?"   

2021 Context Above All

Context again (because of course) but also echoes of the business value post, when I find myself writing "we need to talk about investing the right amount of effort in understanding the context to guide testing of the right kinds of things, in the right kinds of ways, at the right kinds of times, for the right kinds of costs." 

2022 Step on It

One of my earlier posts on testing using model-based walkers making random choices and invariant assertions. In it, I invoked an analogy with running around a minefield wearing heavy boots (yeah!) and then (to my own surprise reading it back) researched the origins of the minefield analogy in software testing itself.

2023 Play to Play

This one is a review of Rick Rubin's book, The Creative Act. I loved it and see it in my work — which I consider creative — but it a tighter edit would help gems like this shine more brightly: "All art is a work in progress. It's helpful to see the piece we're working on as an experiment. One in which we can't predict the outcome. Whatever the result, we will receive useful information that will benefit the next experiment."

2024 Not a Happy Place 

You won't find me emotionmaxxing in Hiccupps but I have written about feelings, problems, and fears from time to time. This post describes a strategy I continue to use for centering myself and I'd call out a couple of earlier posts too: Unsung Love Song (which moves me still) and Speaking Easier.

2025 The Momentum of Doing It

I had forgotten this one from 12 months ago (not unusual, but given the content it's amusing) on the topics of blogging, anniversaries, and reflection. Hmm. Reading it back, I like that it's open: a document of what I've done, what I got from that, where I'll go next, and the things that I don't know or understand around all of it.

--00-- 

Sampling fifteen posts gives a flavour of the content over time, but I also wanted a wider perspective so I pulled the labels from all 720, mapped them to years of blogging, and sliced the data a few ways. All of the visualisations had flaws, but this one feels like it tells a reasonable story:

The three columns are blocks of five years each, roughly corresponding to phases of my working life: as relatively new tester and test manager; as a manager of managers and very active test community member; and as an experienced individual contributor.

Grey boxes show topics that were used heavily across all periods, others come and go as I follow different interests and professional needs. Management ramps up then disappears, likewise local community engagement after Covid, being on the board of the Association for Software Testing cuts across the last two blocks, while exploratory testing and automation leap to the top of the list when I get back to more concentrated hands-on work. 

Although I assigned the labels based on what I felt was relevant at the time, there are weaknesses to consider. For example, some labels were added later and I haven't typically applied them retrospectively, I almost certainly haven't used any of them consistently, and there are fewer posts in the later years so raw label counts might skew the analysis. 

But, as the labels show, we live in an age of AI and I've taken a professional interest in it in recent times, so I got Claude to look at all the posts and create a new set of labels given the benefit of hindsight. This is how that distribution looks: 

Caveats galore here of course (and I leave them as an exercise for the reader) but I sampled a couple of the categorisations and found them at least defensible. That said, I wouldn't stake anything of value on these results, so consider them another compromised lens.

Something this view shows that chimes with my intuition is that exploratory testing is spread across the whole period. I just didn't start using that label myself until later. More surprising is test strategy, although that becomes less unexpected when Claude's matching criteria are exposed: deciding what to test, coverage, risk, test planning, oracles, test design, when to stop. OK, yes all those things.

--00--

So what do I take from this navel-gazing? Well, I'm pleasantly surprised that I wasn't embarrassed by the early posts and I can see a consistency of thought and approach across the years, including openness to ideas, accepting my own failings, context-driven testing, seeing value in writing and sharing, finding the joy in testing, and the pleasure of a pun. I've also forgotten a lot.

I knew that I'd varied my focus over time and it was fun to compare my memory of that with my labels and then again with the generated labels. My take-away there is that what I feel the post is "about" at the time I write it outweighs trying to label comprehensively. I don't feel like I need or want to change that.

I've often pondered who I'm writing this blog for. Right now, I'm pretty confident I'm writing it for me. For sure, I let others know when a new post is up because enough people have told me over the years that they like to read them, but I'm not striving for views and likes and I definitely don't feel like I have to create content or boost a brand. I'm writing about the stuff I want to write about, when and how I want to write it.

A thought just struck me. I feel like I've generally avoided telling readers what they should do, although it's not obvious from anything above. So I searched the blog for the word "advice" half-hoping it wouldn't appear at all. Naturally, it appears plenty of times. One of the results is Testing Forays where this list appears, the bullets are the advice I was giving myself while testing back in 2014:

  • Ask questions - including of yourself
  • Answer questions - including your own
  • Act - on what you now know, or to find what you need to know
  • Again? - there might be more to do here 

You know what? I'd forgotten that too, but I like reading it afresh and I'm happy to write it again. I'm like the sign at the top, I guess: showing my age but turning up and doing the job like I always did.
Image: Deborah L Carlson on Unsplash  

Labels:

Popular posts from this blog

Meet Me Halfway?

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answ...
Read more

How do I Test AI?

  Recently a few people have asked me how I test AI. I'm happy to share my experiences, but I frame the question more broadly, perhaps something like this: what kinds of things do I consider when testing systems with artificial intelligence components .  I freestyled liberally the first time I answered but when the question came up again I thought I'd write a few bullets to help me remember key things. This post is the latest iteration of that list. Caveats: I'm not an expert; what you see below is a reminder of things to pick up on during conversations so it's quite minimal; it's also messy; it's absolutely not a guide or a set of best practices; each point should be applied in context; the categories are very rough; it's certainly not complete.  Also note that I work with teams who really know what they're doing on the domain, tech, and medical safety fronts and some of the things listed here are things they'd typically do some or all of. Testing ...
Read more

Notes on Testing Notes

Ben Dowen pinged me and others on Twitter last week , asking for "a nice concise resource to link to for a blog post - about taking good Testing notes." I didn't have one so I thought I'd write a few words on how I'm doing it at the moment for my work at Ada Health, alongside Ben. You may have read previously that I use a script to upload Markdown-based text files to Confluence . Here's the template that I start from: # Date + Title # Mission # Summary WIP! # Notes Then I fill out what I plan to do. The Mission can be as high or low level as I want it to be. Sometimes, if deeper context might be valuable I'll add a Background subsection to it. I don't fill in the Summary section until the end. It's a high-level overview of what I did, what I found, risks identified, value provided, and so on. Between the Mission and Summary I hope that a reader can see what I initially intended and what actually...
Read more

The Best Programmer Dan Knows

  I was pairing with my friend Vernon at work last week, on a tool I've been developing. He was smiling broadly as I talked him through what I'd done because we've been here before. The tool facilitates a task that's time-consuming, inefficient, error-prone, tiresome, and important to get right. Vern knows that those kinds of factors trigger me to change or build something, and that's why he was struggling not to laugh out loud. He held himself together and asked a bunch of sensible questions about the need, the desired outcome, and the approach I'd taken. Then he mentioned a talk by Daniel Terhorst-North, called The Best Programmer I Know, and said that much of it paralleled what he sees me doing. It was my turn to laugh then, because I am not a good programmer, and I thought he knew that already. What I do accept, though, is that I am focussed on the value that programs can give, and getting some of that value as early as possible. He sent me a link to the ta...
Read more

On Herding Cats

Last night I was at the Cambridge Tester meetup for a workshop on leadership. It was a two-parter with Drew Pontikis facilitating conversation about workplace scenarios followed by an AMA with a group of experienced managers. I can't come to work this week, my cat died. Drew opened by asking us what our first thoughts would be as managers on seeing that sentence. Naturally, sadness and sympathy,  followed by a week ? for a cat ? and I only got a day for my gran! Then practicalities such as maybe there's company policy that covers that , and then the acknowledgement that it's contextual: perhaps this was a long-time emotional support animal . Having established that management decisions are a mixture of emotion, logic, and contingency Drew noted that most of us don't get training in management or leadership then split us into small groups and confronted us with three situations to talk through: Setting personal development goals for others. Dropping a clange...
Read more

Reasonable Doubt

In Your job is to deliver code you have proven to work  Simon Willison writes: As software engineers we ... need to deliver code that works — and we need to include proof that it works as well.  He is coming at this from the perspective of LLM-assisted coding, but most of what he says applies in general. I think this is a reasonable consise summary of his requirements for developers: Manual happy paths: get the system into an initial state, exercise the code, check that it has the desired effect on the state. Manual edge cases: no advice given, just a note that skill here is a sign of a senior engineer.  Automated tests: should demonstrate the change like Manual happy paths  but also fail if the change is reverted.  He notes that, even though LLM tooling can write automated tests, it's humans who are accountable for the code and it's on us to "include evidence that it works as it should." Coincidentally, just the week before I read his post I told one of my...
Read more

Vanilla Flavour Testing

I have been pairing with a new developer colleague recently. In our last session he asked me "is this normal testing?" saying that he'd never seen anything like it anywhere else that he'd worked. We finished the task we were on and then chatted about his question for a few minutes. This is a short summary of what I said. I would describe myself as context-driven . I don't take the same approach to testing every time, except in a meta way. I try to understand the important questions, who they are important to, and what the constraints on the work are. With that knowledge I look for productive, pragmatic, ways to explore whatever we're looking at to uncover valuable information or find a way to move on. I write test notes as I work in a format that I have found to be useful to me, colleagues, and stakeholders. For me, the notes should clearly state the mission and give a tl;dr summary of the findings and I like them to be public while I'm working not just w...
Read more

Why Test, Test What, Then How?

There was a time when testing was all about the mnemonics . Well, we had no AI back then so thinking about our human craft and how to share what we had learned using our human intelligence with other engaged humans for later recall in their human heads seemed important. But this post isn't about dumping on AI. It isn't about mnemonics either even if WTTWTH does look like something that'd fit well into that ancient world.  No, this post is just a snappier version of what I said to my team this week when I was walking through some testing I'd done the day before. It was concerned with a change to a particular turn in the dialog system we're building where multiple variables are in play, some populated by an external call to an LLM service.  I wanted to make the point that the bulk of the testing work was done in the research I did and the spreadsheet I made, not in the interaction with our product. That spreadsheet was the result of me looking in our service's cod...
Read more

Exploratory Testing Reimagined

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...
Read more

For Fix Sake

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 ...
Read more