Five tips for describing what you do as a tester

Recently I was at an interview where I got this very broad and open-ended question. As I started to answer it, I realized that I found it difficult to express my answer in a both succinct and meaningful way. I wanted to say too many things in too little time.

Therefore I thought I’ll use this post to better articulate what I would like to have said and hopefully inspire others to share their answers to the same question.

Here are five tips that I could have used during the interview:

1. Say the most important things both first and last

For me that would mean that I would stress that all software development essentially is about communication. So I would talk about how important it is for me to form personal relationships with my co-workers and make sure we agree upon how we want information to flow in the team. I would also say that I want to involve all team members in the testing of the product and build a culture around collaborative testing practices, such as pair testing and mob testing.

2. Avoid jargon

This is of course especially important when talking with non-testers but I have found it helpful to stay clear of it even when talking with other testers (in interview settings) since that tends to steer the conversation into discussing definitions of different concepts. And those discussions that can quickly take away too much time from what could be spent on getting to know one another and the task at hand.

3. Use metaphors

When describing what testing is (and what it is not) metaphors can be a helpful way to create a shared mental model from which to discuss. One of my favorite models is that of a traveler coming to a new city. The traveler may have a map (a specification) and different guides (oracles) to ask for directions but the seasoned traveler will use observation, curiosity, exploration skills, tools and serendipity to expand the understanding of the city and all its nooks and corners. And then add the newfound details to the map, telling stories about how the exploration went and specifically warn about areas that looked troublesome from different perspectives.

4. Talk about the value of testing

I think it is important to touch upon the subject on why one would want to have testers at all in a team or organization. I would talk about how testers are critical thinkers that question everything and seek to uncover misunderstandings and potential problems in the product and then sharing that information with others. The real value of testing lies not in verifying that something might work but in revealing in as many ways as possible how something might fail.

5. Tell a story

The human brain seems to be hard-wired to appreciate good stories and pieces of information tied to stories makes them easier to remember. Having a story to tell about how you as a tester thought, acted and contributed in a team effort to make useful software can neatly make your testing metaphor come to life and in a down-to-earth kind of a way answer the interviewer’s question about how you actually test.

The story I might tell would be how I once worked with a developer and an UX-specialist in creating a single sign-on solution for Amazon devices. We all had a clear idea on what we wanted to do from a user perspective: the possibility to log in with just one click using one’s saved Amazon credentials.

Together we started to map out the flow on a white-board. As the flow chart expanded, I started to insert questions in the flow from different perspectives. Most of the questions were open-ended and started with the words “What if…” or “How will this affect…”. Some of the questions prompted us to go and get somebody from billing or talk to our stakeholders at Amazon or involve people from customer service. I transferred the flow chart with all the comments to a mind mapping tool that then served as a visualization of the suggested solution, the different test ideas and the identified possible risks.

As soon as there were something testable, we tested in pairs or all three together, updated the mind map with our findings and continued to implement and test in this collaborative and exploring way. The whole process revolved around conversations and experimental learning.

I’d love to hear your feedback on this post and I hope you’d like to share the stories you tell about your own testing! Cheers!

About the author


David Högberg is a physiotherapist who turned software tester. He likes to think of himself as a guardian of end user satisfaction. But he also believe that the quality of the experience of producing the product is as important as the product itself. He wants to beckon the lovely wherever he works which all begins with forming personal relationships with one another.