Transcripts

[Aaron Hodder] So, our next speaker, Ryan, has been a tester for 17 years, working both in U.S.A. and New Zealand before reluctantly becoming a recruiter.  He also thinks...that testers are terrible at selling themselves and the value that they bring.  

To help us all get better at articulating our value, we now have Ryan Bevens.

[Applause]

[Ryan Bevens]  Hey, look at that, technology's working.  

Hello.  Um...good afternoon, I get the enviable 2:30pm; when everybody's falling asleep after lunch slot.

[Laughter]

So the only thing I ask is, please try not to snore.  It'll mess up the recordings.  

So, before that, I will be speaking about this: trying to tell yourself as a tester.  

Um...one thing, I'm sure some of you are wondering who I am. Some of you know me.  

Um, so, in case you don't, I've got a nice, little slide that basically says "what Aaron said". So I'm not going to belabour the point, other than, yes, done almost 20 years of testing.  

I worked in everything from a four person startup to several Fortune 50 companies in the United States. Several years ago, I decided to take the leap to join the Dark Side, and become a recruiter.  We can talk about that journey later, but because those who know me know that I have a tendency of talking too much. So I'm going to go past this slide now.  

So what I'm going to be talking about is a couple of things.  

And I want to say thank you to some people that I work with. They made the presentation look very pretty. This was not me.  

Um, so, one of the things that we're going to talk about here is, what is our value? 

How we limit ourselves, as testers, in what we say and how we do things?

How do we train testers?  This is a fun one.  

And, then, how can we demonstrate our value?  Okay?  

So, again, people that know me know that I won't necessarily answer these things in a linear fashion. And I won't probably answer the question directly, because I think as testers, we like to discover things on our own. 

So I'm going to kind of talk around things. My intention is to get you to think about how you would answer some of these questions. And then, from there, you can build your picture. I'm here to try to help you to learn to do that on your own.  

So, the first thing that I want to talk about are four questions that I think everyone needs to be able to answer. Every tester should be able to answer these four questions.

What is testing? 

Right? It's a silly thing. We shouldn't have to ask ourselves that question. 

But how many of you have an answer that you like?
How many have an answer that you can compare with others, and theirs will be similar?  

We all have different answers to this question. I have my answer, I'm not going to tell you. But that's something you need to think about, and you need to have an answer to this question. Because any of these questions, whether you're coming for a job interview, whether you're talking to upper management, and you're trying to get an extra person on your testing team, these are questions you need to know. Not because you'll necessarily tell them the answers to these questions, but if you can't answer these, you will not know what your own value is.  

There next one, you can see I'm getting big to small. It's a thing people do. 

What value does testing bring?

Those first two questions are slightly different. They have a slightly different perspective on things, and it's important to know the differences. Because we can have lots of different definitions for testing.

What's our value?

What do we do as a collective to bring value to the software industry, to the gaming industry, to any industry we work towards?  

What skills or qualities does a good tester need to have?

This is a stupid question that people ask, especially prospective hiring managers will ask you this question. Now, I also ask this question. But I do it for this reason…

You better answer in a way that you have shown me that you have those skills during the interview. Right? 

Meant to share my duck. That's my emotional support duck. I may talk about that later.

But I'm going to say one thing about this. And I'm going to say, as people start…you hear a lot of the standard, you know, what do testers do? 

They need to be detail oriented. They need good communication skills.  They need to be curious.

And, if you say, testers need to be curious...and you're not sure why that duck is there, it's probably driving you crazy. Because I just stuck it out there randomly. I may tell you about it later, we'll see.  

So this is just a thing they ask this question at the beginning, or the end, to tell me: Do you actually believe those things? Or did you just Google this before you came?  

And then the fourth one is another one I think a lot of us seem to forget.

What value do I bring?

When I became a part of this organisation, what value can I give?  

You know, whether I am an intermediate tester, a senior tester, test lead, whatever terminology you choose to use, what value do I personally bring? Because if you can't answer that question, there's some issues there.

So, take these away. Think about these questions, the next time you have to stand in front of people, and try to explain why you bring value.  

So, instead of telling you what I think it is, I'm going to go through a couple things of what I don't think testers are. 

Testers don't break stuff.

I hear so many people that are like, why are you a tester?
Oh, I like to break stuff.

You don't break stuff. That's not what you do. You find things that are already broken.

You're not banging things with a hammer.
You're not you're not going into a software and going, woooh! 

You're not doing that. You're finding the faults. You're pushing. You're gently nudging things, and you're moving things around and saying, what's going to happen? You don't break anything. You find the things that are already broken.  

Does it work?

I hate this question. Because it's not our job to tell you if it works or not. It's our job to tell you that...here's the current state, based on the best of my knowledge. Because we can't guarantee something works. We don't have that capability.

We can tell you, this thing does a thing. You can say, it doesn't work the way I expected it to, but the question, does it work, is a really bad question to a tester. Because it's our job to tell people what we get, and let the product decide if that's good enough. Take that off your plate.  That's not our job.  Because we're not gatekeepers.  

You should not come to a tester and say, can we release to prod? I hear some slight giggles around. Um, because if you ask a tester, the tester's always going to say "no." 

