Hiccupps

I am totally loving Oddly Influenced, Brian Marick's new podcast. The latest episoide covers ways in which schools of thought and practice can inhibit the cross-fertilisation of ideas.  It includes a case study in experimental physics from Peter Galison's book, Image and Logic , where two different approaches to the same particle analysis problem seem to run on separate, parallel tracks: In the 'head to world' tradition, you use your head to carefully construct situations that allow the world to express its subtle truths ... In the 'world to head' tradition, you make yourself ever more sensitive to the world’s self-expressed truths ... The first of these wants to theorise and then craft an experiment using statistics while the latter wants to gather data and try to understand it visually. Marick is pessimistic about the scope for crossover in this kind of situation: How do you bridge traditions that differ on aesthetics, on different standards of what counts as...

I attended another Lean Coffee online with the Association for Software Testing this morning. Here's a few aggregated notes from the conversation. Teaching Developers About Testing There's a lot of debate in the community about this, with two extreme perspectives. Anybody can test and we don't need specialised testers. Nobody except specialists can test. There is huge value in teaching developers about testing. Anyone who is involved in building software should be involved in testing software. We've been experimenting with ensemble testing. We started with regular session every two weeks, bringing a task for testing from a customer perspective. The testers helped prepare for the session (areas to cover, environments, data, etc). The session included members of the quality group and the teams. It evolved into various parts of the organisation using this approach for exploratory testing. Is "teaching developers about testing" a good framing for the concern here...

I've been working on my talk for the Testing, Diversity, AI conference run by the Software Testing interest group of the British Computer Society.  In it, I'm thinking about the tooling I built to help me explore a chatbot API. It exploits random choice to walk through the extremely large space of possible chats in a medical symptom checking application. As I reflected on the combination of tools and testing I found it convenient to label three activities that involve both. Navigat e Navigation is about finding a path to an endpoint. While navigating I am very interested to notice assumptions I'm making, workarounds that are required, and any questions that come to mind, but my main focus is on reaching the goal. In the first instance, on this project, I needed a basic framework that would enable my code to start a chat, walk through all of the interactions with the service, and stop. As I was writing code to create my initial ...

  The Great Post Office Scandal by Nick Wallis is a depressing, dispiriting, and disheartening read. For anyone that cares about fairness and ethics in the relationship that business and technology has with individuals and wider society, at least. As a software tester working in the healthcare sector who has signed up to the ACM code of ethics through my membership of the Association for Software Testing I put myself firmly in that camp. Wallis does extraordinarily well to weave a compelling and readable narrative out of a years-long story with a large and constantly-changing cast and depth across subjects ranging from the intensely personal to extremely technical, and through procedure, jurisprudence, politics, and corporate governance. I won't try to summarise that story here (although Wikipedia takes a couple of stabs at it ) but I'll pull out a handful of threads that I think testers might be interested in: The unbelievable naivety which lead to Horizon (the system at th...

  In episode three of Oddly Influenced, jUnit and What Makes a Successful Tool , Brian Marick is speculating about the relative lack of adoption of test-driven development compared to the tooling that supported it.  After putting forward a particular theory he wonders whether it's "true" and says: That ... gives me an opportunity to state a theme that’s been in my work for decades. I read books ... about how people do their work. I’m not so concerned if the theories are true as if they are suggestive – that is, do they give me ideas about how software people should do our work. [The] next task is trying out whether those ideas have good results, in our work. Because everyone’s theory about people is somewhere between fully wrong and fully right, and is always incomplete. I like this perspective a lot. It puts me in mind of Paul Feyerabend's Against Method, a book I failed to finish because it was so dense and widely-read, bu...