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