Hiccupps

Here's the column I contributed this month to my  company's internal newsletter, Indefinite  Articles . (Yeah, you're right, we're a bit geeky and into linguistics. As it happens I wanted to call the thing  My Ding-A-Ling  but nobody else was having it.)  When I was asked to write a  Seven Things You Didn't Know About ...   article ("any subject would be fine" they said) I didn't know what to write about. As a tester, being in a position of not knowing something is an occupational hazard. In fact, it's pretty much a perpetual state since our work is predominantly about asking questions. And why would we ask questions if we already knew? (Please don't send me answers to this.) Often, the teams in  Linguamatics  are asking questions because there's some data we need to obtain. Other times we're asking more open-ended, discovery-generating questions because, say, we're interested in understanding more about why we're doi

I'm testing. I can see a potential problem and I have an investigative approach in mind. (Actually, I generally challenge myself to have more than one .) Before I proceed, I'd like to get some confidence that the direction I'm about to take is plausible. Like this: I have seen the system under test fail. I look in the logs at about the time of the failure. I see an error message that looks interesting.  I could - I could - regard that error message as significant and pursue a line of investigation that assumes it is implicated in the failure I observed. Or - or -  I could take a second to grep the logs to see whether the error message is, say, occurring frequently and just happens to have occurred coincident with the problem I'm chasing on this occasion. And that's what I'll do, I think. James Lyndsay's excellent paper, A Positive View of Negative Testing , describes one of the aims of negative testing as the "prompt exposure of significant

While there's much to dislike about Twitter, one of the things I do enjoy is the cheap and frequent opportunities it provides for happy happenstance . It's not interesting that you can fool a computer. The whole art is how to *not* accidentally fool the computer. — Noah Sussman (@noahsussman) July 27, 2016 @noahsussman Only computers? It's easy to put people in incongruous situations. The art is in not doing it accidentally. — James Thomas (@qahiccupps) July 27, 2016 Without seeing  Noah Sussman 's tweet, I wouldn't have had my own thought, a useful thought for me, a handy reminder to myself of what I'm trying to do in my interactions with others, captured in a way I had never considered it before. Image: https://flic.kr/p/a341bn  

A couple of years ago I read The One Minute Manager  by Ken Blanchard on the recommendation of a tester on my team. As The One Line Reviewer I might write that it's an encouragement to do some generally reasonable things (set clear goals, monitor progress towards them, and provide precise and timely feedback) wrapped up in a parable full of clumsy prose and sprinkled liberally with business aphorisms. Last week I was lent a copy of The One Minute Manager Meets the Monkey , one of what is clearly a not insubstantial franchise that's grown out of the original book. Unsurprisingly perhaps, given that it is part of a successful series, this book is similar to the first: another shop floor fable, more maxims, some sensible suggestions. On this occasion, the advice is to do with delegation and, specifically, about managers who pull work to themselves rather than sharing it out. I might summarise the premise as: Managers, while thinking they are servicing their team, ma

I'm very interested in continual improvement and I experiment to achieve it. This applies to most aspects of my work and life and to the Cambridge Exploratory Workshop on Testing (CEWT) that I founded and now run with Chris George. After CEWT #1 I solicited opinions, comments and suggestions from the participants and acted on many of them for CEWT #2. In CEWT #2 , in order to provide more opportunity for feedback, we deliberately scheduled some time for reflection on the content, the format and any other aspect of the workshop in the workshop itself. We used a rough-and-ready Stop, Start, Continue format and here's the results, aggregated and slightly edited for consistency: Start Speaker to present "seed" questions Closing session (Identify common threads, topics; Share our findings more widely) More opposing views (Perhaps set up opposition by inviting talks? Use thinking hats?) Focused practical workshop (small huddles) Stop 10 talks too many?

Will Self wrote about his writing in The Guardian recently: When I’m working on a novel I type the initial draft first thing in the morning. Really: first thing ... I believe the dreaming and imagining faculties are closely related, such that wreathed in night-time visions I find it possible to suspend disbelief in the very act of making stuff up, which, in the cold light of day would seem utterly preposterous. I’ve always been a morning writer, and frankly I believe 99% of the difficulties novices experience are as a result of their unwillingness to do the same. I am known (and teased) at work for being up and doing stuff at the crack of dawn and, although I don't aim to wake up early, when it happens I do aim to take advantage. I really do like working (or blogging, or reading) at this time. I feel fresher, more creative, less distracted. I wouldn't be as aggressive as Self is about others who don't graft along with the sunrise (but he's not alone; even at bed

Back in May I responded to the question "Which advice would you give your younger (#Tester) self?" like this: Learn to deal with, rather than shy away from, uncertainty. #testing https://t.co/Db8Uj1HGyU — James Thomas (@qahiccupps) May 25, 2016 Last week I was reminded of the question as I found myself sketching the same diagram three times for three different people on three different whiteboards. The diagram represents my mind's-eye view of a problem space, a zone of uncertainty, a set of unresolved questions, a big cloud of don't know with a rather fuzzy border: What I'll often want to do with this kind of thing is find some way to remove enough uncertainty that I can make my next move.  For example, perhaps I am being pressed to make a decision about a project where there are many unknowns. I might try to find some aspect of the project to which I can anchor the rest and then give an answer relative to that. Something like this: "

I've been reading Here Comes Everybody by Clay Shirky. It's about how, in around 2007, technology and social media was beginning to change the ways in which people were able to organise themselves. Interesting to me on sociological, leadership and managerial grounds, here's a handful of quotes that I particularly enjoyed: If you have ever wondered why so much of what workers in large organizations know is shielded from the CEO and vice versa, wonder no longer: the idea of limiting communications, so that they flow only from one layer of the hierarchy to the next, was part of the very design of the system at the dawn of managerial culture. (p. 42, on Daniel McCallum's revolutionary ideas for hierarchical management )   In business, the investment cost of producing anything risks creating a systematic bias in the direction of acceptance of the substandard. You have experienced this effect if you have ever sat through a movie you didn't particularly like in ord