Hiccupps

  I was invited onto the Testers' Island Discs podcast recently. Testers' Island Discs is ... a podcast focused around software testing and storytelling hosted by Mark Winteringham. The concept is straightforward: each episode, Mark interviews a different member of the global software testing community to talk about their career, interspersed with clips and discussions of the music that they love. Every guest gets to select five songs and one book to take with them to the island. I've written about the music I chose in Island Records . This post is for links to things that came up in the conversation. Puns Your Testing is a Joke from EuroSTAR 2015 The Rule of Three and Me CEWT How it started ( Blog ) Topics covered ( List of CEWTs ) ...

I was invited onto the Testers' Island Discs podcast recently. Testers' Island Discs is ... a podcast focused around software testing and storytelling hosted by Mark Winteringham. The concept is straightforward: each episode, Mark interviews a different member of the global software testing community to talk about their career, interspersed with clips and discussions of the music that they love. Every guest gets to select five songs and one book to take with them to the island. Music was my life for a long, long time. I was in bands, I did my own solo music, I wrote a fanzine and occasionally for "proper" publications too, I attended gigs several nights a week, and I DJed on student and community radio stations. I built up a big record collection stacked around the house and in the loft but when my daughters got old enough to need their own bedrooms I had to sell it to make space. Although I never counted, I estimated that there were ar...

    Jerry Weinberg discusses quality in Quality Software Management: Systems Thinking with an anecdote about a book his niece wrote. In the story, her book is released with significant sections missing due to bugs in the word processor she was using.  Weinberg happened to be working for the company that produced it and asked the project manager what was going on. The manager said that they knew about the issues but were unlikely to fix them any time soon: ... out of more than a hundred thousand customers we probably didn't have ten [who might have seen these problems] ... Eventually we'll probably fix them, but for now, chances are we would introduce a worse bug - one that would affect hundreds or thousands of customers. I believe we did the right thing. This situation motivates Weinberg's idea that quality is relative, encapsulated in the famous definition linking quality to value:     Quality is value to some person Hundreds of thousands of customers get...

A developer I don't work with often made a change, tested it against the problem case that motivated it, and then asked me to have a look. I started by reading his description of the testing he'd done, reviewed his commits, and then ran the application with and without the change. After testing for a short while I went back to him having found a major problem. This isn't a blog post slagging off how developers (don't) test, it's also not about how testers should strive to create a quality culture and coach the team, and it's not about how clever I was at finding the problem either. This blog post is about the response the developer gave when he heard my report: "what made you think to test it that way?" Which is a great question from someone who wants to improve themselves and their work. I didn't want to put him off ever asking me anything ever again by taking the opportunity of an apparently receptive audience to lard on the test...

The other week I found myself locked out of our shed and subsequently learned more than I ever expected to about Yale locks, or night latches as I now know they're called. The image at the top is a pretty standard night latch. It is opened from the outside with a key and from the inside with the handle. The latch (the gold tongue on the top left image) is sprung, which means that simply closing the door will push the latch onto the striker plate and into the box (both top right), locking it.  A deadlock which stops the latch from moving can be applied from the inside using the button (or, more correctly, the snib ). Night latches are an old technology, insecure, and make it easy to accidentally lock yourself out. The snib helps with the last of these by being able to hold the latch back inside the body of the lock. This means that even if the door closes, the latch can't engage and the door remains unlocked. Which is nice to know, but my problem was that I couldn't get in ...

David Högberg tagged me on a thread about teams in the Rapid Software Testing Slack the other day. I've paraphrased the conversation here: Our team has expanded to include groups working on many different products. I'm thinking of starting a Testing Community of Practice with a Slack channel and perhaps a monthly meeting. I'd like to share things like articles, how we test our applications, interesting bugs, what we've learned, the business problems our products solve, who our users are, and so on. Looking for thoughts, ideas, advice, articles, etc. I've spoken to David about this stuff in the past, and I'm an agreeable kind of chap, so I started listing some of the things my team at Linguamatics has done over the years until it became apparent that I had quite a lot to say and I'd be better off typing it up in a proper editor and posting it somewhere other than Slack. So here it is. -- 00 -- Our setup is a little different to the scenario above in that w...

This week I wanted to monitor several pieces of software that talk to one another via HTTP and HTTPS. All are running on the same machine, three are Linux services, and one is a standalone script. I was interested in being able to see all of the communications between them in one place, in time order. I know a couple of ways of capturing this kind of data: proxying and network sniffing .  My default approach would be to have the applications configured to proxy via Fiddler running on my laptop inside the work network. Easy, right? Err, no, because I had forgotten that the machine in question is on a network that isn't considered secure and firewalls prevent that connection. In my proof of concept experiment, the standalone script just hung failing to find the proxy I had specified. Interesting behaviour, and I later reported it, but not what I needed right then. Next! As all of the software is on the same machine, capturing network traffic int...

When I started Hiccupps I challenged myself to do 50 posts in the first year. If I could manage one piece a week, I reckoned, I'd have a decent idea whether I really wanted to write and whether the effort I was putting in was worth it.  At the end of that initial 12 months I found that I really did want to write and, that as far as I was concerned, the effort was worth it. In the almost nine years since then I've maintained an annual average of around 50 posts and as I've reached the half-century or October I've taken a moment to reflect on how things are going. This post will be the 456th — with something like the 400th awful pun of a title — and so now seems like a good time as any to look back down the track again. Blog is a contraction of weblog and it occurs to me now, in a way that I'm not sure it has before, that Hiccupps genuinely is a log of stuff I've been pondering or doing or reading or viewing. The posts feel...

So I've just given up on Paul Feyerabend's Against Method . It's by no means the first book I've stopped reading; only recently I skipped big chunks of Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, shortly before that I dumped Douglas Rushkoff's Team Human , and further back Women, Fire, and Dangerous Things by George Lakoff moved off my bedside table and back onto the book shelves.  Why? Well sometimes I feel like I know the content already, sometimes I feel like I don't or won't have a context in which the information is useful, sometimes I'm just not feeling it for whatever reason. So I stop, or skip, or cherry-pick, or all three.  What was the problem with Feyerabend's book? It was too dense, referring to too much that I don't know without looking it up, and I have too much on my mind to be able to concentrate at the depth needed to consume it. Also, Feyerabend helpfully provided a summary of his argument, broken down by chapters...

Drew Pontikis spoke about Leading Communities of Practice at Cambridge Agile Exchange tonight. Some might think it controversial that a CoP should have a leader, but it's one of the four things that Drew thinks are required, along with regularity, a purpose, and the investment of (at least) time. Crucially, though, note that it's leadership rather than management, that Drew wants for a CoP. His own experience is that trying too hard to force things, direct behaviour, or control the structure or content of the group will lead to failure. He told the story of a team where management made CoP attendance mandatory and how awful it was to be interacting with a group who largely would rather be somewhere else. Leadership in a CoP should keep the group grounded during the early stages when motivation is high and motivated during the inevitable downturn in enthusiasm that will come. The leader is a peer with knowledge, respect, and integrity, and also with contacts and the ability t...