Hiccupps

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

In Looking Good, Testers!  I made the case that testing is about looking and that delegating the looking to someone or something  else involves a risk calculation: do you both understand the task the same way, is the third party likely to carry out the task in the way you requested, how easily can you check any results they give back, could they complement you in some way, how will you keep your knowledge and skills up to date if you don't do this task any more, how much does this task matter, how much do you care about any of that, ...? I didn't say anything there about selecting what to look at or for  ... and I'm not going to talk about it here either because it's essentially the whole of testing. I will note one thing, though: to find things other people don't find,  look where other people don't look .  What I do want to cover here is looking at things that, arguably, you don't need to.  My team was recently asked to add a new layer to a service we ow...

In yesterday's Angry Weasel newsletter, Leadership is a Constant Experiment , Alan Page was explaining how, as a leader, he gets better results by trying things intentionally, in public, in a safe way: But in real work, confidence isn’t the superpower. Curiosity is.  I feel this too, although confidence, or the appearance of it, can get you a good way up the greasy pole, if that's your chosen destination.  In a post on LinkedIn today, John Cutler made an analogy between a software development teams and a restaurant kitchen where busyness is not a useful metric, and success means that great food is delivered as ordered in a timely fashion. He sadly concludes that: ...  in software, effort is easy to generate, activity is easy to justify, and impact is surprisingly easy to avoid. This is a tragedy that plays out over and over. My primary goal in software is to help us to metaphorically put the right food on the right plates on the right table at the right time more oft...

I'm slowly learning German ... for fun, believe it or not.  To limit my time commitment I've been mostly studying with lessons on apps or in-person supplemented by YouTube, ChatGPT, DeepL, blogs, an ancient CD-based box set that my well-meaning parents bought in a charity shop, subtitled German-language films and ... Peppa Wutz.   I've pushed ahead in some areas, for example by completing Babbel lessons all the way to  B2  even though I'm nowhere near speaking at that level, and starting again at  A1  even though I'm well past it. Being exposed to the advanced content can give some useful context, and redoing the basics can cement understanding, reinforce learning, and make connections that were missed the first time around. What I wasn't doing was rote learning verb conjugations, grammatical structures, or vocab lists. And that was fine for a long time, at least until I got good enough to have simple conversations...

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

A few weeks ago, in A Good Tester is All Over the Place , Joep Schuurkes described a model of testing work based on three axes: do testing yourself or support testing by others be embedded in a team or be part of a separate team do your job or improve the system It resonated with me and the other testers I shared it with at work, and it resurfaced in my mind while I was reflecting on some of the tasks I've picked up recently and what they have involved, at least in the way I've chosen to address them. Here's three examples: Documentation Generation We have an internal tool that generates documentation in Confluence by extracting and combining images and text from a handful of sources. Although useful, it ran very slowly or not at all so one of the developers performed major surgery on it. Up to that point, I had never taken much interest in the tool and I could have safely ignored this piece of work too because it would have been tested by ...

    Yesterday, reading The Year Without Pants by Scott Berkun, this leapt off the page at me:  Diversity of skill makes people self-sufficient. It's in a paragraph about the culture at Automattic, the people behind WordPress, when Berkun worked there around a decade ago. The paragraph continues: "They didn't need much help to start projects and were unafraid to learn skills to finish them ... They weren't afraid to get their hands dirty in tasks that in a mature engineering company would span the turf of three or four different job titles. That lack of specialization made people better collaborators since there was less turf to fight over." Last week at work I observed that my team's build pipeline was broken. I do not enjoy investigating this kind of infrastructure problem. The company Jenkins setup has a complex ecosystem with many moving parts, my mental model of how all the bits are interconnected is fuzzy, and in any case all the bits keep changing. The ...

  The testers at work had a lean coffee session this week. One of the questions was  "I like testing best because ..." I said that I find the combination of technical, intellectual, and social challenges endlessly enjoyable, fascinating, and stimulating. That's easy to say, and it sounds good too, but today I wondered whether my work actually reflects it. So I made a list of some of the things I did in the last working week: investigating a production problem and pairing to file an incident report finding problems in the incident reporting process feeding back in various ways to various people about the reporting process facilitating a cross-team retrospective on the Kubernetes issue that affected my team's service participating in several lengthy calibration workshops as my team merges with another trying to walk a line between presenting my perspective on things I find important and over-contributing providing feedback and advice on the process identifying a...

  If only we knew ... When our testing is essentially the same eyes looking through the same lens at the same thing in the same context in same way over and again then we are limiting the extent to which we can learn about our product. If we aspire to know more, then we should use different eyes and different lenses and look in different ways at different aspects of the system under test in different scenarios. Easy to say, of course. But how to do ? Engage with what's happening elsewhere in our teams, in other teams, in our companies, in our domains, in the tech our companies use, in the testing community and industry, and in other areas relevant to our contexts. If only we new ...  We will find people, tooling, approaches, or knowledge that could help us do a better job. We will make opportunities to try those new things and invest in the ones that look promising.  We will find that what we knew wasn't as much as we thought. Image: https://flic.kr/p/2mz3krH

The other day I got tagged on a Twitter conversation between a couple of my colleagues, Ben Dowen and Dan Ashby , which ended with Ben citing me as an example: But there is a trap, in that a Dev who Tests, or Tester who codes both risk becoming Test Automators ... The counter argument is Testers who code can do as @qahiccupps does, and use and build tools to explore. A jumble of thoughts tumbled out as I read it and here they are, in no particular order. It is flattering to be mentioned but I'm far from the only person doing this. Maaret Pyhäjärvi   and Rob Sabourin are vocal about the value it can bring and go out of their way to tell and teach others how to get it. Ben is right when he says I use coding as a tool, and as a tool factory. It's a means to an end. Coding itself doesn't give me a lot of pleasure. Having created a useful thing gives me an enormous amount of pleasure. I am not a great developer. But then I rarely need to be.   Yes, I have made bug fixes that...

