Hiccupps

Last week I started a new job. The team I've joined owns a back-end service and, along with all the usual onboarding process, inevitable IT hassles, and necessary context-gathering, one of my goals for my first week was to get a local instance of it running and explore the API. Which I did. Getting the service running was mostly about ensuring the right tools and dependencies were available on my machine. Fortunately the team has wiki checklists for that stuff, and my colleagues were extremely helpful when something was missing, out of date, or needed an extra configuration tweak. Starting to explore the service was boosted by having ReDoc for the endpoints and a Postman collection of example requests against them. I was able to send requests, inspect responses, compare both to the doc, and then make adjustments to see what effects they had. If that's testing of any kind, it's probably what I call pathetic testing : There's this mental ima...

Yesterday, I attended Unit Testing for Grown ups, a webinar with Gil Zilberfeld . Despite the title, it wasn't a tech-heavy tour through testing strategies, test doubles, or testability but instead a series of business arguments in favour of testing, primarily at the unit level.  If I had to sum it up in a couple of bullets, it'd be something like this: developers, your work does not start at the first line of production code and end when you push managers, your teams can probably work smarter And if I had a few sentences, it'd go like this: The goal of a software development group is to solve problems by writing code that "works" and is maintainable.  It is usually the case that as a codebase expands unintended side-effects occur more frequently and the costs of integration, testing, and bug fixing grow. How to reduce these costs? Test first, and mostly at the unit level. But the tests have to be good tests so developers should train their creative skills for thi...

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

  I'm in the middle of BBST Bug Advocacy at the Association for  Software Testing right now.  As you might imagine, on a course with that name there's been plenty of talk about what we mean by terms like bug, value, and quality. One of the great things about the four-week course is the mix of book work and application, so we students are repeatedly challenged with situations in which the learning can be practically applied. I have a lot of time for both Seth Godin and Shane Parrish so I'd have been listening carefully to Seth's appearance on the Knowledge Project podcast anyway but, given the context I'm in, the passage I've transcribed below stood out. It's about how the concept of quality is concretised as conformance to spec, and how that in turn directly drives physical actions. It starts at around 1:04:45: There's lots to be said about the spec. First lets talk about Edwards Deming and what spec and quality mean. Quality is not luxury, quality ...

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

Bear with me, there is testing here but first we need to talk about my toilet.  Yeah, my toilet . Its flush was getting weak and though I was pleased to have a preliminary diagnosis ( siphon membrane ) I wasn’t happy about the likely treatment. I’ve changed siphons before and it’s always taken me ages, with a lot of pieces to disassemble and reassemble.  Worse, I have never managed to get all the bits refitted on my first attempt without a drip appearing somewhere. That’s usually how the second attempt goes too. Worse still, on this toilet all of the moving parts are hidden behind panels. How was I supposed to do anything with that? But I know from past procrastination that I get nothing accomplished without starting, so I began by looking and feeling, wondering whether I’d need to apply some force to flex a sprung catch, undo a screw thread that hasn’t moved since Noah was a lad, or pull a stiff doodah...