Hiccupps

I've just finished How to Cheat at Everything by Simon Lovell. It's a good read, although the lengthy descriptions of false cuts, dodgy deals, and ways to conceal or peek at what you shouldn't during high-stakes card games got repetitive.  In fact, at some level the whole book is extremely repetitive: there is always somebody looking for an angle and if you're the producer, consumer, or user of anything you are a potential target. Sometimes the angle is knowledge. Being aware of, or being able to calculate, probabilities will protect against some scams, such as those at the fairground or in amusement arcades. In them the punter is lured in through social engineering to play a game they will never win. That's not to say they won't get some return, of course, just that its value will be minuscule relative to the cost. Sometimes the angle is ambiguity. Bar bets are essentially riddles for money and the setup will make them sound like a sure win for the punter.

  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-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answer would be almost meaningless and certa

  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