Hiccupps

I'm enjoying The Vernon Richard Show  a lot recently because the vibe Vern and Richard have created is one where two knowledgeable and experienced mates talk around a topic they are both interested in with curiosity and open minds.  Also, there's less football than there used to be. This week's show is titled When Everything Sounds Like Testing… How Do You Explain What You Really Do?  and sees the pair discussing the meanings of quality assurance, quality engineering, testing and other related terms. There's no firm conclusions, and enough left unsaid that they're carrying the dialogue over into the next episode, but I was still interested to see these two models put forward: In the first, proposed by Vernon, quality engineering consists of preventing bugs (QA) and detecting bugs (testing). In the second, floated by Richard almost in spite of his better judgement, quality assurance is the holistic term. In this ver...

  Over on the Agile in the Ether  Slack instance one of the Ethernets recently asked: MoSCoW: Does anybody have a simple way of explaining when items should be Must vs. when they should be Won't? Is it really as simple as whether it's an inclusion or an exclusion of the item? MoSCoW  is a basic approach to grouping project project work into buckets graded by priority: M: must have S: should have C: could have W: won’t have (for now) I'm sure every one of us has been in conversations where the buckets are filled and then stakeholders say they're all emergency-level important, but that's not today's problem. In this case the questioner had been burned by people twisting the words in unhelpful ways: " must not do ..." (i.e. won't) or " won't  do without ..." (i.e. must) which only makes the often fraught prioritisation discussions even less pleasant.  I have found MoSCoW to be useful so I share...

The theme at  LLEWT this year was Rules and constraints to ensure better quality.   My experience report concerned a team I'd been on for several years which developed (bottom-up) a set of working practices that we called team agreements.   The agreements survived "natural" variation such as people leaving and joining and even some structural reorganisation which preserved most of the team members but changed the team's responsibilities or merged in a few people from a disbanded team. The agreements did not, however, persist through a significant round of (top-down) redundancies where the team was merged with two others.  I'm interested in thinking about the ways in which constraints on how people work affect the work and whether there are patterns that could help us to apply the right kinds of constraints at times they are likely to be useful.  I'm going to use this post to dump my thoughts. My starting po...

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. 

Maaret Pyhäjärvi  posted the quote above on LinkedIn a few weeks ago. It speaks strongly to me so I asked Maaret if she'd written more (because she's written a lot ) on this specific point. She hasn't, and the sentence keeps coming back into my head and I'd like to understand why, so I thought I'd try to write down what I take from it. I think it's easy to skim read as some kind of definition of exploratory testing but that would be a mistake in my eyes.  Testing by Exploring  summarises how I felt last time I went into the definition in any depth and, for me, Maaret's quote is concerned with the why  but says nothing of the what or how . But let's say we have a shared definition of exploratory testing, would I make this statement this baldly generally? No, I probably would not. Why? First, it's written in very personal terms (" my time", "the best testing I could") and, second, as a  contex...

I attended LLEWT 2025 at the weekend. LLEWT is a peer conference  hosted by Chris Chant, Joep Schuurkes, and  Elizabeth Zagroba in Llandegfan  on the island of Anglesey, North Wales. This year's theme was Rules and constraints to ensure better quality: Think of things like WIP limits, zero bug policies, trunk-based development, not allowing any form of interprocess communication except through service interfaces that are externalizable, or just firing all your testers so the devs have to step up. (Yes, not all of these are a good idea all of the time.) Some terms related to this theme are forcing functions, poka-yoke, and behavior-shaping constraints. Basically we're looking for any rule or constraint you put in place to get to better quality. (Some systems thinking might be required.) The format of LLEWT encourages proposals for experience reports on the theme, takes feedback on the proposals, an...

I'm been working on an application that will orchestrate data from multiple services. As the developers add clients for those services, they have been writing integration tests and, naturally, many of them use mocked data. Mostly the data consists of non-trivial JSON response bodies full of domain-specific terminology captured during interactions with the other services. Consequently, many of our tests reflect this complexity and domain-specificity by asserting on its data structures and particular terms. This is functionally fine, but problematic for readability because test intent can be hidden in a mass of incomprehensible word salad. Again, this is usually fine for the author when writing the test because the intent is front of mind but it's problematic for other readers, including the author later. I have been vocal about this drawback and today one of my colleagues asked me to summarise my prescription for it. Without thinking I said this, and I ...

I've spoken to a couple of friends recently about testers they know who continually express a desire to "learn automation" and continually fail to begin learning anything at all.  A common behaviour is to find something that blocks the goal. For one friend, the testers wanted a course on automation and ring-fenced time each week to work on it. Without those, they said, it was obvious that no learning could happen. For the other friend, an interesting natural experiment had taken place. There had been a couple of weeks at his place where the wiki, task management system, and source control service had been unavailable. Staff who usually complained about not having time to study anything because they were too busy moving an endless stream of tickets across boards were told to spend that time on self-learning.  Do you think they mostly did? No need to answer. I can empathise. From a standing start a distant goal can look very intimidating. Of course putting off starting does...

We are generally not the target users of the software products we work on.  That's not to say we never use our applications or that we have no interest in those who do, but mostly we rely on feedback from elsewhere to tell us whether needs are being met.  Sure, as testers we'll interact with the software and maybe even consider ourselves to be a proxy for users. Yes, we'll probably have people in product and business roles translating, or inventing, customer requirements for us. And, yes, perhaps we'll even dogfood the stuff we build sometimes, to some extent. I've lost count of the number of times I've asked developers whether they ran the software after their changes and been told that the tests pass. I've lost count of the number of colleagues I've had who work on a service and have little or no idea what clients it has and what kinds of tasks their users are trying to complete or why. I've lost count of the number of times I've been in argume...