Hiccupps

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

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   In this set of exercises, the idea of feedback is introduced. Feedback is at the heart of systems thinking because we humans seem to be primed to view the world as a simple linear cause-leads-to-effect machine in which only the causes and effects that matter are those that (a) we desire or (b) are glaringly obvious. Day 6 Task : Watch a video on causal loops and take sketchnotes.   I know and like this kind of diagram ( Be a Quality Detector ) but  I have struggled to build them for any system that I've looked at. In particular, I find the formal labelling of positive and negative loops to be more of a dark art than a science. The good news is that informality has proved sufficient for...

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 The initial exercises introduce some core concepts and a couple of approaches to modelling, and encourage us to think about our work and the system we're looking at. Day 1 Task : (1) Draw a Bubble Diagram of a bicycle (2) Sketch a bicycle from memory (3) Pick a key capability [and use] sketches and words to explore and convey how it works (4) Reflect on what you learned.  I'm comfortable doing what I'd call "factoring" which tries to find different angles or features or affordances of a thing that could be useful seams to follow when testing. I've used plenty of tools, such as the Six Thinking Hats or SFDIPOT to help with that, and represented the outcomes with a mi...

My friend Patrick Prill posted some of his System Seeing practices at the start of the year. He is a systems thinker and nobody's fool so I guessed that if he valued Ruth Malan's Advent(ure) in System Seeing series of daily exercises it would be worth taking a look. I did. I agreed. I bookmarked it and then ... And then months later I came back to it. Although the activities are cast as an Advent series, in the spirit of Advent of Code , there's nothing seasonal about them and I can now say, having completed them, the things they talk about, the skills they encourage us to exercise, and the questions they ask are timeless, at least while there's still humans on this planet. This is how Ruth Malan introduces them: Each day of Advent ... there is an activity that is focused on the concepts and practices of system perceiving and understanding. This activity has instructions (which often include a visual canvas or mode...

You know when you suddenly discover that you have an internal model of a chunk of the world that's been guiding your thinking and behaviour but you never realised?  I love that. The most recent instance for me was a couple of weeks ago when asked what problems I have with test data at work. That's when it became obvious that I have three broad categories of test data, and want something different from each of them. Of course I do! Duh. And why didn't I realise this before? Not sure. Perhaps I've never framed that kind of high-level abstract question, Maybe more often I'm interested in test data for the actual problem in front of me? Whatever, here's my initial draft of what I think I think... Data for specific logic. I use this in traditional regression tests that need a static expected result: unit tests, for instance. I see a lot of examples that have clearly grabbed runtime application data that's the right shape and b...