Hiccupps

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