Hiccupps

  The Ministry of Testing laid down a poetic challenge last week: write a haiku about software testing in just five minutes. https://twitter.com/ministryoftest/status/1631718833340686339?s=20 This is what I came up with: You only find bugs In the places that you look. So broaden your view. Image: https://flic.kr/p/2cTruoF

  So much of what I want to do with automation is repetition of slight variants. I was reminded of it again last week when I was looking for a way to list the versions of certain dependencies across many versions of a product my team owns. These dependencies are exposed through the running product's API on an "about" endpoint. They can also be found in our Gradle configuration file, build.gradle , something like this: thingVersion = System.getenv( 'THING_VERSION' ) ?: '4.0' otherVersion = System.getenv( 'OTHER_VERSION' ) ?: '2.3.1' anotherVersion = System.getenv( 'ANOTHER_VERSION' ) ?: "7.6.0" Conceptually I need to run through released versions of the product, interrogate each for the  dependencies, and aggregate them into some easily-parsable format. If I was only after a couple of versions of the product I'd just check out the code for those versions, inspect the build.gradle files, and copy

  The map is not the territory.  Perhaps ironically, this gloss is not the quote. The original, due to Alfred Korzybski, can be found in Science and Sanity , page 58, and is more subtle: A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. The map is not the territory.  Mark Bessoudo, in his fun short essay on the topic agrees and, while a cartographical cheerleader, is likewise keen to circumscribe the map, or model's, utility: Engineers are trained to use tools that seek to change the world using “first principles” [but] Models do not replace skill or knowledge ... Knowing their limitations and the context within which they operate is essential. The map is not the territory.  Unlike Korzybski and Bessoudo I'm no philosopher. But I've learned that, in testing, models are unavoidable, that they can be extremely valuable, an

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 , Mastodon , 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-- "Developers can’t find bugs in their own code." I'm not usually so blunt unless we know each other well but, to my mind, if you mean what it looks like you mean, that's just

  The science first ... Stigmergy is a term for individuals collaborating or coordinating through the effect of their actions on the environment. It comes from the study of animal populations which demonstrate sophisticated emergent behaviours without any obvious control structure or even direct communication. If that sounds too abstract, think about wasp, ant, or termite colonies and the level of organisation suggested by their complex nest-building, foraging, feeding, and breeding patterns. You've probably heard about scent signals. Stigmergy observes that an individual will mark the path to a food source and that this influences the behaviour of other members of the community. They in turn also mark the path, reinforcing the signal and bringing still others to it.  If there are alternative routes to the food then the one which conveys most benefit, perhaps by requiring less energy to reach, will tend to get reinforced more. It can be instructive

A couple of weeks ago I was wondering what testing patina might look like .  What do I mean by patina in this context? I think I'm looking for artefacts and side-effects of work, visible on tools and places of work, that demonstrate something about the length of time, depth, and breadth of work, and ways of working.  I'm seeking things that other practitioners could recognise and appreciate as evidence of that work. But, and this is important, the patina is not the work itself. So here's the list of things I've come up with so far: Patina might be visible in an IDE I've been using for a long time through a litter of plug-ins, some for defunct tooling, or obsolete languages, with multiple plug-ins for the same file format, and so on. Patina might be visible at work from my Confluence home page where I collect links to the internal talks and demos I've done. (Top-right in the image at the top, and deliberately obfuscated I'm afraid.) Patina might be visible in

I paired with my friend Vernon last week. He mentioned it in a blog post afterwards: Watching my colleagues Lisi and James work is like watching wizards cast spells. He's very kind, and I do like a pointy hat, but there was no sorcery involved, simply intentful exploratory testing.  What do I mean by that? In this case, I mean that we started with a question and looked for ways that we could find information to help us to answer it. This particular question was very open because we didn't have a very specific oracle: can we find examples where the output of the system under test might be problematic? What did we do? CODS : Control, Observe, Decompose, Simplify. We could use the debugger to trace execution to a few pivotal functions and see what the application was doing (control, observe) but that was tiresome after a while. So we hacked the source code a little (conceptually simplify) so that variables were available to be d

  I was in the shed earlier on, spraying the footrest I've made for my daughter a metallic purple.  As I ghosted the can back and forth, a waft of paint drifted onto the workbench adding another colourful contribution to the happenstance Pollock that's been building up since I fished the boards out of a skip in the centre of town *cough* years ago. That's not to mention the various scratches, cuts, dents, dinks, and drill holes that pepper the surface. Yes, I thought to myself, this bench has a real patina . On seeing my bench, a fellow maker and fixer would recognise it. The layers and shapes are archeological evidence of the variety of activities at different times, with different materials, operated on by different tools.  Which got me thinking: how and where am I building up patina in my work in testing? And how would anyone ever see it? And would they be able to appreciate it if they did? Edit: I followed up with a few ideas in A Testing Patina

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-- "Whenever possible, you should hire testers with testing certifications"  Interesting. Which would you value more? (a) a candidate who was sent on loads of courses approved by some organisation you don't know and ru