[Laughter]

We want everything to be perfect. You know, I've been really enjoying the other speeches, because you do hear those things that say, we got to remember that good is better than perfect and we gotta…you know.  And that's true.  But our default is going to be, but there's something. And if I haven't found it, it's just because I haven't found it yet.

[Laughter]

So don't make us the gatekeeper!

You know? We're just going to drive the car up to the gate, and tell you

“It's only got three wheels. Are you okay with that?” 

And if they say "yes," we send it out. 

So these are things we need to think about.  Take it off your plate.  It's not our job. Let everybody do their job. 

You know, I've heard several people, today, up here, say, trust. Trust your developers. Trust your product owners. Trust these people to do their job. They want to do a good job and they want you to do a good job.

But we really aren't: failed developers. 

Anybody hear this one? I think this one makes me laugh because I think probably at least half of the people in this room got into testing weren't developers at all.

I wasn't. I fell into testing because...I knew a lot of business knowledge. That's how I started. I learned to be technical. I took some programming courses and did quite well. Wasn't my thing. It's not what I wanted to do. Not failed developers. 

We allow ourselves to kind of deal with this, especially when you get people that started in development, and decided that they wanted to be testers.

It's not because they weren't good at development.  It's because they have a different mindset. And they have the mindset of a tester. They have the mindset of somebody who's going to think critically, not somebody who builds. These are very important, distinct skill sets.  

And we are not monkeys banging keyboards! We don't just get out there and go

“Well, what happens when I press this button?”

We at least…we shouldn't be.

[Laughter]

I won't say it's not true for everybody, but this is not what we should be.  

Um, you know, testing should be a well thought out, structured process. However that structure is, for your organisation, it's a thought process. It's not a mindless game. It's not just us boundary testing.  It's not just looking at a field and going

“Well, what happens if I put ‘minus 1’?”

We have to think about some of these things, but that's just such a small piece of it. 

And we continue to allow people to kind of think this is what we do.  We make a lot of jokes about it and those kinds of things, but it's not what we do. 

And I think we need to be better at pushing the idea that we are trained professionals. That we are not idiots banging at a keyboard.  We're not the lowest common denominator. And I think some of this, to me, comes down to one thing that we don't do, that I'll talk about in a minute. 

One of the things...these phrases, up here, are what I consider kind of limiting terms, in some ways.  

How many times do we hear

"Oh, they're just testers"
“Oh, it's just the testing team.”
“Don't worry about it. We'll make it up in testing.”

It's because…when was the last time that a developer came out and said

“Uhhhh, we found this new problem. We found this issue that came up when we tried to develop this, and it's going to take an extra couple of days for me to get this done.”

And some of you go

“No. No, we're not going to do that. Just send it out as it is.”

Well, that's what we let people do to us. 

We allow people to go

“Uhh, yeah, I realise you had three days to do this and you've only got one.  Sorry.”

We need to start saying “sorry's not good enough”. Or “let's talk about those repercussions, because I can't do my job in an afternoon”.

And then, the whole, we are a bottleneck. 

I know everybody here has probably heard that. Please tell me everybody's heard that. 

And I think there's two ways of looking at this. 

There is the concept of...are we the bottleneck because of bad processes? Is what I just described what you see normally? Then we're talking about bad processes and we're not the bottleneck, the process is. And, we just kind of are the unfortunate side effects of being the end of that process.  

You can also look at it in the way of...maybe we are the bottleneck.  But maybe that's not a bad thing. When you are looking at road work being done, and they're reducing two lanes down to one, why are they doing that? 

They're doing that for safety.
They're lowering the risk.
They know that there are people on that road doing work.

That bottleneck is needed. It's important and it's actually a good thing. It's a safety thing. So, sometimes that's intentional.

Everybody's got different organisations. I can't tell you why you're the bottleneck if you are. But think about it, review, take the time to assess.  Work with the company, work with the processes and say, "why."  Why are we the bottleneck? 

So one thing I want to talk about is, who trains testers?  

[Audience made a snarky remark]

[Laughter]

Probably. 

Um, so, I think if I asked everybody here how you got trained in testing...I'd probably hear one of very few answers. But most of it's going to revolve around, um, I just kind of learned by doing. Right?

I'm going to say that that's not the best plan, mostly because I agree.  No one, no one trains testers. Right? 

Mostly because they think that we're just monkeys banging keyboards. Nobody wants to invest in the training, because we don't talk about how training is necessary. And one of the ways we devalue ourselves, is if we have the belief that you don't need training, how important is that job? Right?

Who's going to go to a doctor that's trained themselves? Right? 

This isn't how we should do things. You know, we don't talk about trying to train. We don't talk about making sure that people know what's going on. You know?

Now, I know at least one or two of you is going to be saying, but, Ryan, what about ISTQB?  

[Laughter]

See, I knew there would be at least one. 

I'm not going to bag on it. Um, but I will say this. I think for the most part, from my perspective when I look at it, it's like training a developer in GitHub, and then calling them a developer.  Right?

It's the artefacts of testing. It's kind of process-y, but there's not enough around ideologically, what do testers do? 

