Hiccupps

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 ,  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-- "Isn't all testing context-driven ?" As we exist in a context, it's impossible to do anything that isn't influenced by that context to some extent. Some people take this to mean that all testing is driven by context. But d

Last night I attended How to TDD a REST API, a webinar by Gil Zilberfeld . In it, Gil described an experiment he's running to try to use test-driven development for a service built with Spring Boot in Java. As part of this, he is building unit and API tests at the same time. The code is available in GitHub and you can follow the kindergarten moves he talked us through by reading the src and main directories in parallel in numerical order. What insights did he get from his experience? Well, as you might expect, with all the additional weight of a framework and internal and external dependencies, there is a lot of friction.  But he still thinks there is still value in using TDD, or perhaps its spirit. His recommendations include: small steps a hexagonal architecture for aggressive abstraction very thin adapters (code that interfaces your code to the external world) code and data that is framework agnostic as far as possible small steps refactoring eagerly for readability refactori

I watched Allan Kelly 's Reawakening Agile with OKRs presentation at the Cambridge Agile Exchange last night. You can find a lengthy summary in his recent article for InfoQ and there's a book too, but here's a few points that caught my attention. If you've been around the block you'll have doubtless come across OKRs — objectives and key results — and perhaps cynically think of them as the antithesis of agile working, a management tool for the top-down imposition of overcommitments. From that perspective, promoting OKRs as a way to save agile could look a bit like the kind of sharp tactics that unscrupulous second-hand car salesmen might employ: "OKRs, one careful owner, a nice little runner, thousands of miles left in this one." Fortunately, Allan is open about the history and specific about the contexts in which he thinks OKRs can add something. In his view, their backstory is why OKRs are also a useful hack for the kind of "mil

About once a week, on average, for just under ten years I have published a blog post. 500 posts in total. Wow. The nucleus of the content has always been software testing but what falls into its orbit has varied as my thinking, my needs, and my activities have changed over time. With one eye always on testing, and the other on my context, I've covered areas such as software development, management, recruitment, writing, creativity, visualisation, tech support, meetups, workshops, conferences, training, exploration, Jerry Weinberg, semantics, science, statistics, public speaking, sketchnoting and, erm, fixing my toilet . I was wondering how to commemorate this anniversary when I recalled that in another lifetime I wrote a music zine which also reached the ten-year mark. Re-reading the retrospective piece I penned for that I found this line that encapsulated my triple aims of honesty, economy, and quality: Be true to myself. Say what the music is. Don