Hiccupps

The other night I attended We Need To Talk About Testing , a panel discussion featuring Cassandra Leung , Alaine Miller , Richard Bradshaw , and Rob Meaney , hosted by Codecraft . With an audience of software crafters rather than testers, it made sense that the conversation was guided through a set of greatest hits topics including automation, the need for humans in testing, confirmatory vs exploratory, testability, the testing triangle, and observability.   The panelists spoke eloquently about all of those things from positions that demonstrated both expertise and experience, and a sense of humour.  I couldn't help thinking about Brian's mum when Richard urged us not to drive testing with the automation pyramid: it's not a strategy, it's a triangle . I was familiar with the majority of the content but I do enjoy listening to knowledgeable people speaking on a subject they care about. One of the things I particularly like abou...

  Earlier this year I did the Black Box Software Testing course in Bug Advocacy with the Association for Software Testing , and loved it. That and other BBST courses are run in collaboration by both AST and Altom , and four members of the Altom team ( Oana Casapu , Denisa Nistor , Raluca Popa , and Ru Cindrea ) recently did a webinar, Bug Advocacy in the Time of Agile and Automation , on the RIMGEN mnemonic in the context of hard to reproduce bugs sitting around in a team's backlog. Cem Kaner says that our mission as testers includes getting the right bugs off the backlog and fixed. The webinar described how we can work towards that by thinking about how to Reproduce, Isolate, Maximise, Generalise, and Externalise the issue, then reporting what we found using a Neutral tone.

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-- “Stop saying 'it depends' when I ask you a question” I'm sorry about that, I understand that it can be frustrating to not get a direct answer to what you perceive is a direct question. My motivation is to give you a sense of the v...

A significant part of testing is thinking up questions it might be interesting to ask, identifying ways that they could be asked, choosing a question and a way, and setting off.  Parklife. I find that I can usually think of more questions than I have time for.  Parklife. I find that there is usually more than one way to address them. Parklife. I find that after setting off, exploration usually throws up observations that prompt additional questions. Parklife. I know that I will never be able to address all of the questions in all of the ways. Parklife. So it's key to be able to pick the ones I think are most likely to give information which will be most important to the people who matter in a cost-effective way at the right time. Parklife. The rest have to be parked.  Parklife. The result? As testers, our view of the system under test will never be as high resolution as it could theoretically be.  Parklife. My advice? Accept that your vision will be blurred and embra...

A while ago my team was asked for estimates on a customer project that had become both urgent and important. Unfortunately, but not unusually, there was a reasonable amount of uncertainty around the customer need and two possible approaches were being proposed.  It fell to me to organise the team's response. First off, should we refuse to estimate? Woody Zuill talks compellingly about #NoEstimates approaches. In Control, or the Fear of Losing It I summarised his perspective as: We think that we estimate because it gives us control. In reality, we estimate because we fear losing control. The irony, of course, is that we aren't in control : estimates are inaccurate, decisions are still based on them, commitments are also based on them, projects overrun, commitments are broken, costs spiral, ... Ron Jeffries has a typically nuanced take on the idea in The #NoEstimates Movement : How to apply #NoEstimates isn’t entirely clear. ...