Hiccupps

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

A colleague pinged me the other day, asking about an "ideal test plan" and wondering whether I could suggest something. Not without a bit more information, I said. OK, they said. Who needs the plan, for what purpose? I asked. Their response: it's for internal use, to improve documentation, and provide a standard structure.  We work in a medical context and have strict compliance requirements, so I wondered aloud whether the plan is needed for audit, or to show to customers? It's not, they replied, it's just for the team. Smiling now, I stopped asking questions and delivered the good news that I had what they were looking for. Yes? they asked, in anticipation. Naturally I paused for dramatic effect and to enhance the appearance of deep wisdom, before saying: the ideal plan is one that works for you.   Which is great and all that, but not heavy on practical advice. --00-- I am currently running a project at the Association for Software Testing and there is a plan ...

Elisabeth Hendrickson was on The Confident Commit podcast recently talking about systems and flow, and her new Curious Duck project. Towards the end she was asked a question about individuals, teams, and judging success. Her answer was simply super: The team has to be the agent of work. There are many reasons for this but it's a key tenet for me in leading any organisation. If the team is the agent of work then what that means is the individuals absolutely contribute to it and deserve to have growth paths and career paths and be rewarded for their contributions, etc. So individuals matter very much. However if somebody decides to go on a four-week vacation to Bali, work cannot stop on the whatever-it-was, they can't be the single point of failure. So if you have the team as the agent of work, the team can swarm on things, the team can have a set of working agreements internally for how they're going to accomplish things. There's plenty of space for the individual but...

I've listened to every episode of Gene Kim 's Idealcast , a podcast about "the important ideas changing how organizations compete and win." If that terse statement sounds desert dry to you, then think again, the show is a wide open ocean of practical experience and considered theory. I particularly enjoyed the one with Elisabeth Hendrickson whose playbook has chapters on management, software development, people development and more, along with the testing chops of Explore It! that she's particularly known for in our field. Gene's presentation style is that of a knowledgeable friend, making space for his guests to lay out their perspective on a topic, and giving each insight a big "yes, and". He injects verbal sidebars into the podcast from time to time, pausing the interview to zoom in on a point that was made in passing and direct the listener to references that will give background, or talking about how a specific example made the concept click ...

Last week I started to see tweets with the simple text "Like this tweet and I’ll write something about you." The replies, all by the author of the tweet, were fascinating: numbers apparently representing a person followed by praise, reminiscence, and gratitude. Elisabeth Hendrickson's thread is a particularly uplifting example.  I was intrigued, so I liked a couple of them. Shortly afterwards I got a direct message which explained that the tweet was part of a project for suicide prevention month with the aim of celebrating people while they are alive. If I wanted to join in I should provide a number to represent myself so that the author could write something about me, and I was invited to do the same for others. I'm naturally cautious of these chain letter-like activities and I'd heard of Suicide Prevention Day and Week , but not month. However, I found that September does appear to be promoted as suicide prevention awareness month by the National Alliance on M...

This post is a prettied-up version of the notes I made in advance of my talk, How To Test Anything, at the OnlineTestConf 2020 this week. Here's the abstract: Sometimes you’re asked to start testing in a context that is not ideal: you’ve only just joined the project, the test environment is broken, the product is migrating to a new stack, the developer has left, no-one seems quite sure what’s being done or why, and there is not much time.  Knowing where to begin and what to focus on can be difficult and so in this talk I’ll describe how I try to meet that challenge. I’ll share a definition of testing which helps me to navigate uncertainty across contexts and decide on a starting point. I’ll catalogue tools that I use regularly such as conversation, modelling, and drawing; the rule of three, heuristics, and background knowledge; mission-setting, hypothesis generation, and comparison. I’ll s...

The topic at CEWT #7  last weekend was Dirty Testing Secrets. I decided to present something reasonably provocative as a conversation starter. I think it worked. The essay below is a pretty version of the notes I prepared in advance. --00-- Quality Assurance. QA. It's getting less common, but it's still not unusual for people in software to talk about getting something into QA or to asking us to QA their stuff. I've worked hard over the years at our place to spread the word that I don't think of my team in that way. I do an induction for all new employees and explain how testing is a creative and intellectual activity, not a checkbox ticking drudge. Sadly, I still encounter career testers who think that their role is to confirm that requirements are met and no more. But my sense is that that's an open secret rather than a dirty one. This isn't a dirty secret either, although it might be a surprise to some: That's not to say that we ar...

Commiserating once again with a colleague about the frustrations of testing a complex (computer) system within a complex (human) system I said that it reminded me of the Fighting Fantasy books I used to  play as a boy. In them, non-linear storylines are generated by choosing, or rolling dice to determine, how the story proceeds. Characters are typically  engaged in some kind of quest, such as collecting gems, and  have some attributes, such as strength, which are affected by interactions during the game.  As a little bit of amusement for myself I tweeted a few words that reflected something of the situation I found myself in at that moment. Then now and again over the next couple of weeks I extended it (fictitiously!) as if I was playing out a book. I've compiled the whole thread here.  62. You upgrade and rerun the test. Presently your client is wedged. Server logs have stopped and 'df -h' shows disk at 100%. You can start an...

I spoke at UKSTAR 2018 this week, an eight-minute talk in a Storytelling track. This post is a prettied-up version of the notes I made for it along with some of the slides. The full slide deck is in the Media page . My story is called The Anatomy of a Definition of Testing. It's not a suspense story though, so I'll give you the definition right up front: Testing is the pursuit of relevant incongruity. That is, for me, testing is the pursuit of relevant incongruity. But how did I get there? Well, the journey started with Explore It! by Elisabeth Hendrickson, a great book about exploratory testing which has, near the beginning, this definition: Tested = Checked + Explored It's finessed a little by Neither checking nor exploring is sufficient on its own and the idea that testing is to ... interact with the software or system, observe its actual behavior, and compare that to your expectations. Interestingly, the definition doesn't really play a sig...

This is a prettied-up version of the notes I based my CEWT #3 talk on. Explore It! by Elisabeth Hendrickson is a classic book on exploratory testing that we read - and enjoyed - in the Test Team book club at Linguamatics a few months ago. Intriguingly, to me, although the core focus of the book is exploration, I found myself over and again drawn back to a definition given early on (p.6): Tested = Checked + Explored where, to elaborate (p.5): Checking [is testing] that you design in advance to check that the implementation behaves as intended under supported configurations and conditions. Exploratory Testing [is] simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next. And both of these aspects are necessary for testing to have been performed (p.4-5):  ... you need a test strategy that answers two core questions:  1. Does the software behave as intended under the conditions it’s s...