Q&A with Neil Studd

Welcome to Q&A, a series in which we discuss testing and quality with guests from the world of technology and software development.

Some guests you may know well, and others might be less familiar. You should learn something new about each of them, and something new from each of them. Each brings their own perspectives and insights on quality and testing.

The format will be the same each time:

  • a little information about this month’s guest and what they are currently up to
  • some questions for them to answer
  • some answers for them to question (the ‘Jeopardy’ section where I will provide the answer and ask the interviewee to give me the question)
  • finally, the ‘Pass it on’ section with a question from last month’s participant and the opportunity to pose a question for next month’s guest

In this edition of Q&A we are joined by Neil Studd, Quality Engineer with Zoopla.

Neil has been a tester in the UK for nearly 15 years, working for a variety of increasingly agile teams in roles which often overlap with developer and BA duties. In recent years he has become a regular speaker at meetups and conferences, making his American debut at TestBash Philadelphia last year.

Neil is most often encountered in audio format, as co-host of the Screen Testing podcast with Dan Billing (dissecting the plots of movies from a test perspective) and presenter of Testers’ Island Discs (interviewing testers about their careers and their favourite songs), with a third podcast project launching later this year. You can find him on Twitter @neilstudd.

Welcome to Q&A, Neil. Would you like to tell us about anything interesting you’ve been involved in recently, any exciting upcoming ventures, or just what you are working on at the moment?

