Hiccupps

  I seek to minimise friction in my working practices. I seek to minimise friction in my team's working practices. I seek to minimise friction in the interactions and integrations me and my team have with others. I bias to action in these activities. I implement a tiny delta on what was done before.  I evaluate the impact of that itty-bitty difference. I make more, regularly, without fuss, each time lubricating the process a little more. I am happy to fly under the radar, doing my thing.  I am happy to pay the low price that each step costs me. I share that value has been added, when it becomes significant enough. I demonstrate to others that I or we, or perhaps both, are getting benefit from my work. I see that they begin to do similar things themselves. I see the power of bottom-up incremental improvement to have wide-ranging long-lasting benefit. It may be small change, but look after the pennies and the pounds look after themselves . Image: https://flic.kr/p/aHp45R

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--  "Will the testing be done by Friday?" If the question relates to some prior discussion about scenarios we've agreed to run through before Friday then I'll do my best to base my answer on experience gathered so far . How sim...

And this is how it goes. One thing to another ... At the weekend I  was listening to Gene Kim's Idealcast interviews with Dr. Nicole Forsgren and Jez Humble . Jez Humble was talking about the importance of rapid feedback and referenced a  Brett Victor  talk that had stuck with him over the years: ... he built this little JavaScript game and he was changing parameters and the game was changing in real time. And his whole comment is like, if you can change something and see the change as you are changing it, it's incredibly powerful.   And so I looked it up in the show notes and watched it. Wow ... Inventing in Principle shows examples of experimental tooling for creative activities, particularly those that include a temporal dimension. The essential idea is to reduce the friction of having to maintain a model outside of the tool. In the image at the top, the left side is a traditional IDE and the right side is a dynamic visualisation of the function being develo...

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-- “What's the difference between context-driven testing and exploratory testing?” Put crudely, context-driven testing is about how good testing can fit into software projects while exploratory testing is about performing the testing. To add...

Periodically I get asked for advice on getting a job in software testing with no experience as a tester. It happened again yesterday. As a hiring manager I hired many testers , some with and some without testing on their CV. What's most important to me is the way people do their work, how they think and talk about their work, and how they deal with other people around their work. But I'm probably not the hiring manager you're approaching right now, so bear in mind that the suggestions I'm making below are generic, and mine, and should be taken only to the extent you think they fit you and your situation. CV, Application Form, Cover Letter Lead with the skills you have and the value you provided by using them. Make the skills that you think are transferrable to testing most prominent on the list. Think very carefully before leading with a list of responsibilities such as "attended daily Scrum, reviewed proposals, edited the website". This says almost nothing ...

Last week I did a presentation to a software testing course at EC Utbildning in Sweden titled Exploring with Automation where I demoed ways in which I use software tools to help me to test. Following up later, one of the students asked whether I had a favourite tool. A favourite tool? Wow, so simple but sooo deep!  Asking for a favourite tool could make a great interview question, to understand the breadth and depth of a candidate's knowledge about tools, how they think about an apparently basic request with deep complexity beneath (favourite for what task, on what basis, in what contexts, over what timescale?  what is a tool anyway?) and how they formulate a response to take all of that into account. I could truthfully but unhelpfully answer this question with a curt Yes or No. Or I could try and give something more nuanced. I went for the latter. At an extremely meta level I would echo Jerry Weinberg in Perfect Software : The number o...

On Fridays I pair with doctors from Ada 's medical quality team. It's a fun and productive collaboration where I gain deeper insight into the way that diagnostic information is encoded in our product and they get to see a testing perspective unhindered by domain knowledge. We meet at the same time each week and decide late on our focus, choosing something that one of us is working on that's in a state where it can be shared. This week we picked up a task that I'd been hoping to get to for a while: exploring an API which takes a list of symptoms and returns a list of potential medical conditions that are consistent with those symptoms.  I was interested to know whether I could find small input differences that led to large output differences. Without domain knowledge, though, I wasn't really sure what "small" and "large" might mean. I prepared an input payload and wrote a simple shell script which did the following: make a...

The other day I got tagged on a Twitter thread started by Wicked Witch of the Test about people with a background in linguistics who’ve ended up in testing. That prompted me to think about the language concepts I've found valuable in my day job, then I started listing them, and then realised how many of them I've mentioned here over the years .   This post is one of an occasional series collecting some of those thoughts.  --00-- If you're not familiar with the term syntax, you've probably heard of it by another name, grammar . It's the set of rules that defines the acceptable combinations of words in a language. Most native speakers have an instinctive grasp of it in their language, even if they were never taught it explicitly. Knowledge of English syntax is what can tell you that the first two of these are legitimate structures (even if the second makes no sense) and the third is not:  As a customer I want to log in using two-factor authentication to protect...

It takes a village to raise a child , they say. It can take a village to explore a piece of software. I noticed occasional spiky patterns of increased latency in the production data for a service I work on. Unfortunately for reproduction purposes, the requests contained personal information and so were not recorded. I experimented for a while but couldn't find a way to provoke the same shape behaviour. I spoke to the team whose library is invoked by that endpoint but we couldn't make it happen together either. I proposed that we log anonymised data under specific conditions to help diagnose the issue. My team agreed and our PO took the task of asking the relevant parties for approval. They gave it, we got the change made, tested, and deployed at the next opportunity. After that, as new occurrences of the issue began to appear, I collected and reviewed the data. It was unusual (and suspiciously so!) but my sight remained limited by the the systems I had access to. I reached out ...

After hearing good things about it for years, and failing to get one of the limited spots at its lean coffee events for almost as long, I was excited to finally be at Agile in the Ether last week . Here's a few aggregated notes from the excellent conversation.  How to encourage non-digital stakeholders to understand the value of discovery and outcomes over outputs? The business has scaled quickly and is large and stakeholders just want features They don't talk about problems and give people space to offer solutions Help them to think about how they experience the world outside work Lay out the risks/benefits of switching to incremental devlopment Get an ally who is respected (by them) to support your case Show business which haven't adapted, e.g. Blockbuster Show business which have adapted, e.g. McDonalds Let stakeholders observe interviews with users to understand their prioritie...