You know, how do we think?
How can we refine some of those skills that we've all learned naturally from childhood? Of pushing boundaries and pushing back on things.
How do we take those and refine them into the skills that make a good tester?

We need to start doing these trainings. We need to start talking about the value of companies…probably having to spend a little bit of money.  Not right now, but soon, hopefully.  

So, I think this is the thing to take back and remember. When you talk about value, you do talk about all the things that intrinsically leads up to the thing being valuable. 

We don’t consider ourselves valuable enough. We don't push these things, because we don't need to be trained. We can just throw somebody on the job and they'll figure it out after a while.  

I mean, for me, I can't tell you how long it took me to get to the point where I realised I didn't want to test what the developer did. I wanted to test the requirements for what they were supposed to do. It took me years to figure that out, right, because nobody told me those things.

You know, I would just take on faith, whatever the developer told me, because I walked into a place that didn't have any training, and I only had business knowledge. So we need to value ourselves. We need to get out there and do training.

It was after I started doing it that I went, uhhh, I've been doing this all wrong and I can be better. Ooohhh.  And I was a test lead, which is scary to me.  

So, this will be a little bit of my...all right, I kind of lied.  

I will tell you a little bit about what I see testing getting into. All right.  

Because, right now, we see, you know…Toby spoke a bit about this when it comes to the whole automation side of things.

Those of us who have been in the industry long enough, have seen the cycles where automation is kind of the magic bullet. And then everybody realises that it's not, and then they think it's a magic bullet again, because somebody new comes along and

“0h, I've got a new idea.”

Now we're getting into the era of things like AI, and AI is now going to take all the testing.

No, it's not. It still requires that human brain to take it, move it into a different direction, and to evaluate things critically, because the machines don't evaluate critically. They do what you tell them to. And if you have the wrong person telling them what to do, they're just going to do that. Even these big things. 

So, for me, here's what I think we need to be talking more and more about. Toby hit on this really well: risk, risk assessment, risk mitigation.  

Risk. We need to be talking about the idea that if you do not have a critical thinker, trying to tear a system apart, risk increases.  

Developers, their job is to build a product. Right? And they can't sit around thinking about all the "what ifs". They'd be stuck with decision making paralysis, and stuff would never get built. 

So somebody has got to be the one that does it. 

A BA isn't going to do.
Product Owners aren't going to do it; they want to deliver.  Right?

So it is unfortunate, or fortunate, depending on your personality. Somebody has to do this. Somebody has to think critically and go

“Wait a minute, what if?”
“What about?”
“Did we…Have we even talked about this other thing?”

And we can use our brains for that. Right? Because it's not always going to be the same answer every single time. 

And, some of my best testing work would happen when I wasn't even in front of a computer. When I was sitting down with a developer, and we just discuss a project that… 

[Mic sound suddenly dropped]

Should I switch (mic)? Okay, we'll see how she goes.

It's understanding that some of the best testing is when you're sitting down with developers, and they're talking to you about different ways of working. 

There's always more than one way to solve a problem. And so to have such a good relationship, that a developer comes to you, you and says

“I've got three ways of solving this problem. What do you think about them?”

You know, I've had those relationships with developers. To be able to just sit down and go

“That's not going to work because…” And they go
“Oohh, that's a good point” Or they go
“Oh, but we could do this.”

And to be able to talk through those things, so by the time the project starts, you've already got a lot of that work done.  

And a lot of it boils down to this...you know. Everybody who's worked for the legacy system knows the risky bits. The parts of the codebase that no one wants to touch.  Right?

They're like, oh, no, no, we're not going to do that.

[Laughter]

You know, because that's the big, scary box that somebody, 20 years ago, built, and it still works so why not still use it.  

We need to be thinking about these risky bits and say

“If we don't want to do that box, we’ve got to work around it”

And that's just a little extra, hey, did I mention risk? 

We need to remember these things. We need to remember that everything we do has value. But unless we push that value, and unless we start talking collectively about our value, people are going to continue to think of testing in the same way they do now.  

It's an afterthought. It's a tick box.

Everybody knows we need testing, but we don't know why.

It's only when you work with really great testers, who really understand what's going on, that those developers start going

“Oohh, that's why. That's why we need that person.” 

We need to do that more. 

So, this is where I say I'm done. And, normally this would be the question bit but I know we're doing the…   

[Audience asks]

What about the duck?

[Ryan Bevens] All right. The duck.

Ivan (the audience) is proving he's a curious tester. The duck.

So, for me, I've done some public speaking in the past.  Um, and I've done theatre work and those kind of things. And I recognize, this is something that a lot of people do that they become very afraid of: the idea of public speaking. 

One of the little ways that I play with myself, psychologically

[Laughter]

is, I like to pretend that nobody's looking at me. So, this is my psychological safety duck.  

This was brought to me by an intern. So now I use it as a kind of focus tool. Plus, I can use it for little illustrations if I feel the need to bring up the uniduck.  

Um, do you need me to…? 

I think we're all right, unless we want any other questions? No, we're good? All right.  Excellent. Thank you.

[Applause]