As somebody who enjoys learning and discovery, my most interesting ventures tend to be outside the workplace, where I’m free to experiment under my own steam (and for as long as I like). There’s a big one that I’m working on right now, though it started under difficult circumstances: my brother-in-law passed away earlier this year, and he used to run a football website which required quite a lot of manual data entry. As part of investigating how we can keep the site running in his honour, I’ve managed to code a solution which utilises an external football results API service (https://www.football-data.org/) and regular cron jobs to ensure the data is always fresh, without anybody having to lift a finger. Solving business problems is great, but I get even greater satisfaction from solving everyday problems for people that I care about.

One other such personal project that I’ve undertaken recently is… actually, I have to be a bit secretive about it. In short, it’s a toolstack which sniffs out single-use voucher codes for certain high-street retailers and emails them to me. It’s not a hack or an exploit, but I don’t want to say much more in case somebody poaches my freebies! As a technical exercise, it was really rewarding (I learned a lot about complex regular expressions, and spent a lot of time hands-on monitoring traffic using Fiddler) and the semi-regular freebies in my inbox are a nice bonus.

If you encountered a version of yourself from earlier in your career, and talked about how you approach your work, what would you disagree on?

I think that a version of me from 2005 would probably balk at the amount of deep technical knowledge that I utilise these days – by which I mean, understanding of application architecture, a variety of programming languages, being able to structure complex database queries, that sort of thing. In my earlier days, I would have thought “that’s somebody else’s job”, but a lot of day-to-day problems become easier if you’re confident in getting your hands dirty in that sort of area. Currently I spend a lot of time supporting my product owner in prioritising work by extracting metrics from our product’s data, or looking at analytics, to demonstrate potential value in what we’re looking to build.

The old me would say, “That’s not what a tester does”. But if we’re trying to help teams to build quality products that actually have value, if I can utilise my skills to prevent us from wasting time building something that isn’t going to deliver the benefits that we’d envisaged, then who’s to say that we shouldn’t be more flexible when it comes to defining our roles?

When you look back at your career so far, what do you consider to be the highlight(s)?

Far too many to mention, or at least so many that it would fast become boring for readers! I can definitely highlight a couple of pivotal moments in my career though.

The first was when I joined Last.fm, an online radio station which was at the forefront of the Silicon Roundabout revolution in London. It was my first time working for an organisation which was a household name, my first time working in the capital, and my first exposure to concepts such as continuous delivery. It was a moment in which I felt that I had “made it” as a tester, yet it also gave me a chance to flourish in areas that I hadn’t experienced before (most of my previous companies specialised in delivering enterprise software on CDs about once a year!)

An even bigger professional highlight was discovering the existence of the testing community, primarily through the many facets of the Ministry of Testing. Oddly I remember overhearing about the first ever TestBash (which was held in Cambridge) when I was working in Cambridge, but I didn’t manage to make it there; but once it moved to Brighton the following year, I began attending and my career hasn’t slowed down since. I’ve hired testers (and been hired by companies) directly thanks to community recommendations; I’ve created and consumed educational content, and not only do I now have a valuable professional network but also got to know a number of people who I’m proud to consider some of my closest friends.

When you think back to these highlights, what were the most important lessons you learned?

As per the quote commonly attributed to hockey player Wayne Gretzky: “You miss 100% of the shots you don’t take”. This applies as equally to me outside the workplace as inside it. Don’t be afraid to try new things, often the fear is unfounded and the time spent procrastinating is often better spent getting the damn thing done. There is tremendous value even in failure, and I would much rather be seen as somebody who is bold and honest, than somebody who plays it safe and sticks to what they know.

Without wanting to talk entirely in fortune cookie sentiments, my other guiding philosophy is “Do whatever makes you happy”. It’s not my only decision-making tool, but it’s one that tends to prove useful, and certainly preferable to chasing after money or recognition. Of course, I’m sure my credit card company are delighted that I feel this way!

When you consider the many organisations around the world involved in developing software and technology, is there an example of one which stands out for you as having a focus on quality?

This is a really tough question! There are a number of big-name organisations who are frequently name-checked when this comes up (such as Microsoft and Spotify), and there are dedicated testing consultancies across the world (some which I’ve worked for, some which I would like to work for in the future!) who are definite trendsetters.

However, the organisation that I want to champion is Monzo – depending on where you’re from, you might not have heard of them, but they’re a new startup UK banking service who primarily allow account servicing through a mobile app. Unlike most of the rest of the financial industry, they’re agile from the ground-up: much of what they produce is open-source, their product roadmap is visible on Trello, and they ship frequently. Building a banking service from scratch, the things they ship aren’t trivial – e.g. the ability to create/manage an overdraft – and when you’re providing a service that is practically life-critical (and overseen by some pretty stringent government regulators) then it’s absolutely essential that you have a high-quality product. Everybody that I know who uses them is delighted with their service, and while I think that any high-quality product is laudable, doing it in an arena where few have attempted before is definitely worthy of kudos.

What do you think is the most common misconception about testing?

The word itself! Historically its most common usage has been as a verb: to describe the act of performing some form of testing/investigation, be it executing a test case or chartering an exploratory test session. Even though we’ve mostly banished the ghost of waterfall development, with fewer companies relying on throwing a build over to a QA team for sign-off, there are still those who think that a tester who isn’t tethered to their desk “doing the testing” is somehow not doing the best job that they can.

As I mentioned when talking about roles earlier, I think we need to think about testing more in terms of desired outcomes, and testers are the guiding force which help to ease the achieving of those objectives. That definitely means getting involved earlier in the development process, but it also makes it generally easier to justify stepping outside your perceived role, be it getting involved with fixing bugs myself, facilitating discussion across teams who aren’t talking to each other for some reason, or helping to shape the format/content of a usability workshop that we’re running with customers.

And now, the Jeopardy section. I’ll provide you with some answers and ask you to suggest the questions…


What is… the first thing that always seems to get sacrificed whenever a deadline comes along?


What is… part of the software development process, which is present in both waterfall and agile methodologies, which everybody doing all of the time, even if they don’t realise it, and even if they’re not doing it very well?

Lastly, the ‘Pass it on’ section.

This question was posed by last month’s participant, Samantha Connelly:

“What are the challenges facing you in your career?”

My biggest challenges are certainly not unique to me, or specific to testing/technology. They’re best summed-up as: too much to do, too little time! As somebody who has a passion for their work, I often spend evenings and weekends putting in extra hours, either developing new features for our products or exploring new test approaches. On the surface this is beneficial to the team, and greatly helps with my career development, but I feel that I need to be wary of setting unrealistic expectations for those around me.

As an example, I’ve developed something of a finely-balanced ecosystem within my current team, with my colleagues embracing “Quality is everybody’s responsibility” and we’re able to produce a consistent amount of high-quality work on short deadlines. However, this tranquillity often becomes an excuse for people to say “Everything’s okay, so let’s move Neil onto something else for a while”. There’s a danger that this can lead to a situation where I’m left trying to keep multiple metaphorical plates spinning – I’ve suffered with burnout in the past, and I’m recognising that there’s a real danger of getting caught in that spiral again.

And finally, what question would you like to pose for next month’s participant?

What is the one piece of knowledge/wisdom that you wish every new tester could receive when starting their first job??

My thanks to Neil for taking the time to participate in Q&A. See you again soon!

2 thoughts on “Q&A with Neil Studd

Comments are closed.