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

I'm lucky that my current role at Ada Health gives me, and the rest of the staff, a fortnightly community day for sharing and learning. I've done my, erm, share of sharing, but today I took advantage of the learning on offer to attend a workshop on our approach to making medical terminology accessible to non-experts, a presentation on how we manage our medical knowledgebase, another on the single sign-on infrastructure we're using in our customer integrations, and a riskstorming workshop using TestSphere to assess an air fryer. So that would have been a great day by itself, but I, erm, capped it off by attending Capgemini's TestJam event, to see the keynotes by Janet Gregory and Lisi Hocke . Janet talked about holistic testing, or the kinds of critical review, discovery, and mitigation activities that can take place at any point in the software development (and deployment, and release) life cycle. The foundation for all of this is good communication and relationship...

Sliding doors , naturally, but it feels like the Sinclair ZX Spectrum 16k I got as a combined birthday and Christmas present when I was a boy was significant in where I've ended up. I recall with fondness the tedium-expectation opposition of typing in BASIC programs from printouts and then debugging them only to find that the monster was a letter M, and you were an asterisk and collision detection was a concept the author had only a passing grasp of. I have nightmares about trying and failing to install several sets of RAM chips to upgrade the machine to 48k and instead ending up with a wobbly and unreliable external RAM pack. I mourn the times we had to take the whole computer back to the shop for repairs. I regret spending my hard-earned paper round money on a Brother printer and then spending my hard-won free time trying to work out how to get it to print reliably, or at all.  I can still feel the covers of the thick ring-bound manuals, introducing me to BASIC and helping me to...

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 percentage of our test cases are automated?" There's a lot wrapped up in that question, particularly when it's a metric for monitoring the state of testing. It's not the first time I've been asked either. In my...

The First Law of Systems-Survival, according to John Gall, is this: A SYSTEM THAT IGNORES FEEDBACK HAS ALREADY BEGUN THE PROCESS OF TERMINAL INSTABILITY Laws are all-caps in Systemantics . Not just laws, but also theorems, axioms, and corollaries. There are many of them so here's another (location 2393-2394): JUST CALLING IT “FEEDBACK” DOESN’T MEAN THAT IT HAS ACTUALLY FED BACK There was a point when I realised, as the capitalised aphorisms rolled by, that I was sinking into the warm and sweetly-scented comforting foamy bathwater of confirmatory bias. Seen, seen, seen! Tick, tick, tick! I took the opportunity to let myself know that I'd been caught in the act, and that I needed to get out of the tub and start to challenge the content.  Intervening at that moment was congruent: I was in a context where I would accept it and prepared to change because of it. Of course, I enjoyed the deep irony of nodding along with Gall when he talked about...

Susan Finley's webinar for the Association for Software Testing , Making the Invisible Visible , has just been made available on YouTube.   It starts in the middle of an ongoing war room situation with a large group crammed around a small table, surrounded by empty coffee cups and the crumbs of long-consumed sandwiches. They are breathing stale air, they have perspiration on their brows, there is a production incident in full flow and they have no confidence that they understand the causes, the potential fixes, or even each other. The conversation repeats and circles and spirals back on itself until someone jumps up, sketches out a set of boxes and arrows on the whiteboard, and anchors the conversation on a model of the system. Suddenly there is shared context and understanding. That picture, Susan says, truly is worth a thousand words. The rest of the talk is focused on strategies and practices for reporting on the state of software, and this is very f...