How do you teach testing to a non tech audience

Recently I was given an opportunity to work with two of my colleagues to bring together a presentation to give an introduction to testing, talk about some of our processes and test automation. I’d like to share the part that I worked on — introduction to testing. I’ve learnt some valuable lessons and along with that I’ll give you my structure to give you ideas if you need to do a similar thing.

Remember your audience

We had 4 weeks or more to create the presentation and unfortunately my household caught covid (we’re all fine now!). My time was limited and I needed to pull something together quickly. I ended up reusing a presentation that I had done for a technical college thinking that it would do the job fine. How wrong was I!

We had a dry run through with the facilitators from the other department. The honest feedback was that they still had no idea what testing is or even how you would go about testing! The terminology was overwhelming and we missed talking about the basics. It felt like a shock. however, I said we’d take time to digest the feedback and work on it. I find feedback can feel like a shock initially, but each time I have received seemingly shocking feedback it has always helped push in the right direction.

We can forget the basics

With taking time to digest the feedback, one of the things it made me think about was how we forget the core basics sometimes the more experienced we are. I have seen this many times when Seniors have tried to explain something to a new starter, however, they’ve missed out the steps in between that are vitally important.

What we removed from the talk

I scrapped talking about the following four things and tried to step back and see testing from a birds eye view:

  1. Seeing testing as a scientist doing experiments or Sherlock Holmes figuring out the clues.
  2. Explaining the difference between waterfall and agile.
  3. Talking through the quality attributes and what they meant.
  4. The continuous testing model. All of these things were too much detailed and didn’t help in explaining the basics!

How did the talk evolve

  1. Introduced two broad things — check it meets the specification (verification) AND check it meets the goals, wants and needs of the user (validation).
  2. The testing manifesto — compiled in 2013 by agile coaches Karen Greaves and Samantha Laing. This was in the draft presentation, but it was decided with feedback from my colleague to move it earlier up in the presentation. I often hear that testers are seen as people that break the software and find bugs, so I wanted to use this to explain that we are doing much more than that. For example, we are trying to prevent bugs from happening in the first place . So I’d recommend using this if you are in a similar working environment. As an alternative, you could draft up the values you hold close to you as a tester or test team and use that to educate others on the value you are trying to add.

3. The Heuristic test strategy model — There is a lot of detail in this model. What I didn’t want to do is go into so much detail that the audience would find it so overwhelming, but I needed to give them a flavour of understanding. Rather than explaining the model and then talking about an example. My colleague suggested to use an example to talk the model through. I wanted an example that everyone could relate to in some way, so the most relevant thing I could think of was a mobile app to track covid-19 vaccination. Perfect!

So as I said before there are lot of parts to each of these (project environment, quality criteria, product elements and test techniques). I decided to choose the parts that may seem familiar to all. For example, for test techniques, I didn’t choose stress testing or risk testing. I chose the more general ones of performance testing and user testing.

This is how I talked through trying to keep it high level and general as possible.

Project environment — As we’re using a mobile device, then let’s ask for an android and iPhone to start. Then we need to figure out what environment we’ll use. We want to understand the timelines for this project, is it 6 weeks, 3 months of longer? What deliverables do we have — we have the mobile app, but is there anything else like documentation we need?

Quality criteria — I explained there were a bunch of quality criteria's here, but the idea is to go through the list and select the ones that you need to care about for this project. So I chose the ones that were easy to explain, and selected capability, usability and performance. Explaining that we want to check if this app can perform the required functions, assess how easy it is to use and check how speedy and responsive it is.

Product Elements—I decided to pick data and interfaces as these seemed high level enough for anyone to understand. I gave an example of how you might want to consider adding a tonne of records here. To think about how you’ll be interacting with the product. Is there a UI element or is there a database behind it?

Test technique — Then I explained that what I’m going to do here is take all of this information and use a test technique which, in short, is basically a way of doing something. So for example, I am going to set up an experiment. What I will go is simulate 5,000 users to log in at the same time and see what happens with the application. Does it become slow and unresponsive?

Or I might let the feature mould into a prototype. Then I’m going to email all of the business to get their feedback for ‘user testing’ (this is something we have done before, so thought it was relatable). Or, I explained, that we might organise getting some real users involved and get their feedback.

Perceived Quality — Then the output of all of this we’ll have a perceived sense of quality, such as the app is not speedy and responsive or it’s very hard to use. We’ll then work on this feedback as a team and decide what we’re going to do with it.

High level terms worked well

Explaining this in high level terms seemed to work well. If you’re a tester looking to explain to a more technical audience, then you might want to take a different approach. Using the example of a mobile app to track covid vaccination and talk through it in a lot more detail. If you’re interested in seeing how you would go about doing that. Then let me know and I can write something tailored to that audience.

4. But how do you actually go about testing?

This was one of the questions that I got in the initial feedback session with the facilitator from another department. I explained that the answer is that ‘it depends’(I took these words ‘it depends’ from my fellow colleague that states these words when we were working on the feedback). I explained that in the example I gave before, we were using mobile devices, but in other cases you might be using a laptop or tablet. You might not be using a device at all and drawing out a mind map to figure out how to test something. Or we use tools to help us with our testing, such as playwright or selenium to write test automation (gives us confidence when making new changes) or other tools such as OWASP ZAP for security or Postman for API testing.

Summary

  1. Remember who your audience is when you’re talking about testing.
  2. Don’t forget the basics. Remember to zoom out and see the big picture.
  3. When you get feedback, take a deep breath and try and think about why they are giving you the feedback.
  4. Don’t be afraid to inspect and adapt your approach — it’s not a failure, all learnings.
  5. Use the agile manifesto or make a list of the values you hold to explain testing to others.
  6. Consider using the Heuristic Test Strategy to explain the factors involved in testing to give that overall picture. Come up with an example product to test and use that to talk through the model.
  7. Explaining testing to others across your business is important. Offer to do a talk to go over this at your next big meeting!

How have you taught testing to different audiences? Have you got any tips and tricks to share? Please reply as a comment on my Twitter or LinkedIn (or medium if you have an account).

Test team leader sharing my knowledge, experience and thoughts on testing related matters.