Teaching non-testers about testing

Testing Thoughts
#1

So, I’m the only tester in my department (it’s traditionally been more prototype stuff, so most teams don’t produce products as such, so, no testers. They are now shifting in focus to deliver things to other teams within the company).

I’ve been on a bit of a mission to increase the visibility of what testers do and why I think they should be thinking about testing. I gave a quick lunch and learn talk on testing, which you can see here: [https://docs.google.com/presentation/d/1sGipJBAK9Nm-mD6qQUCQNggUuJNBRTX4akPQD2bxy0Q/edit?usp=sharing](http://Google Drive link)

A team that have no testers and are just starting to build a test strategy, starting with unit tests, have asked me to help them. They’re currently doing some ‘ways of working’ meetings and want me to come along to a couple of them to help. I asked if anyone else had experience with teaching people how to test - especially when my time with them will be limited and there almost definitely won’t be a tester on the team going forward.

My thoughts:

  • First get their thoughts/ideas/current practices
    — What are their unit tests like, what other skills are in the team, any testing experience elsewhere, what their thoughts are about what testing is
    — Educate as needed. Throw some blog posts at them if they want (thinking Maaret P and Katrina Clokie to start with as they’re big on getting non-testers to test).
  • Do some sessions around risk (maybe riskstorming) and non functional requirements
  • Get them to consider their pipeline from idea to production, and figure out where testing activities can fit, what they currently do, what they can do: coupled with the risks I think this could be quite powerful
  • See what comes out and iterate as needed

Apologies for the wall o’ text but what do people think? Anyone else have any experience of things like this?
(I’m aware this is an amazing position to be in and don’t want to mess it up)

4 Likes
Are there any good resources for introducing non-testers to software testing?
#2

Hi Gem,
I like what you have here. Your pipeline bullet already touches on this point. You may want to draw some attention to the teams receiving the tested stuff, as in a customer-supplier model. How should the testers relate to their “customers” to meet expectations, avoid duplicate efforts, schedule work, etc.?

1 Like
#3

That’s an interesting point! They are literally just pivoting to that kind of stuff so I’m not sure how far away from ‘other people could use this thing’ they are, but it’s definitely something for them to think about

1 Like
#4

I had to do this a while ago. I’d say it’s 90% culture and depends on the problems you’re facing. It will depend on what you get out of your “thought/ideas” section and how honest they are. I find that being on their side helps them to open up about problems. Sometimes it’s fear about someone critically appraising their work, sometimes they fear a new “test” phase to deal with (rather than a platform that supports all work), sometimes they don’t understand what is actually involved with testing, sometimes they hate the idea of trying to pair on things, some people think the teams will be too large or the process will become unwieldy, some people want their devops and to eat it too, sometimes they just don’t care about the product. Each takes a different emotional approach to education and support. I like asking people their problems and what they feel they’d get out of having a tester on board - then I can agree to do it, or clarify what I can do and agree to work with them to solve their problem another way.

The other thing I do is what you’ve already done in your talk - make it fun. I offer game workshops with Set, Zendo or Concept. I bring snacks and share them. I try to cultivate the idea that I’m not the suicidally depressed, anxiety-ridden, social isolationist I actually am, but the fun-loving, problem-solving, supportive, team player I actually am. I tell them that I don’t mind if the product has problems, as long as we know about it and can make decisions as a team so that I’m not a gatekeeper nor am I there to judge them. That way I’m more likely to get what I want - all the testing, none of the parenting, like a pear cider that’s made from 100% pear.

When I first started I thought testing was 90% skill and 10% teamwork. My numbers are very different now.

2 Likes
#5

I think these are all pretty good bullets. I’m facing a similar situation now, where I’m the only “official” tester but I really want to get everybody testing. I started off pretty much the same way – talk about what testing we’re doing now and what experience people have, what risks we’re actually concerned with and what we can do to mitigate those concerns (sometimes phrasing it as “what can we do” rather than “what can we test” makes it sound less scary), and then where in our process we should be doing those things — but the hard part is still that there’s still a lot of learning to do and skills to develop. The team might know they want to test for a specific risk, but maybe not how to actually test it, or how to test for it well. I’m still trying to figure out how to address that point! Pairing with people has probably been the biggest thing that helps, but like @kinofrost said, people react differently to it. I also just got Zendo today and love that it exercises so many testing concepts, though I wonder how well that’ll translate into coming up with good tests on a software product.

1 Like
#6

Hi,

Looks like a good start, for your risks and requirements session it’d be good to have some practical examples for them. Give them the basic brief and let them have their own brainstorming session. From their hopefully they come up with some good ideas but miss a couple of things, which will allow you to provide a testing insight into the broader picture. You often find with these that developers will focus on the positive tests to prove it does what it says on the tin but forget about negative scenarios, boundaries etc.

It’s a good way to demonstrate the difference in thought process and highlight the importance of testing/QA in the life-cycle.

Good luck!!

#7

One thing to think about is how you teach them testing. I might give out personas to my new testers and have them adopt that persona and interact with the software the way the persona might. This is kind of a way to get them to do exploratory testing, and to get them thinking like the customer of the software. Any decent software will have a couple of surprises (either good or bad) and personas can help uncover them.

#8

If your talking about training new staff to be testers - don’t bother reading my post.

However, if you are talking about User Acceptance Testing (UAT) where business users are testing a system for the first time.
Here are my 3 tips I tell business users -
There is 3 cycles to UAT.

  1. Test what you do - If you use the system to check accounts and update payments. Then go do it first. No one is building a system that users cannot do what they need to do. The question to keep in mind is - does this help me, is it what I want?

  2. Test for fun - The whole point in this type of exploratory testing is to get people asking those important questions like what happens if I do this? Is that where I expect it to be? or my personal favorite - if my kids got on here, could they break it?

  3. Test the new stuff - Test the new features last and ask why was this made? Can it be better? Will it save me time?

I always stress that breaking the system is a good thing and offer a free chocolate or coffee to anyone who manages to do it. I think that is the biggest hurdle I face with new UAT testers, they fear doing something wrong and this means they do little valuable testing.