Hiccupps

  The Association for Software Testing board elections are happening shortly. Terms are two years long but staggered so that half of the board is up for re-election every year. I've just finished my first term and I've decided to stand again, for a few reasons. First, and accuse me of whatever cheesiness you like here, I truly believe in the AST's ethical code and mission : The Association for Software Testing is dedicated to advancing the understanding of the science and practice of software testing according to Context-Driven principles. It's important to me that I remain a practitioner of testing, and I roll my expertise and experience into the context when I practice.  Second, and with another helping from the cheeseboard, the AST is emotionally significant to me. When I started testing it was the organisation that Lessons Learned in Software Testing led me to, and its Black Box Software Testing courses

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 ,  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-- "Do more test cases mean better test coverage?" Simply, no. Less simply, depending on the assumptions you care to make, perhaps. The terms test case and test coverage are loaded, so let's talk about a somewhat analogous pr

  I am a believer in open-notebook testing . I make my work visible to anyone who wants to look at it, while it is in progress. Why? Well, I dislike information silos, publishing keeps me thoughtful about my work and my standards high, and sometimes someone will spot something I've missed or mistaken. But I also want my testing to be friction-free. In this context that has two aspects: I need to be able to (a) record and (b) share what I'm doing with as little impact on my work as I can manage. I've written before about the way I take notes in a text editor using a simple markup language. In my previous job I ran a little script on my testing notes and pasted the output straight into the Mediawiki instance we used. Unfortunately, in my new job we use Confluence. Also unfortunately, I found that support for even its own markup language was unreliable and so I had to find a new route. What I've iterated my way to over the last four months is, agai

I really enjoy lean coffee conversations. I am energised by the rapid-fire topic switches and love it when I get exposure to multiple perspectives. The time-boxed aspect of the activity is a turn-off for some, keeping things relatively shallow, but it's one of the great advantages of the format for me: I know that I'm only investing a certain amount of my time, and it's usually small enough that the return is worth it. All of which is background context for my experience at the first Cambridge Tester Meetup event for over a year , an online lean coffee, this week. I died a little inside when I saw The Future of Testing ticket placed on the board. I felt the pain of internal necrosis spreading as it was voted up. I winced while my pre-frontal cortex withered into a tiny blackened stump at the precise second that Devops, automation, and quality champions were tossed into the discussion. The? Future? Of? Testing? GRRrrr! For as long as we are build

This morning I was delighted to see the long-awaited return of the Cambridge Tester Meetup in the form of an online Lean Coffee!  Here's a few aggregated notes from the conversation in the group I was in. Onboarding of testers in Covid land From the company's side: Looking for tips for getting testers up and running remotely. Structured introduction plan, inluding people, tools, and relevant docs. Encouraging the new team member to complement that with finding their own path. Remember that it's hard being new and remote. Make sure that time to learn and to use the product is available. Try to find some task that can make them feel productive, an early win. Have a buddy with priority and time to answer questions. Set expectations on both sides. From the onboarder's side: Be prepared to ask questions. Self-motivation is really important. Set some goals for yourself (to get that achievement hit). Be prepared for it to be harder. Be brave (even if you don't feel it). T

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 just finished reading Thinking in Systems: A Primer by Donella Meadows. It's not a new book but I'd managed to be unaware of it until recently when Marianne Bellotti mentioned it on her podcast, Marianne Writes a Programming Language .  Bellotti is writing a programming language (duh!) for modelling system behaviour using the concepts of stocks and flows, inspired by Meadows' book. The image at the top gives an idea of how such models can work, notably making explicit the feedback relationships for resources in the system, and allowing modellers to reason about the system state under different conditions over time. I have been aware of systems models similar to this since I first saw Diagrams of Effects in in Quality Systems Management Volume 1: Systems Thinking by Jerry Weinberg. Weinberg's book, and other reading I was doing early in my career as a tester, inspired me to look deeply at the systemic context in which the software I'm working on sits and