This month I've been taking the Bug Advocacy course at the Association for Software Testing . It's been ten years since I took the introductory Foundations course, the first in the Black Box Software Testing series , and with this degree of hindsight I can see how fundamental that was in how I like to test. I've done plenty of learning in the decade since I started testing, so much of the material in Bug Advocacy is not new to me. That doesn't detract from the value of the course. I've taken the opportunity to refresh my memory, and to look at how the other students interpret the same material and how they go about the practical exercises, and compare that to my own approach. I love that these courses are run with small cohorts, emphasise practice to reinforce theory but also to ask questions of it, and require that students review each other's work as an aid to learning. Each week there are exercises that have the students interact with...

In the last couple of weeks I've published ten sets of sketchnotes for events that I've attended online. That's a lot, for sure, but we're in lockdown right now and there's tons of opportunities to take part in events that in the past would've been unavailable. I had a handful of aims: learn something in the areas of software testing and development practice my sketchnoting practice getting my written thoughts in order quickly and concisely I signed up for a bunch of interesting-looking meetups, webinars, ask me anythings and panel discussions. During an event I sketched and afterwards challenged myself to write up a summary, opinion, or thoughts inspired by the session on the same day or, at the latest, within 24 hours. I find that sketching helps me to listen actively and record less, more valuable, content. Being able to get essentials typed up efficiently is tremendously valuable to me, particularly at work, and especially if I'm documenting as part of ...

  This morning I attended How I Learn New Scripting Languages , a webinar by Rob Sabourin hosted by the Test Tribe . In it, Rob laid out general principles and specific steps that he recommends for anyone new to scripting, or to a particular language. His general points included: Don't get tied to a particular language or platform; it'll get in your way at some point. Don't sweat the syntax; you can always look it up. Do learn how to learn; this will serve you well everywhere, not just in picking up a new language. I don't think I'd argue with any of that but I'm less sure that my specific steps would be the same as his. For example, he recommends several foundational topics be reviewed before opening up a text editor. I wouldn't make that a precursor to starting. It's not that his ideas have no merit — they absolutely do, and to testing in general — just that they can be learned later, and tied to practical programming concepts. As it happens, I'm ...

The other week I found myself locked out of our shed and subsequently learned more than I ever expected to about Yale locks, or night latches as I now know they're called. The image at the top is a pretty standard night latch. It is opened from the outside with a key and from the inside with the handle. The latch (the gold tongue on the top left image) is sprung, which means that simply closing the door will push the latch onto the striker plate and into the box (both top right), locking it.  A deadlock which stops the latch from moving can be applied from the inside using the button (or, more correctly, the snib ). Night latches are an old technology, insecure, and make it easy to accidentally lock yourself out. The snib helps with the last of these by being able to hold the latch back inside the body of the lock. This means that even if the door closes, the latch can't engage and the door remains unlocked. Which is nice to know, but my problem was that I couldn't get in ...

Drew Pontikis spoke about Leading Communities of Practice at Cambridge Agile Exchange tonight. Some might think it controversial that a CoP should have a leader, but it's one of the four things that Drew thinks are required, along with regularity, a purpose, and the investment of (at least) time. Crucially, though, note that it's leadership rather than management, that Drew wants for a CoP. His own experience is that trying too hard to force things, direct behaviour, or control the structure or content of the group will lead to failure. He told the story of a team where management made CoP attendance mandatory and how awful it was to be interacting with a group who largely would rather be somewhere else. Leadership in a CoP should keep the group grounded during the early stages when motivation is high and motivated during the inevitable downturn in enthusiasm that will come. The leader is a peer with knowledge, respect, and integrity, and also with contacts and the ability t...

What feels like a zillion years ago I wrote a few pieces for the Ministry of Testing' s Testing Planet newspaper. Understandably, they've since mostly been replaced with much better stuff on the Dojo but MoT have kindly given me permission to re-run them here. --00--  You've got skills, but still you know you want more skills. Skills for testing, naturally, for the tools you use, for choosing which tools to use, for the domain you work in, the kind of product you work on, the environment your product is deployed in, for working with your colleagues, for reporting to your boss, for managing your boss, for selecting a testing magazine to read, for searching for information about all of the above. You want to hone your skills, to develop, consolidate and extend them. You want to learn new skills that will help you do what you do more effectively, efficiently, efficaciously, or just effing better. You want to find ways to learn new skills more easily, and you kn...

In Juggling and Bicycles , an episode of the Akimbo podcast , Seth Godin talks about learning. In particular, he makes a point about training wheels and learning to ride a bike. If the goal is to ride a bike then, while training wheels do permit anyone to pedal themselves around, superficially feeling like they are riding a bike, they don't actually teach a fundamental skill: balance. Sure, training wheels immediately give a sense of accomplishment and perhaps a confidence boost, but they don't teach balance. Worse, they actively inhibit learning that skill because they compensate for any lack of balance that the rider has without penalty or encouragement to improve at balancing. This is not to say that no-one using training wheels can ever learn to ride a bike. Godin's point is that there are ways to learn to balance and with balance riding comes easier. He points to balance bikes as one approach. In my role I support people in work they have not done before....