Hiccupps

I spoke about the overlap between testing and technical support at  SoftTest 2018  last week. The presentation was based on When Support Calls , the book I wrote with Neil Younger and Chris George for the Ministry of Testing . Here's the blurb: Testers are said to be advocates for the customer, but when do most testers come face to face with a real-life customer? I don’t mean internal stakeholders, but the people at the sharp end of things, the ones actually using the software. Rarely, I find. Which is why it can be a SHOCK! to be asked to participate in a customer support call. It’s an unusual situation, there’s pressure, the customer is watching, something needs fixing, and there’s a deadline ... of yesterday.  Gulp. But don’t worry! You’re on the call because a colleague values your input. Perhaps you’re great at analysis, or lateral thinking, or problem solving. Maybe you have deep knowledge of your product, or the whole ecosystem, or the historical angle. ...

I was at SoftTest 2018 in Dublin this week. I'll write proper notes later , but for now here's my sketchnotes (below) and the letter my youngest daughter gave me before I set off, detailing her research about the city (above).   For those who made it all the way down here: I did take a big coat and it was the right choice.

Just over a year ago now, I put out an appeal for resources on testers doing technical support. A tester on my team had asked for background material before his first support call and I didn't know of any, beyond our internal doc for support staff. Turns out there's not much out there: I got a book recommendation, for The Mom Test which isn't strictly about either testing or technical support, and a couple of offers to pool experiences from local testers Neil Younger and Chris George . I bought and blogged about The Mom Test , and started a Google doc where Neil, Chris, and me began to deposit notes, stories, and advice (our fieldstones ). Some of my own material was culled from blog posts here on Hiccupps (e.g. 1 , 2 ) at a time when I was managing both the Test and Support teams at Linguamatics . When the doc had got to about 20 pages, I began the painstaking process of editing it into shape. Eventually four broad categories emerged: What even is technical supp...

A few weeks ago I put out an appeal for resources for testers who are pulled into live support situations: Looking for blogs, books, videos or other advice for testers pulled into real-time customer support, e.g. helping diagnose issues #testing — James Thomas (@qahiccupps) October 28, 2016 One suggestion I received was The Mom Test  by Rob Fitzpatrick, a book intended to help entrepreneurs or sales folk to efficiently validate ideas by engagement with an appropriate target market segment. And perhaps that doesn't sound directly relevant to testers? But it's front-loaded with advice for framing information-gathering questions in a way which attempts not to bias the the answers ("This book is specifically about how to properly talk to customers and learn from them"). And that might be, right? The conceit of the name, I'm pleased to say, is not that mums are stupid and have to be talked down to. Rather, the insight is that "Your mom will lie to y...

You say "defect", the customer hears "defective" and the developers anticipate blame. You say "failure", the customer hears "catastrophe" and the tech support staff anticipate overtime. You say "own goal" and the customer wonders what you're talking about and you anticipate an imminent conversation with your boss. As an industry we use many different names for bugs, including anomaly, call, crash, defect, DR, enhancement, error, events, exception, failure, fault, flaw, incident, issue, mistake, own goal, problem, side effect, suggestion, ticket, TR (collected from  1 ,  2 ,  3 ,  4 ). But surely it's as Shakespeare never said : What's in a name? That which we call errors By any other name would smell as sweat; Really? What exactly are we talking about here? I like the broad  Rapid Software Testing  take on what a bug is: A bug is anything about the product that threatens its value. The BBST Bug Advocacy course  h...

If you can keep your head when all about you customers and colleagues are losing theirs and blaming it on you then, with apologies to Kipling, you'll stand a decent chance of being comfortable in tech support. I often think about the crossover between support and test and I've recruited people with support experience to work as testers more than once. I've also  noted before that I have my test team watch all support traffic and it's common in many companies for testers to be brought in for advice and to test fixes for issues that start as support tickets. But being the owner of a hard-to-reproduce high-value support issue, without a buffer between you and the customer who is experiencing the pain, being the one responsible for working out what the issue is and identifying a workaround adds piquancy and urgency and pressure to the diagnostic task. This kind of thing is often more constrained than the average test mission. In this scenario you know that there...

My QA team are observers on all bug and support traffic. They aren't required to respond to any of it or even to read it all, but they are expected to skim it. If nothing else this gives a flavour of where current issues are in the released and in-development builds. But we find it's more valuable than that. It generates test ideas based on customer scenarios, or even asides or expressions of interest in future features. It means that we can provide a more informed user viewpoint for product decisions, alongside our customer-facing colleagues. It's also not uncommon for QA staff to provide information that helps the support staff identify issues. With the overview we get, we can join the dots across the product. We reduce the number of dupes that are filed, we spread knowledge of fixes that may affect repro of other bugs, we often find that an issue that someone has seen sporadically and not filed because they can't repro will be related to another ticket and we...

I ask my test team to be proxy  users. They can and do report issues over, above, outside, around, across and regardless of any spec, convention or any other consideration if they feel that customers will find it an issue. To help to keep the team in step with customer thinking, all QA engineers are watchers on support traffic. (This has other benefits too, but that's for another time .) When you're doing this, especially in exploratory work, you have to be careful not to confuse your user with your self. You just won't have a single model user and, even if you did, the chances of it or any particular user having your own set of behaviours and prejudices is small (although obviously your behaviours and prejudices are the optimal set of behaviours and prejudices to have). So, if you're navigating the product and you like to use short cuts , don't just use short cuts. Take the slow route with mouse clicks too because some of your users will. Hover over all the ...