Hiccupps

  This month marks 13 years of Hiccupps and this is the 660th post.  It's traditional for me to mention in my anniversary posts that, when I started the blog, I tested my interest in blogging by challenging myself to write around a post a week for year. I usually then also say that I'm amazed I've kept that rate up in the intervening years. This year is no exception, although I am particularly surprised because my personal life is getting increasingly difficult and I am finding less time and energy for blogging. A non-surface glance at the numbers reflects this: 40 weeks into 2024 and 24 posts. If I cared about such things, I might worry that Blogger's unreliable numbers suggest that someone (or more likely some thing ) is visiting more as I do less. But I don't care. Instead, as I look at this graph my testing head wonders whether this possible inverse relationship would mean that I could get a very large number of views by re

  The other day my dad showed me a copy of my BSc. dissertation that he's had in a folder somewhere since 1992. I remembered vaguely that it was about drawing trees and plants using L-Systems   to describe the structures and Logo to render them, but had no strong memory of what I actually did. Flipping through it, I saw that I learned enough C , yacc , lex , and Postscript to cobble an implementation together and that the trees, although only greyscale line drawings, could model aspects of natural growth patterns in a convincing way. A pleasant trip down memory lane, for sure, until a what the ...? moment as I came across a (short) section on testing. I have no recollection of learning testing at university and there are no testing resources in my bibliography. Did I just make it up as I went along? Well, as we all know, anyone can test, so I thought I'd look at what approaches the anyone who was the callow me tried. I pulled out evidence from the brief text, trying not to ov

Why wouldn't you just give up? The system under test has poor testability which means that the testing you'd like to do will take longer and the resolution of your findings will be lower than you'd like. So do you give up, battle through, wait for someone to add what you need ... or change the product yourself ? There are potential risks to that last option, of course, because (duh!) you're changing the product. But there are potential wins, too, because you're getting the data you want earlier and can give richer feedback to your stakeholders. I took that route this week.  The service I'm looking at is essentially a pipeline of steps, each of which calls out to a third-party service and post-processes the result, set up like this: result1 = step1.run(input) result2 = step2.run(result1) result3 = step3.run(result2) I wanted the response time for a large number of requests against its API, which I can get easily from the client

  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

The Association for Software Testing has been crowdsourcing a book, Navigating the World as a Context-Driven Tester , for the last three years. Over that time 28 questions or statements about testing have been posed to our community and the various answers collected and collapsed into a single reply. Lee Hawkins, the coordinator of the project, has just blogged about the experience in The wisdom of the crowd has created an awesome resource for context-driven testers . He pulled some statistics out of the records he's kept showing the level of interest in each question or statement, measured by the number of responses from the community. That's the red bars on the chart at the top, ranging in value from 4 to 28. I replied every single time Lee posted, with a very specific mission in mind: 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 fa

  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-- "Pair and ensemble testing look like a waste of time and resources to me. What do you think?" You're right! Sometimes.   But also not pairing or ensembling is a waste of time and r

The big story in IT right now is Crowdstrike 's unfortunate update that prompted millions of Windows machines to BSOD and caused chaos in critical infrastructure around the world. Actually, that's not just big, it's BIG or B. I. G. or maybe B! I! G! and it's provoked loads of speculation about the hows and whys and what-should-haves and what-didn'ts. But even on a week without that scale of fail, even on a week where nothing untoward happened on any computer anywhere, the observation I'm sharing here probably wouldn't merit much coverage.  This is it: Do you see? Just under the orange bar, the word OLIVE. Why? Don't get me wrong, I like olives. I just don't expect to see them on the BBC Sounds player while I'm setting myself up to listen to England win the cricket at the weekend. Of course, if you look a bit closer and wait a second or two, you'll see that there's a slight vertical alignment difference between the O and LIVE and the th

Last weekend I participated in the LLandegfan Exploratory Workshop on Testing (LLEWT) 2024, a peer conference in a small parish hall on Anglesey, north Wales. The topic was communication and I shared my sketchnotes and a mind map from the day a few days ago. This post summarises my experience report.  Express, Listen, and Field Just about the most hands-on, practical, and valuable training I have ever done was on assertiveness with a local Cambridge coach, Laura Dain . In it she introduced Express, Listen, and Field (ELF), distilled from her experience across many years in the women’s movement, business, and academia.  ELF: say your key message clearly and calmly, actively listen to the response, and then focus only on what is relevant to your needs. I blogged a little about it back in 2017 and I've been using it ever since. Assertiveness In a previous role, I was the manager of a test team and organised training for the whole team

This weekend I was at LLEWT 2024, a peer conference on Anglesey , north Wales, discussing communication. Given the day jobs of the participants, it was no surprise that the experience reports and the conversations that followed them mostly focussed on software development contexts.  Notes from my presentation are in Express, Listen, and Field . I made sketchnotes (below) for each presentation and a mindmap (above) to try to summarise the whole. Without much reflection yet, I guess I would pull these common high-level threads from the day: There are multiple reasons that communication fails  ... like, duh! ... but having multiple strategies for framing a message can help ... and having multiple tactics for delivering a message can help too. Understanding what you want from an interaction is key ... so setting the context to make that more likely is wise ... which might mean meta-conversation, being transparent, or changing your approach ...