Skip to main content

Posts

Exploring the Context

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...

Door Not Mouth

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 ...

My Favourite Tool

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...

Use the Force Multiplier

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...

Testing and Syntax

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

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 ...

Agile in the Ether

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...

Testing is not the Goal

  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-- “Testing is a bottleneck” I'd really hope it isn't, but let's see if we can work out what's happening and how we could improve the situation. First, what are you seeing that makes you think testing is a bottleneck? When I...

Testing and Words

  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-- In The Complete Plain Words , Ernest Gowers notes, acidly, that: What appears to be a sloppy or meaningless use of words may well be a completely correct use of words to express sloppy or meaningless ideas. It surely sounds trite to say it but our choice of words can make a significant difference to how well our message is understood, and how we are judged. We choose from amongst those words we know, our lexicons . The more my lexicon agrees with yours,...

Testing and Language

    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 . Like all collaborative activities, software development requires a medium for communication. As humans we tend to choose language, written and spoken. This is great! Most humans come preinstalled with language. This is terrible! Most humans come preinstalled with ambiguous language and a huge blindspot about it. Who hasn't been in a conversation where it turns out that was delivered, despite being precisely what was asked for, turns out to be nothing like what was asked for?   We all know intuitively how low the signal-noise ratio can be, but the field of linguistics has terminology and theory that can help us to tease out w...