Hiccupps

I was guest speaker for a software testing class at EC Utbildning  a couple of weeks ago. I talked about one of my hobby horses — using automation to amplify my ability to explore — and I'll give the same talk at the Ministry of Testing Cambridge next Tuesday. Perhaps you can make it? Chatting with the Swedish students on the call before my presentation I asked what they liked about testing and, as no-one seemed to want to go first, I gave my own answer: I enjoy testing because it mixes technical, social, and intellectual challenges. And that's true but it isn't always enjoyable in the moment . Last week at work, in a small group session, I offered to share my screen while we tried to exercise and then, when it wasn't working, debug some new monitoring functionality. Honeycomb is a valuable tool, and I've used it plenty of times, but not at an expert level. The instrumentation we'd been developing is based on existing...

In Your job is to deliver code you have proven to work  Simon Willison writes: As software engineers we ... need to deliver code that works — and we need to include proof that it works as well.  He is coming at this from the perspective of LLM-assisted coding, but most of what he says applies in general. I think this is a reasonable consise summary of his requirements for developers: Manual happy paths: get the system into an initial state, exercise the code, check that it has the desired effect on the state. Manual edge cases: no advice given, just a note that skill here is a sign of a senior engineer.  Automated tests: should demonstrate the change like Manual happy paths  but also fail if the change is reverted.  He notes that, even though LLM tooling can write automated tests, it's humans who are accountable for the code and it's on us to "include evidence that it works as it should." Coincidentally, just the week before I read his post I told one of my...