Greetings and welcome to the latest episode of the Vernon Richard Show.
And we have some alternative names for that thanks to James Thomas.
Thank you very much.
And they are the Vern and Richard Show, the Vern -en Richard Show.
So Vern, apostrophe, N, apostrophe, Richard.
And then there's one diabolical one, which is awful.
We can't go with it.
It's just bad.
It's Vern On Richard Show.
Dreadful name.
Can't go without.
Dreadful.
got all the letters in it.
Like it's perfect.
It makes it sound like it's my show and you're just on it.
Absolute classic from you Bradshaw.
Friendly tester my ass!
here it is!
That's the first instance of that.
How many times have I heard that?
Yeah.
4?
Whatever it is?
I don't know, 3, 4?
Whatever it is, I don't know, I've lost count.
Anyway, we failed with the intro.
Let's try this again.
Welcome everyone!
Sorry for that rambly intro.
I'm Vernon.
And I'm Richard.
And yeah, we've been busy since the last episode.
We're getting back on track with things.
We're starting to build a bit of a routine, which is nice.
It's been busy since we've last been on the pod.
Rich has been off to very cool conferences and I've been doing busy stuff at work.
So I think we're gonna spend most of the time talking about what Rich has been up
to and what he's got at the conference.
to trigger the topics, I think.
Just generally like, you
Promote what was a really good event, you know, because I think everyone should
definitely go to this event if they get chance.
And also, I think there was great topics that we can, me and you, can come up with
conversation about.
And also just to set the scene for people listening and watching, you will know that
me and Vernon are fans of...
football and we support very different teams, almost arch enemies.
But our teams are both playing right now as we're recording.
So if you suddenly get interrupted with a yay or a woohoo or disappointment, it
might be because our teams aren't doing so great.
And especially as it's the Liverpool Derby that's currently happening.
So.
And even worse, hopefully we won't be on long enough for this, but if you hear a
random, Hey Rich, or Hey Vern then you'll know.
You'll know the results.
Yeah, something's gone wrong if we're still on at the end of that.
But let's see.
So yeah, the conference I'm talking about is I went further north to Leeds at the
weekend.
At the weekend?
No, it's not the weekend.
It was on Tuesday.
To the Leeds testing Atelier.
That's just reminded me, Verdeen.
When was the first...
Did you know what the word Atelier meant when you saw the name?
looked it up but I've since forgotten and I'm going to quickly do it now.
Do you know what it means?
No, not at all, but it was the fact that that event came out was the first thing
that made me think of it.
I know in French it means workshop, but I didn't know if it had a different meaning.
private workshop or studio of a professional artist in the fine or
decorative arts or an architect.
Where a principal, master, and a number of assistants, students, and apprentices can
work together, producing fine art or visual art released under the master's
name or supervision.
Sick.
I didn't even, I didn't even, how did I forget that?
So anyone listening to this, who's not been to the Atelier, one of the things
that they do is they make all the signs themselves the night before.
So people go the night before and you make the signs for the names of the talks, the
rooms, everything else, and maybe that's because of that, the artistic side of the
Atelier.
It's also because they are very punk.
That's what that's how they describe themselves, right?
Which I take to mean.
a very cool venue called the wharf chambers.
I think it is very inclusive, diverse space in leads as well.
But yeah, it was really good.
Great to catch up with a lot of people.
I've not seen for a long time.
Some people like a really long time, like pre -COVID.
So it was great to catch up with them.
And yeah, there was a great, great selection of talks.
So.
But I think you were going to do this, Vernon.
Let's see.
You were going to lead this by following, was it Jits summary of events?
me find his
Ooh!
Football resulting!
So, live from the studio, there has been a goal for Everton.
It's currently 1 -0.
Gerrard Braithwaite with the what I imagine is a superb strike and causing
misery across many Liverpool fans' faces right now.
Richard has a future in commentary.
mate, it's sad times.
Hopefully, come on, come on you red, sort yourself out.
Anyway, back to the topic of Leeds testing atelier.
I'll quickly get this out of the way so I can go and cry.
Yeah, so Jit, I've got a post up here from Jit that he shared on LinkedIn yesterday.
Shout out to you Jit.
And he's listed a bunch of people whose workshop and talks that he.
listened to and took part in.
So do you want me to go through the list Rich?
Er, yeah, just pick one and I can tell you if I was there or not, let's do it that
way.
And then I'll fill in the gaps of the ones I went to.
I will start from the top.
The first one, Jit says, Ellie Gowsden delivered a great workshop and has given
me loads of ideas to try back at the office.
Yeah, so Ellie gave, I don't know what the title was now, but it was about play.
It was about the importance of play in the workplace and learning from play.
So I believe she works at Co -op Digital.
And there's a few people from there.
And she was talking about how they kind of have a lot of fun at Co -op and the
importance of it.
And the activity that she got us to do was, you know what?
I thought of my bag.
I think it's in my bag.
But I will try and go from memory.
So Snakes and Ladders, right?
You've all played Snakes and Ladders.
Have you played Snakes and Ladders?
So they gave us an empty board of Snakes and Ladders.
And it was to help the framing she gave us was around exploratory testing, but
generally onboarding new people.
So the idea was that you had to design your own Snakes and Ladders game.
And...
on the appropriate squares, you would have a testing challenge.
But really simple.
So their example was co -op.
So if you roll a three, you land on the number three, and it says add five items
to your basket.
And then you're going to learn how to do that.
And obviously, they're going to get to watch you and see how that goes.
So you could use it for user research, but you could use it for new people on board.
And you could generally just use it for test ideas if you're stuck at what to do,
just play a game of snakes and ladders on your own.
Um, but then she just waiting hers and they had like remove items from your
basket, pay for your basket.
Uh, you know, general co -op kind of shop related things, but then she challenged us
to make our own for our own.
Context.
So for me at the moment, my lot of my stuff's around memberships and
subscriptions and buying products and stuff.
So I was thinking more about some of the regression scenarios that we have, and I
was populating my little game.
And then you got to draw the snakes and where you'd come down and, um,
But yeah, I found it really interesting that side of it.
And then the final one, she challenged us, or maybe I'll challenge you now and see if
you can do it.
She said, think of a game you already know and how would you turn it into a testing
game?
like any game or board.
Okay.
of, um, battleships.
So I remember as a kid, I had an electronic battleships, right?
You know, you say B7 and stuff, and you know, it will sink my ship and stuff like
that.
I was thinking if you, my idea was, could you play that with, um, like basically
JIRA tickets and pull requests and, you know, stuff like that, lines of code.
So, you know, instead of like, maybe the ships are bugs instead.
and you say, you know, PR number seven, right?
And you, you know, you're basically squashing the bugs instead of sinking the
ships.
And, you know, you'd have to remember certain context of that bug to know which
one it might be.
Cause you know, remember in the past, you'd be like, well, I've already, I've
sunk you five ship and I've done you over one.
So yeah, that was one of my ideas.
And then what was my second idea?
Trying to go from memory.
No, it's gone.
It's not there.
What was it?
Have you thought of any?
Kind of.
So my, my favorite board game of all time is called Colt Express.
And basically this, this game is not really, well, it's a board game, but
there's no board.
It's more, the board is like a, a model of a train.
And the objective is every player is a robber.
Each robber has different abilities.
And the winner of the, of the game is the train robber who amasses the most swag.
Right.
And the way you play,
this will make sense soon.
The way you play is that each turn you play a card which gives an instruction to
your character.
Now, there are two things that can mess this up.
One of the characters can play a card face down so you can't see what he's done.
Okay.
and there's also some constraints on each round where you're in a tunnel which again
means you played the card face down so you can't see what people have done.
And what that means is you're effectively programming your players to do, your
characters to do stuff and because people can, you can like say, oh I saw Rich has
gone that way so I'm gonna react to that but as soon as this card start getting
played down you don't know what's going on.
and it's absolutely hilarious.
And that game reminds me of, reminds me a lot of programming and things not going
according to plan.
Like, oh yeah, I wrote the code to do this thing, but then money actually flipped the
cards over and play out the actions and moved it.
Things do not go according to plan.
And I was like, this is absolutely about software development.
It's got nothing to do with Robin trains.
So yeah, that's my example of what it's already about.
Yeah, yeah, it kind of already is.
Yeah.
I'm trying to think now of the examples that we saw as well.
So.
I think Claire, oh I can't remember her surname, Claire from North Wales, she's
often at Agile testing days, surnames allude to me, she joined, Newman, Norman,
yeah Claire.
I think she, her group came up with a play on UNO and I can't remember the specifics
of it but it was like a testing version of UNO which was kind of cool.
And yeah, so we're just generally talking about how the getting you,
playing is obviously kind of more chill.
It's more inclusive in some ways.
It's kind of not as like, oh, God, we've got to do training again or whatever,
right?
It's a bit more enjoyable and entertainment.
And she mentioned things like Lego serious play, which I've still never actually been
to a session of Lego serious play.
It comes up all the time, but I've never actually been to one.
Need to get myself to one of them.
And the, reminded me of my Lego automation workshop where again,
introducing that element of play to teach something in a slightly different manner.
I think it's like two different things.
One is using, you know, like fun methods to teach something, whereas the other one
is just making something more interesting by turning it into a game.
So yeah, it was really good fun.
She smashed it, delivering a really hands on.
You know, it was a 60 minute talk, but it was delivered as a talk and then
absolutely, you know, giving us challenges to do.
Why are you laughing so much?
See who's score!
Oh, what?
Outrageous.
I hope it gets bar'd off yet.
Let's see.
Anyway.
I didn't laugh this hard.
You better hope you hope Everton don't score again, mate.
We're playing United are playing Sheffield United, which is why he's laughing because
I think they are.
Are they bottom of the league or like, yeah, bottom of the table?
Yeah, well.
Anyway, right.
So, yeah, props to Ellie.
Great session.
What you're doing at Co -op Digital looks incredibly good fun as well.
So if anyone sees a job opening there that looks interesting, it sounds like they
have a great time there.
Very collaborative, very open.
Yeah, it looked like a good place to be.
I hope I'm pronouncing your name properly, Ellie.
Is it Galsden or Gawsden?
Forgive me if I'm mispronouncing it.
Okay, shall we look at the next name on Jit's post?
So his next one, he's saying, Elliot Thirland gave a great talk on the post
office horizon scandal.
If you've not looked into what happened there, then it's pretty shocking.
Did you go to that one?
I didn't, I didn't go and I think the reason why I didn't go is obviously you've
always got to make a decision at a conference, right?
That's one of the tricky things.
I think it's cause I've read a lot of James Christie's blogs on the topic.
So I, yeah, I opted to go for something else.
just for context for anyone who doesn't know about this.
This is, if anyone, you know, it's one of those moments where the importance of
software testing and bug reporting and software development is absolutely stocked
like this, just unequivocal.
So situation is, what, two decades, 20 years ago, 30 years ago?
Quite some time ago, the post office in the UK,
who are primarily responsible for delivering our letters.
They commissioned some consultancies to build themselves a new system for
postmasters and postmistresses, the people who run the post offices in the UK.
Like an EPOS system, electronic point of sale.
And the software would also do all the reckoning up at the end of the day.
And long story short, that software had a bug in it, which meant that, let's say I'd
actually taken a hundred pounds that day, the till and the software would say I'd
only taken, I don't know, 90 quid or 80 quid.
And so these postmasters and postmistresses who'd all been, you know,
absolutely fine before were now being accused by the post office of stealing.
And they were like, well, no, this is like the machine, like the software is buggy.
And the post office was like, no.
Absolutely not, you're all thieves and we're going to prosecute the lot of you.
And they did and the consequences were absolutely grim.
You know, many people went to jail, many people lost their livelihoods because
obviously, you know, the post office prosecuted them.
And even more horribly, some people took their own lives as a result of this.
And it is just...
It's unbelievable that it happened and a lot of governments dropped the ball on
this over many years.
So if you want to hear some more about this, there's two resources I can
recommend.
One of them, which already mentioned, which is James Christie.
James Christie used to be an auditor, then became a tester, worked in software
development for many years.
And he is incredibly good at explaining stuff.
And he has done a lot of research into this and is just...
It's a grim read, but it's also an insightful read.
So go on, look at all his materials.
And then the other one is a really good documentary series on the BBC.
I'm not sure if it's still, I hope it's still available.
I'll try and find it.
Well, I think why it's so prominent now is because ITV made a TV show about it
recently.
And that really brought it to the fore, which I haven't watched it actually, but I
listened to the...
BBC radio series about it some years ago and I couldn't, I actually couldn't
believe it.
So that's, that's, that is the short version by the way.
I think the important bit, like you said there though, is like, you know, you, you,
we always try and think of the people like who our software is going to be used by
right all the time.
But like in some spaces, like, yes, we're thinking how that could go wrong, but
like, I would admit I don't always frame it from the, the end user point of view.
Like I'm like, oh, you know, if that, I wonder if there's a way of that getting
negative, right.
As opposed to that, is there a way that I can make that not add up as opposed to.
Will someone lose their job if that doesn't add up, right?
They're very different, like framings for that testing.
And often I'm very much in the software model function space, as opposed to the
person space of what, how would that person be?
What would happen to their life if this went wrong?
And it reminds me of the headline game that Elizabeth Hendrickson introduced me
to for your software.
Like what's the worst possible headline you could wake up to tomorrow for your
product.
Yeah.
as a group, you try and reverse engineer it to see if it could actually happen.
And I think that again, that ties back into that idea of play as well.
It's like, you know, it's a very different way of framing going about testing.
And yeah, I remember, I think it's in the book that she, I think it's an explorer or
maybe she did a training, I'm not sure, but I definitely got it from her.
Yeah.
It's an explorer.
I mean, thinking about the second and third order effects of a bug is absolute,
like that can really, really help you report your bug more effectively.
And, you know, I learned a ton from, I did the bug advocacy course, the black box
software testing bug advocacy course, maybe 10 years ago.
I think that AST are in the midst of updating it and I know that Altum also,
where were they based?
Altum, they're in Romania.
Romania and Finland, I believe, that's the biggest places, I believe.
definitely check those out because they've got some good information about that.
But Kelty Hightower talked, gave a really good example of this last year at the
Manchester Tet Fest when we had a fireside chat.
You know, he talked about this, by the way, if you ever have a chance to listen
to Kelty Hightower talk about anything, take the chance.
And I mean anything.
He could be talking about the lint in his pocket and he will reveal the secrets of
the universe in that talk.
But in this talk, he was talking about how...
He was on a team that was dealing with a production issue and the team, you know,
you're in your, you're in your war room, I guess, trying to figure things out.
And I'm butchering this story when it's compared to Kelsey telling it, but he felt
that the energy was off in the room.
And so he's kind of got everyone, everyone's attention.
They kind of said, look, cause it was a, it was a, it's something to do with
transactions on credit cards.
That was the issue.
People couldn't pay for stuff.
And he's like, look, right now there is a family in a supermarket, the only way they
can pay is with our credit card.
They have no...
American version of Universal Credit, when food stamps went electronic, I think it
was.
he's like, they have no other way to pay for what they are buying.
The queue is backing up behind them and this thing is not working.
That's why we need to get this thing fixed.
And now it's the whole new level of seriousness now has just been applied to
the situation.
And that's why it's really important to try and frame these things in a really,
you know, in as impactful a way as you possibly can.
There's a human being affected or could be affected by this problem that we found.
But anyway.
For a talk that we didn't see, we talked about it a lot.
But there's actually a talk that I've...
I didn't write down, because I was like, you know, sometimes you're just listening
intently.
was a talk later on in the day with Leah King and Tracy Archibald about killer bugs
and how to squash them.
They build medical software for testing your eyes and doing Lasak and stuff like
that.
And they were talking about things like, like,
Like a field or a form not showing the data as it used to be, which could cause
the technician not to notice, which could cause them to do the wrong procedure.
So they were talking about like the, I can't remember the exact framing now, but
like the severity of the bug and then like the impact of it.
I can't, I'm going to get their word wrong.
I apologize, but it was like, you know, having a field wrong on there is not too
bad.
Oh yeah.
They had a scale basically for the risk of lives.
It was.
could injure multiple people at the same time, or sorry, death, could kill people,
multiple people at the same time.
The second one was, could kill an individual, could cause death to an
individual.
But the same, sorry, the framing was multiple people at the same time as in the
same moment, right?
Whereas the second one was, could kill one person, but it could kill a thousand
people individually, yeah.
And then the next one was, could cause.
long lasting damage, life altering damage.
And then there was a second one, which was kind of less severe damage.
And then the other one was kind of, you know, wouldn't, wouldn't cause any damage,
but they were going through bugs that way.
Like, yes, it's a field wrong on the screen, but the impact is massive.
And that reminds me of like Kelsey's story there where yes, I can't pay, which is
bad, right.
But actually now I'm also embarrassed as hell stood at the front of a supermarket,
which is not even the worst bit of it.
I also can't feed my family.
I can't eat like.
And that's it.
It's not, I can't pay.
Whereas if you remember logging that bug, it'd be like, well, what's the bug?
Well, you can't pay.
Right.
But actually when you come to think about how important is it to fix and you, if
you're not framing it in that second, third impact, it's like, well, you know,
someone can't feed their family.
They can't feed, you know, they couldn't feed somebody else and they can't feed
themselves.
It changes everything.
It does change everything.
Right, yeah, so yeah, another brought another talk into it there, but that was a
really good talk just about how they frame bugs as well and being in the medical
space.
And I've just seen that we've equalized Vernon, get in one, one, one, one, right.
What's the next talk?
What was what's next on Jitslist?
Oh, okay.
Jit says, Emily O 'Connor showed us how to test the chat bot and automation does play
a part.
I've not done it, but have you used any of these recently?
What a chat bot.
Yeah, like an AI one.
I don't know if it was AI, it was just as irritating as all the rest of them have
ever been.
So I don't know if it was.
current context, we use a payment gateway and I went to their docs.
Um, you know, docs are great, right?
Um, but they've turned their docs into a bot.
So not a bot as in a, you know, go read this link bot as a bot as in like chat
GPT, basically framing the docs into answers for you.
I'm like, well, I've got this.
And then it was like, giving me like really good link and a proper answer,
which I tried to do.
And it worked like sometimes.
But then other times I was like, I don't see that button.
And then it would be like, oh, well, you're probably not seeing that button
because you're not on this plan or because this has been configured separately.
I thought, oh, this is amazing.
And then it was like, well, how do I configure that?
And like, it was a very, usually the interactions I've had have been trying to
just get through it to get to somebody.
Whereas this was actually helping me.
But yeah, I didn't go to that talk, but I like, you got to make decisions, like I
said before, but yeah, I've had, I've actually had a positive interaction with
one of these bots recently.
That's, I've heard about that.
You effectively train chat GPT, well, I say chat GPT.
You train your LLM on your docs.
And then you can ask it sensible, like I say sensible, like you just conversate
with the chat bot, with the LLM.
It's like, oh yeah, where's this button?
Oh, you probably can't see it.
That sounds.
That sounds pretty sick.
That was not my experience of the chatbot that I was using the other day when I
tried to get conned by...
He tried to get content.
Well, I tried, I was, oh dear, should I name them?
I won't name them.
But I was renewing a domain with a provider and they said, your domain is
about to expire.
And I was like, oh okay, I better go and pay for that.
And so I paid for it.
And then the message on screen was like, you haven't paid.
Like, oh okay, I'll pay again.
And then they're paying twice.
That's fine, before you go any further, that intrigues me.
Because my brain's like, no, I've paid.
I ain't paying again.
I wouldn't even entertain the idea of going to try and pay again as a solution.
So the fact you did that's also intriguing me.
had that reaction after the second time it failed.
I was like, huh?
Nah, this is that, not twice.
basically, you're happy to pay for things twice.
It's the third time of paying for something you're like, oof, too much.
Go on then, so you've paid twice.
having to interact with the chat bot to try and get through to a human.
And the only thing a chat bot is good for is preventing you from getting to a human.
So that was interesting.
And then when I got through to a human, the human acted like a chat bot and tried
to tell me that they couldn't possibly help me.
It was just an infuriating experience.
until the third person I got a three to was like, oh.
Why don't you call up?
Because the people on the ends of the phone have got way more privileges and can
do way more than, and I was like, why?
Okay.
So then I called and sorted it out in like five minutes.
It was just, the whole thing was annoying.
Anyway, that was a massive tangent.
There was a really good chatbot thing related to this during COVID.
I think it was hotels .com.
They quickly knocked up something.
I don't know if it was AI powered or not, but it was basically allowed you to get to
the canceling of bookings really quickly and get your money back.
Like no questions asked kind of refund.
And the bot was very specifically designed to handle that scenario.
I'm guessing cause maybe the volume of inquiries that were coming in and stuff
that it was an easy way of doing it.
But like basically.
He asked it, he answered a few questions and it just let you cancel.
I don't know if it was a bug, maybe it was a bug.
Who knows?
But yeah, chatbots, they're out there and hopefully getting a little bit better for
certain use cases.
I think it's good for getting information.
I'm not sure about, you know, like getting through a more complex, serious kind of,
you know, give me my money back flow, but we'll see.
let's see.
So the next one Jit talks about was by Stephen Milne.
He says, Stephen Milne showed us how screen readers work and how we can improve
our web apps with a shout out to the BBC Ally team in there too.
Jit works at the BBC as well.
You see he works on the iPlayer and Sounds team.
So as a shout out for the Beeb teams there.
Did you go to that one?
See?
BBC article.
So, yeah, he gave a really good talk about screen readers and from a point of view of
using them, the importance of doing it, like why we should even care, the
importance of accessibility.
And that was kind of like, you know, the underlying thing, but the way he
structured the talk was he showed us.
You know what?
He didn't even show us the actual website.
He first played a recording of the screen reader and says, what do you think this
website looks like?
And obviously none of us got close, right?
It was played at full speed that people listen to it.
Say people listen to it.
The speed that a visually impaired or a person using a screen reader day to day
would listen to it, which I believe was 400 words per minute, I think is what he
said from memory.
Oh, good, good, yeah.
flying.
It was like email field, visible, active, button, next.
And it was like just ripping through this.
And I was like, whoa.
And then he was asking us, right, so what do you think this looks like?
And we're all laughing.
I have no idea.
And then he started basically piecing it, showing us like, do you think it might
look like this?
And then you think it might look like that.
And then he went, let's listen to it again, obviously a bit slower.
And then we're all going, oh, no, I don't think it does look like that.
And we basically got to the end of the page where he showed us what the form
looked like.
And it was a user, your name field, so your full name.
And then there was a grayed out text box for your, sorry, there was a label for
your, even I'm getting it all wrong now.
There was a paragraph with your name, your email address, sorry.
And then there was a button that said save changes.
So.
He then showed us what this page was like, and then he basically taught us all the
flaws that are wrong with this page.
So from an accessibility screen reader perspective, so basically the fact that
the save button was outside of the paragraph.
So yeah, there was the input field, then there was a separate section with the
email addressing as a label, basically a paragraph.
And then there was the save button.
So they were all detached.
So you're kind of now listening to the screen reader and like, well, is this
button related to the email address paragraph?
But then there's no other button on the page and it was all getting a bit
confusing.
And he taught me something because I wrote it down.
So I've built lots of like front ends and stuff like this.
And, you know, if I'm thinking of showing a piece of information, I usually put it
in a paragraph, right?
Or a span or a header or something like that.
-hmm.
even if it's a, you know, like a, you know, showing the results of a form field.
And what this is and what he was showing us was even if it's because it's a form,
which it was right.
It was a form to basically change your name is what this page was showing you
your email address.
Oh, that was it as well.
The email address had a change email button next to it.
And then the bottom of the page had a save button.
I will.
Hopefully you're following along.
But.
Essentially, what are you...
and form was in absolute shambles.
Yeah, but he basically said it was very common pattern that you see though.
Like usually there's a save button at the bottom of a page and then somewhere in
that page, there's information that you can alter.
There's information you can read.
Um, but it's all usually structured in like not in a very accessible way, but for
a screen reader.
So the way he confirmed it was the way it should have been is.
You're the reason why they had the change email on a separate page and everything
else right.
It's cause it's easier from a code point of view.
You have one controller for change your email.
You have one set of code.
You have one page for changing your email.
You have one page for changing your name.
It goes to a controller.
You change your name, right?
Or even an API, right?
However your code structured.
Whereas he was saying, well, no, you need to put them all on the same page and deal
with that logic on the backend.
Make it easier for your users.
So he rewrote the form to have name, email field, and then save changes, right?
Okay.
And then, cause now that's all in one form, the screen reader can understand
that they're related and that the save button is related to those two fields.
Cause they're now grouped together in semantic HTML.
He made a very good point as well about using semantic HTML.
But the thing that blew my mind, which I've never done, and I've built a lot of
websites and pages was when you show information back, such as email, name,
whatever, right.
You should still use an input field, but use the read only attribute of that field
because it then shows the screen reader that it's actually a piece of information
that's been provided as opposed to just a general paragraph on the page that has
someone's name in it.
And then it would say, import read only field.
email address can also because when you use an input field, you get to give it a
label.
And therefore it has an accessible label as opposed to having like a, you know,
styled HTML that, you know, might say email and then your email that isn't
accessible because the screen reader doesn't know they're connected.
Cause the only way to connect stuff is with semantic HTML with inputs and labels.
So if you have a read only field, you can still style it to look.
however you want it to look.
But marking that input field as read only and having a label for it that says email
would make the screen reader go email richard at whatever .com read only.
And it's completely different flow.
So yeah, hopefully I've made sense of what that was, but it was about using semantic
HTML and structuring pages in a way that a screen, it flows for a screen reader
instead of jumping around, which was really interesting.
is incredible.
I think, so I've got a very beautiful teammate by the name of Paul Coles.
He's an absolute legend.
And he was helping me and another one of my teammates.
Shout out to you, Rita, Rita of water.
And we were doing some accessibility testing at work last year and Paul really
helped us level up our accessibility.
know how and he shared with us this really good talk.
I'll find it, I'll dig it out and I'll add it to the show notes because it was the
same as what Rich described.
It had somebody, I'm pretty sure he was, was he totally blind?
I think he was, he had zero vision, I think, or maybe a little bit.
So he used a screen reader and it's exactly as you described.
I didn't know that that's how people use the screen, just that information alone.
was valuable.
So, oh, this is how people actually use a screen reader.
Okay, good to know.
So it's a really insightful video.
I will share it.
It's a really important topic that I think more of us need to start getting our heads
around, even if it's just so the low hanging fruit and the real obvious
mistakes, we can help avoid them.
So thank you.
very much indeed for doing that talk.
Mr.
Milne, you absolute legend.
gave a really good rule as well.
He was like, nothing should be unlabeled.
That was the rule.
That was kind of the holy grail of making sure things were accessible.
So any inputs, anything like that should always be labeled to make it easy to read
by the screen reader.
And the...
Go on.
Oh, sorry.
I was just gonna say, I'm not surprised the BBC, Ally team So for those folks who
don't know, the BBC is the public broadcaster, the national broadcaster in
the UK, I guess.
So the amount of things that they have to support, by things, I mean devices and
browser and all the rest of it, is ridiculous.
So if anyone has to get their heads around this in a real serious way, it's probably
them.
So yeah, shout out to them.
One more takeaway from this talk that came up in a Q and A was about cookie banners.
And Stephen kind of laughed and said, it's hilarious because, well, it's bad, but
like it'd be funny at the same time in that, you know, people aren't paying
attention to this was the people structure them so that the cookie banners at the
bottom of the DOM.
So screen readers basically read the whole website to you before you get.
to the cookie banner because it's been coded badly.
And it immediately made me want to go off and like try on various websites because I
can, in my head, I can view how that would be wrong because you would let, you would
have to label all the pages like not necessary.
And you'd have to, you'd have to really structure the page properly for that.
Cause focus isn't enough.
Like it would read it all and then go cookie banner focus, as opposed to it
being the first thing the screen reader comes to.
And he didn't, he didn't go into lots of answers about how to do it, but it made me
want to go away and go, how would you do that?
How would you actually code that to make sure that that's the thing the screen
reader gets first and not the rest of the DOM, which could be massive depending on
what the page was.
But yeah.
include some links to some accessibility tools and stuff in the.
to say about Stephen as well, he's a developer slash designer.
So again, that was awesome to just have other roles at the testing conference
talking about, you know, testing.
And shout out to you, Steven, you absolute legend.
Okay.
Next one from Jitspost is this.
Colin W.
taught us all about user flow mapping and how it can help build a joint team
understanding of the work teams need to do and to finish off the day.
I didn't go.
Didn't go, but it's something that I do.
I might not do it by the book of user mapping and et cetera, but it's one thing
that I do straight away.
We think we spoke about in one of the episodes, mental models and stuff.
And that's part of what I need to do.
I kind of do them in a user and a technical flow at the same time.
Like I want to, as I'm going through these screens, like the way I draw it, like the
flow across the top.
which is probably maybe close to being the equivalent of user mapping.
But then underneath that, I like to then list what's gone on under the hood.
You know, was it an API call or was it just saved in state?
If it was an API call, was there multiple calls?
Did it go to a DB?
Like what actually happened between those steps?
Cause I need to know that from the way I like to test, maybe a bit more technical
in some aspects, but also thinking of automating it and thinking of data
creation and thinking of state management.
I need that in my head to be able to work.
I'm quickly like Googling user flow mapping.
Cause I wanna know if it's what I think it is.
It is what I think it is.
Okay.
Yeah.
I think this is a very useful thing to do.
And I don't think I've done enough of it over the years in the teams that I've been
on.
So I think I'm gonna give that a go back in the office for my project.
I'm pretty sure where I work, we have some user flow maps for the app.
that I'm working on.
We've definitely been talking about them.
I've definitely been looking at one or two more recently, based on some of the work
that we're doing.
So yeah, and that'd be really useful for me to look at as well, because I'm kind of
new to the team.
So it would help me on board and kind of think, well, what even is going on around
here anyway?
So that would be like a double edged, a double.
And from a testing point of view, you know, similar models, like a lot of models
are very similar, but we get different names.
You know, if you were going to do like, you know, even just the flow diagram that
a lot of us maybe get taught in some of the certifications that exist in testing,
right?
It's like, you know, the different ways decision points you can go to have you
covered the whole tree.
But, you know, it's more from a higher level.
I tend to use screenshots and like, you know, use that.
And then as I said, technical under the hood, but anyway, you need to learn about
a system.
It's going to make you, it's going to help you, especially when you go visual in my,
in my, I love visual stuff.
So.
Well, I like any model that makes it easier for you to talk about the change.
With the user flow diagram, when you're talking about a change, you could start to
say, well, what's gonna be different after we do implement this feature, like after
we create this capability or whatever, what's gonna be different?
And then you compare that up with like an architecture diagram.
It's like, okay.
What calls are being made under the hood when I go from that screen to the other
screen?
Why are you smiling?
Oh God, have we conceded another goal?
No, no, I'm smiling because I can see what you're doing, right?
So if you're listening to this, Vernon's like moving his hand around, but he's
actually pointing.
He's got his finger out and he's pointing.
And me and Mark Winteringham in our automation training, we talk about the
importance of visualizing stuff because of what Mark coined as pointability.
Your ability to point a diagram.
And it is so much easier because if you don't have it,
we're talking about different models in our head and we think we might be talking
about the same thing, but we're not.
Whereas as soon as you visualize it, even if it's the worst drawing in the world,
right?
And we've all done those drawings, right?
Where we start as a square, right?
This talks to that.
And then if that maybe did that, and if that did that, and if this did that,
right?
You've got this epic squiggle on the board now, but because you did it together, you
know what it means.
So when you have this visualization, you can start pointing like, I think it
happens there.
I think it happens here.
Yeah.
to there, you can't do that without that visual.
Well, you can, but there's the danger that you're not on the same page.
So I just, cause I could see you doing this.
It just made me, it reminded me of that.
I wonder how you do that in an accessible way though.
Like say you've got someone on your team who's visually impaired, how do you, how
does that model manifest itself?
I haven't really thought about that before.
It's just because we're talking.
you probably, you probably need the visualization to then describe that
visualization as opposed to basically sharing your thoughts so that they
visualize it in their head their own way.
Here, you would have to say, this is a box connected to another box.
Maybe, maybe be a bit more explicit with your, because I think a lot of people
don't realize as well with visualization.
It's a bit like when we spoke about abstracts last week, it's, it's getting it
out of your head into some form.
It's not going to be correct.
But it's going to be much better than, like me before that, in the same episode
trying to explain, you know, Stephen's screen that he was building, right?
It's, if I'd drawn that five minutes before talking about it, I probably would
have found it a lot easier as opposed to doing it in real time.
So it's that, I think it's that explaining your attempt to visualise and it would
make a big difference.
He just reminded me, so when I was reviewing the last episode, I was doing it
in the kitchen while I was cooking.
And so my wife was coming and looked over my shoulder and looked at, that I was
watching on a Surface Go tablet.
And she was laughing, because like, you're, whenever you talk, your hands are,
you're so much more expressive than Rich, like Rich is not.
using his hands and your hands are everywhere and your face is doing crazy
things.
I was like, oh, okay.
So that was it.
but I Twitch a lot so I'm holding, I've usually got something in my hands that's
stopping me from doing that.
I wonder how that affects things for the podcast.
Like I'm pointing at stuff.
leads into a talk that I know I did go to that didn't, which was, let me find the
notes.
It was Melissa Rocks and it was communication with anxiety.
So again, quite a good interactive session.
want to get into this one Rich, you don't want to check the results.
Me?
Oh, the anxiety of being a United fan.
because we're bloody losing like this is no good.
we're both losing now.
But honestly, Melissa gave a really honest, vulnerable talk about her own
struggles with anxiety and depression, talking about how basically she's quite
open with it in the workplace and how that's improved the way, you know, her
work life, but also how she's now trying to use the same methods with the people
that she's managing.
And there was a few things that came up.
She calls self doubt questions, you know, like, am I good enough?
Can I do that?
Is this and that?
She calls them brain weasels, which I really liked.
And yeah, she was talking about how she has all these brain weasels.
But the biggest takeaway for me was thinking about what you can do to reduce
someone's anxiety in the workplace.
So.
Not even without necessarily knowing that that person is anxious.
I think when you do know that and you've built that relationship, then I think
obviously you should be doing it, but also just generally what can you do to reduce
some of that anxiety?
And, you know, she gave us a, she challenged us to think of ways of, um,
what currently happens that makes you anxious in the workplace.
So the common one that everyone joked about was, you know, um, Vernon, um, I
think we need to have a chat.
Hahaha!
you know, uh, can we have a little talk?
Uh, you know, I think we've all been there, right?
You know, the Slack message, uh, you know, let's have a little chat.
Um, and I think, I think the Slack message is also bad, but I've had it in real life
as well, where it's like, I think we need to have a chat and like, can we not just
do it now?
Like, why are you telling me?
Like, you know, it's like, we're literally stood here with each other now.
Can let's just have the chat.
Um,
And if it, if we can't be done right now, is it really a chat or, you know, like,
what is it?
And then that's it.
You're now anxious.
You're thinking about it.
You're, you know, you worry in.
And then, yeah.
And then she was saying, you know, what could you, what could you do to basically
stop that, you know, to, to reduce that for somebody else?
And so, no, no, there's a step in the middle, an important step in the middle.
She was like, what are other people doing?
And then she asked us, do we do any of them?
So we're all quite open quite quickly about, oh God, I hate when people do that.
And that makes me anxious.
And, you know, meetings with no agendas came up, you know, you know, this, can we
have a chat?
And then we were like, what do we do?
And I was like, well, what do I do?
You know, and I often ping developers saying, can you help me?
You know, like that I was thinking about that.
Is that, does that reduce, you know, increase anxiety maybe?
I'm not sure.
And then she was asking, what can we do to mitigate it?
So I've made a note here.
It was Vernon, can we have a chat?
Don't worry.
It's all good.
You know, there's nothing, nothing to worry about.
Just, just, just going to have a chat.
Does that help?
Maybe it helps.
It depends how much you know that person maybe.
Yeah I still dislike it because I...
you're having a chat with me or just...
friendly may ask that.
I always find it, I'm realizing that I am not, it depends who's saying it, I think.
So maybe, yeah, so maybe it does come down to that trust thing.
But it depends on a bunch of different things, to be honest.
Like when are they saying it?
How are they saying it?
Like even if they're saying, oh, don't worry about it, it's fine.
There's ways you can say, don't worry, everything's fine.
And there are contexts in which you can say, oh, everything's fine, that are gonna
make you think things are not fine at all.
Do you know what I mean?
But I know what they're getting at, for sure.
There's definitely ways you can just not take the necessary care and cause a lot of
anxiety.
Yeah.
just by not being mindful of how what you're saying is going to be received by
the person.
And also if you haven't, if you haven't, if, in fact, forget that, if you, for
whatever reason, if you're not aware of how that person thinks, and that, you
know, if you're a leader of people and you don't have a sense of how the people in
your team communicate and how, you know,
to some degree how they perceive the world and what makes them comfortable and
uncomfortable, then again, you increase the odds of causing some inadvertent
damage.
And that's the takeaway for those on the watching, not watching, I'm just showing
people my notebook.
She made a kind of a call to action to say, look, if your manager's not done
that, you tell them.
So she was like, talk to your managers, tell them about how you would like to be
managed and how you would like to be interacted with that's going to help you
manage your anxiety, if it's the case that you have that.
Okay, nice, nice.
then a fun thing she did, which was she introduced spoon theory, which I actually
knew about, but I asked you off air if you knew about spoon theory.
It's basically, no, so essentially, right, if you're having a really good day, right,
the example would be you're having a really good day, so you might wake up in
incredible mood, you've got 20 spoons that you can spend for the day.
And then certain activities take a number of spoons off you.
So brushing your teeth, having a shower, right?
It might take two of your spoons away.
So now you've got two, you've got 18 spoons, right?
The effort of driving to work is going to take a couple of spoons off you.
You've got to go to a planning meeting that's taken a few spoons off you.
So, you know, come to the end of the day, you might only have a few spoons left, but
you still might have all these tasks to do or whatever, right?
Or if you're planning your day and you know you've got a few spoons.
You can maybe plan it in a way that's going to help you.
So don't do the, I don't know, don't clean the bathroom today, right?
Because you know, you've only got 10 spoons.
That's going to take five off you.
And now you've only got five left for the day.
So she gave us a worksheet to go off that already had, you know, pre -assigned
numbers of spoons for various tasks.
But she was telling you to think about that.
And on certain days where you know, you've only got a few spoons.
make sure you look after yourself and you're selective with the tasks you take.
Um, because also she was talking about how some people, they get into negative spoons
and then they carry that for a few days.
So you might end up, you know, minus five spoons and now you're going to have to get
those five spoons back at some point because you only have a, you know, a
finite number.
So you might have a knock on effect for a couple of days now where you're chasing
your tail or you're constantly tired or whatever, right?
Mmm.
so yeah, that's spoon theory.
It's this idea of having a number of spoons and doing things and spends them.
And even the mundane stuff takes your spoons away, right?
You know, they're just feeding yourself, right?
Cooking, right?
These things take your spoons away, but I think the important one was acknowledging
that, you know, like if you realize you've got, if you've not got much left, maybe
that's a sign to, I don't know, have a ready meal or just have.
beans on toast or something, you know, while we're all the food, right?
Something lightweight, because you've acknowledged that I've spent my spoons
already.
And if I go now and cook myself a 60 minute, 30 minute meal or whatever, right,
I'm going to put myself in negative spoon territory.
So I think it's like an analogy for energy maybe, I'm not sure.
Mood, energy, whatever.
That's almost like, like what's the, it reminds me of a saying, parental advice is
a parental advisory warning.
Like I don't have any fucks left to give.
That's what it, that's what I'm.
what I thought when she said it yeah yeah I've seen people have t -shirts with that
that say no fucks to give no fucks left
what's the measurement of a spoon?
Do you know what I mean?
But how do you know how many spoons you've got?
It's like story points.
How much is one?
If I've got one spoon, how many rich spoons is equivalent to one verne spoon?
I don't know.
That's a good point.
Someone did mention that in our group, I think.
Not all spoons are created, not all spoons are equal, all the activities.
But there was one thing that, the analogy I've just come off, just glancing at my
phone to see if there's any football changes, is just thinking of it as your
battery level.
You know what I mean?
Certain activities on your phone drain your battery.
It'll be the same for you on any given day, right?
I use cooking a minute.
I love cooking.
Like cooking actually probably recharges my battery, like even though maybe
mentally my battery, but not my physical one, obviously, right.
Cause I'm, I'm expelling energy, but yeah, it was really good talk anyway.
And made me reflect a lot about, you know, some of the interactions I have at work.
And sometimes I feel like I don't call out people who do some of that anxiety
producing behavior.
You know, like tomorrow I've got a meeting, um, which is, um, it's like a
late minute kind of, um,
I can't remember what they called it, like, bringing people up to speed kind of
session.
That's all it says.
And it's like, well, what are we being brought up to speed on?
Like, you know, is it, is it something good?
Is it something bad?
Like, what is it?
What is it?
You know, just give us a brief agenda, but like sometimes, you know, I've not called
it out.
Maybe I should.
Maybe like see what it's about I suppose.
Well I suppose you've got no choice, no one's gonna anti -message you.
So it's like, you know, you'll find out tomorrow.
So the last one on Jitslist is Ian Thomas showed us how they test at Meta and more
specifically how to test VR apps.
It's great to see that the test pyramid is still going strong.
Is it?
I hate the pyramid.
I need that on a t -shirt.
I hate the test pyramid.
Yeah, I didn't make it to that one.
I think again, I've got an allergic reaction to the test pyramid.
So, you know, while I imagine it will be really like, it's more the way the,
there's talks from me on YouTube.
We'll do the whole link thing.
We can't do the link thing yet.
We need a thousand subscribers to do the link thing.
These are more subscribers.
Yeah, to do external links, subscribe.
But there's a talk on YouTube where I talk about the pyramid, and it's more when
people use it as a strategy as opposed to for me, a heuristic.
That's my preference for the model.
But I do think it encourages you to think of the layers in your system, which I
think that talk I imagine would have been about that.
What layers exist in a VR?
System that you can test on so your eyes of why it gone.
What's happened?
Oh Oh double whammy 2 -2 United 2 -0 Everton.
Oh my goodness, Vernon I think we might have to keep this I might have to do 90
minutes on this podcast just to get to the end of the games Oh mate feel for you not
So yeah that
But what you've just seen there actually is how I react when I hear the word test
pyramid.
For those not listening, Vernon is in utter despair right now.
But there was one more talk that I'll go to.
But before we talk about the final talk, I just want to, like, this is a talk about
me going to a Atelier right?
But I want to, it shows the power of going to a conference that there was so many
topics that have been open to me.
And now I'm talking about them with you and you're listening to them and they
might be triggering you to go research something based on what we're listening.
And that, for me, that's the kind of, there's two.
There's multiple things, but two that stand out for me with conferences, it is
that connecting with people, networking, friendships, you know, if you're a
speaker, having people come talk to you about your stuff, like there's lots of
ways of actually connecting with people and talking to them.
I think that's massively important.
But then just this kind of trigger to remember experiences and topics and a list
of things to go and look at, like my notes, the way.
Mm -hmm.
remembered how I took notes because, you know, I'm back in the hands -on QE role,
right?
So now I'm, I'm listening a lot more intently to a lot of the talks because,
you know, I'm, I'm doing that job again.
And I remembered that I used to use icons for my notes.
So like, if it's a tool, I draw a little spanner.
If it's a book, I draw a book.
Uh, you know, if it's an article, I draw a little memo article, right?
And that's reminded me of my notes.
Um,
But yeah, conferences, listening to things like this podcast, reading articles,
they're all just great ways of thinking of finding topics that might trigger your
next learning.
Yeah, 100 % folks, like go and consume all the resources out there.
The books, the other podcasts that are out there, the ones that we listen to.
I was just listening to the adobo and avocado.
Is it a podcast?
The live stream with Alexander, Alexandra, she's gonna hate me.
Alex Schladebeck sorry Alex.
Gave you the full name.
Yeah, go and consume all that stuff, but in particular.
Whenever you get a chance, if you get a chance, try and interact with people and
build up your network and build up your knowledge.
And then crucially.
Implement what you've learned, experiment with what you've learned, try and use it.
Especially with topics like accessibility, that's where we can really make a big
difference.
Absolutely.
And yeah, so the final session, not the final session I went to, but the final
session we're going to talk about is Jit himself.
So, we spoke about Jit talking at Periscom, but like Jit is, you know, like
we said last time, fantastic speaker, great at sharing his experiences.
This time around, he was talking about speed versus quality and can we have both?
So the way he structured it was kind of the way that it's viewed, you know, that
we...
We want more quality, so we work harder, right?
So what tends to happen is the amount of effort goes up, but the quality actually
tends to go down because we end up starting doing bad work and so forth.
And, um, yeah, we struggle.
And then he was talking about actually, we don't want to work harder.
We want to work smarter.
Um, but the one thing that I made a note of, he shared a lot of fantastic ways of
doing that, but he called out the, um, the dip.
that you usually see when you start to try and work smarter.
So people expect it just to suddenly go up, but actually you're probably going to
see a dip in quality whilst those smarter ways of work inform and cement themselves
in place.
And then you'll probably start to see that rise.
Yeah, I think I've seen that graph.
Well, I've seen that talk.
I'm just trying to look for the graph.
a pal called Kyle Goodman who runs a software house called Viva IT and he calls
it, what's he call it man?
Something like the trough of disappointment or something like that.
You get a new idea or you learn this new thing.
And you're like, this is gonna be absolutely fantastic, but that's when your
ignorance is at its maximum.
And then as the reality of how difficult or, you know, how it's significantly less
or more difficult than you thought it was gonna be, then you're like, oh God, this
is gonna be so, so bloody awful.
And then you start to climb out of it as your, as your ignorance decreases and your
skill improves.
Well, that's, that's kind of interesting.
So I'm just reading my notes again and like the way he broke down learning smart.
And I think I missed a bit off because I think I was thinking about something was,
um, you need your team needs to adopt that learning mindset.
He was talking a lot about that learning mindset.
Um, but he was talking about two ways, particularly of doing that one is flow.
So the way that the work is flowing through the team and is it actually
flowing or is it, you know, starting to get like, you know, stuck in places or.
so forth, like gatekeeping and things.
But then he spoke a lot about your need to him.
Cause he was talking about this from a whole team approach, right?
It wasn't just like, you know, quality as in testing is the only way, right?
He was talking about it holistically.
And then he was saying about the, in each capability needs also to have a plan to
improve itself, to continue that smart, that, that, um, working smartly.
So, you know, yes, you can do things to the whole.
do air quotes, Agile right?
Your whole way of working your software delivery lifecycle, you can start to make
improvements to that.
But you also need to be thinking, how can we dev better?
How can we test better?
How can we document better?
How can we use JIRA better?
Whatever it is, right?
Constantly having those little areas improving themselves as well within the
wider improvement, which was a nice thing.
And then you mentioned a little bit about metrics.
So, you know, if you're going to start talking about improving quality and, you
know, um,
uh, you know, improving speed.
It's like, how'd you measure that?
Like, what is your measurement of speed?
That's gotta be clearly defined upfront.
And he, he mentioned Dora, um, explicitly about their, uh, mean time to release as
quite a useful metric for speed.
And maybe not so much around quality perhaps, but it's a good one for speed.
Um, so yeah, it was like, if you're going to do it, you've got to do it smartly.
You've got to have a plan.
You've got a strategy.
You've got to be thinking big pitchable, so small capability kind of improvements.
But then yeah, you've got to have some agreed way of measuring it.
Otherwise, you know, if you just suddenly change what, how you measure quality
halfway through, it's going to screw you up.
So.
struggling.
I found the graph.
It's a it's the hype cycle.
It's the trough of disillusionment.
When you get over the peak of inflated expectations into the trough of
disillusionment.
But yeah, I think the thing I want to say about that is I did a
what the name of the course was.
It was a course by a chap called Troy McGenis or Magenis, McGenis I think that's
how you pronounce it.
I think he's a Kiwi, I think he's from New Zealand, lives in the US.
And it was a course about coaching your team with data.
And he talked about Dora and he was like saying, well, actually they're kind of,
they might be lagging indicators.
And what might be interesting, what's an interesting exercise to do is to kind of
say, well, what are the things that precede, say, throughput?
Like how would you know that your throughput was gonna go up or down?
Like if it was gonna go down, you know, maybe you'd over committed to some work in
your sprint or your cycle, for example.
And maybe that might be a leading indicator of your throughput going down.
So I thought that was interesting.
But yeah, anything Jit's got to say about anything, I will listen to.
Is this talk, is that online anywhere?
Because they don't record their talks at Atelier, do they?
I think they go on the YouTube for Tellur.
So yeah, that's a really good point, but I did not even entertain.
You can watch all these talks and realize if Richard's talking utter gibberish or
his memory's shot or whatever.
Yeah, they were recorded.
So yeah, they should be.
They should be on somewhere.
I'm going to guess YouTube.
I'm going in the show notes and I'll try and well depends on when we post this
thing but if the talks are up I'll link directly to the talks if not I'll just
link to the channel and you can see them there so that was that the last
yeah, one done that, one done that, one done that, one...
I went to another talk which was about exploratory testing from Brian Elmer,
which I'd already seen at a meetup in Manchester.
But yeah, he basically gave us a good insight into their view of exploratory
testing, gave us quite a fun challenge of how would you test a lift, explicitly
trying to break down the what you would test, as in, because people generally have
ideas quite quickly, but then also then why would you test that?
Yeah.
explicitly about how you would go about testing that.
So yeah, it was, you know, that's kind of a model I feel you could use for any
aspect to test them.
But, you know, when you, when even if you do an exploratory testing, sometimes the
ideas are flowing, right?
And it's like, actually, what do I do kind of first and go about doing that?
And then he was mentioning one thing I did write down, which was kind of more about
how I view it.
Brian spoke a lot about breaking things and how he loves as a tester, you know, to
break things and he's, that's kind of his mission.
And he's just like, I really want to break it.
I want to find out, you know, what, what fine ways of breaking it.
But it made me think like, I was trying to think of an analogy for it, but yes, I
want like, I know I view things as like I reveal where they're broken, but my
curiosity goes to, and it always has done, I've already mentioned it in the same
episode, but like I'm curious about how it works.
That's the thing I get to.
It's like, yes, this product's here, but I'm like, how was it built?
How was it hung together?
Cause that's going to help me think of ways that I can go about finding if it's
broken.
Um, so I, for me, it's more like, yes, I want to break it, but my immediate one is
how does it work?
How does it hang together?
And I want to know that because then I can find the cracks and like, get my, get my
testing skills inside there and see if I can pull it apart.
That is, yeah, I used to say that all the time, you know, that I break software.
But yeah, I suppose it's not actually true.
It arrives how it arrives and, you know, at least part of our job is to figure out,
you know, what state is it in?
And how does that compare to the state that we think it's in?
a meetup in Macsfield.
It's my developer relationship tester, developer tester relationship talk.
And it's just like little doodles that I draw and I kind of changed the narrative
depending on where I am at the same time.
But one of the doodles is basically putting an X -ray machine over the
product.
And then there's basically broken pipes and you can see the internal workings of
the system.
So I use that to basically talk about, I didn't break it.
You know, like a lot of testers get great pride in going around going, I've broken
it.
I've broken it.
And it's like, well, you didn't break it.
You found where it was broken.
And I think it, I think it's a power, a very powerful shift that not to make the
developer feel that they broke it, but for them to acknowledge that, you know, they
not, I don't know.
It sounds like a blame game now, but like, you know, they.
They did something wrong, right?
They coded it wrong, but not intentionally.
It's not like they went, I'm going to build this thing wrong, right?
But to help them realize that there might be a different way they could have
improved that.
And I think it's kind of a fun relationship to quality too, as opposed to
it's broken fix it to how did it end up broken?
Why did we deliver it broken early on?
And what can we do to stop that in the future?
Right.
I find it because here's the thing.
Ode is not the only way that bugs can get into a system.
So I worked at a place where we used to charge credit card fees when people were
checking out.
They would buy, you know, it was an airline and they would buy their airline
tickets and we would add a fee.
And suddenly the law changed.
Nothing changed about our system except the context in which it operated.
And now our feature became a bug.
And so I don't like to position things as, oh, well, you did something wrong,
developer, because that implies that the only way bugs are created is by them.
It's not really true.
But if you need hyping up testers and testing specialists, quality engineers,
QAs, whatever you call yourself, check this out.
Because I've got a Michelangelo quote for you that describes our job perfectly.
Check this out.
I saw the angel in the marble.
and I carved until I set him free, which is how I like to think about software
testing.
The state of the system, our understanding of it is hidden in the marble and our
tests are chipping away at the ignorance to reveal the reality of the situation
hidden within.
And that's how I like to think about software testing.
So, Vernon and Richard Cho bringing you a bit of a culture and art as well as some
software developments.
think we should even try.
So I think we should wrap it up there.
If you enjoyed the episode, subscribe, please encourage others to subscribe,
share links to the episodes.
And obviously we love feedback, good, bad, share it, comment on it, tell us please.
We definitely wanna hear your thoughts and improve.
Yeah, please like, share, comment, let us know.
We appreciate all the listeners that we've had so far.
Blows me away that people are even listening at all.
Absolutely incredible.
I'm just gonna check the football before we disappear.
leave you in tension Vernon as you're losing currently two now.
no tension it's abject misery we have failed this season it's not good man it's
not good well we won a trophy i guess that's okay but we had such high hopes
was possible and then in a matter of weeks, that's a bit, is that Liverpool a
bit like developers then, you know, building this product, hoping it's gonna
be really brilliant and then just destroying it in a matter of days.
That is disrespectful to everybody that you mentioned in that comparison.
Absolute disgrace.
You see what I've got to deal with here people?
Friendly tester my ass.
Good grief.
On that note, we love you.
Good night, God bless.
We'll see you on the next episode.