Hang tight while we fetch the video data and transcripts. This only takes a moment.
Connecting to YouTube player…
Fetching transcript data…
We’ll display the transcript, summary, and all view options as soon as everything loads.
Next steps
Loading transcript tools…
Critical Thinking in Test Design with Paul Gerrard | Inside The Outer Loop #5 | Curiosity Software | YouTubeToText
YouTube Transcript: Critical Thinking in Test Design with Paul Gerrard | Inside The Outer Loop #5
Skip watching entire videos - get the full transcript, search for keywords, and copy with one click.
Share:
Video Transcript
Video Summary
Summary
Core Theme
This podcast episode emphasizes that improving software delivery quality and speed hinges less on adopting new technologies and more on fostering critical thinking, effective communication, and strong stakeholder engagement within development teams.
Mind Map
Click to expand
Click to explore the full interactive mind map • Zoom, pan, and navigate
then why didn't you test that podcast
want to improve your software join you
rich and their guests they share
experiences and insights on the many
sides of better software delivery
hello again we're back it is uh Hugh and
Rich once more and we are joined by the
legend that is Paul Jared I've known him
for many many years you may well have
listened to him speak at various
conferences uh we normally
somewhere sitting in a bar in Copenhagen
or somewhere like that discussing
discussing what's right and what's wrong
with the industry
um yeah so you know I think I think Paul
is a creative thinker he's always
prodding and poking and challenging and
I think that was probably uh one of the
key messages from his keynote at
Eurostar last year last year
um so I think just to kind of give it
sort of fill you in a bit Paul so we've
I think rich and I and our various
guests have kind of explored quite a lot
what's what's wrong uh with with the
industry uh you know I mean the reality
is that most systems are late and have
relatively poor quality
um with some massive you know
outliers where they're doing a really
really good job so I think maybe what
we'll try and do today is brainstorm a
little bit between us about you know
what people can actually do what what
sort of small medium long-term uh maybe
just starting with a few small things
moving on to some medium things that
have actually made
um a significant difference to
the speed and the quality and that's
kind of what it's about maintainability
testability all of those types of things
that kind of drop out of what we are
really all about at the moment
um you know and and I think
most managers would probably agree that
there are there are some issues
um and then I think you know if they can
just pick up maybe one or two things
here from us that might lead them down a
path or might just actually give them a
few quick wins to improve a few things
so I'm just going to hand over to Rich
now just to kind of so you can add a bit
of color and then we'll let unleash Paul
for a little bit and then maybe turn it
more into a conversation
so I think you know based on my
experience in in some of this might be
quite boring right and then kind of very
much feeds into the Gopher go slower to
go faster kind of Mantra in terms of I
think a lot of
companies teams
um are very technology Centric and
they're looking for the next big
technology solution
um to solve a problem that isn't
necessarily a technology problem
um and you know my history of kind of
working within test teams and trying to
get automation working um
um
kind of failed to do those things a lot
a lot a lot right and
um I had the fortunate kind of I didn't
see it at the time but the fortunate
gift if you'd like of taking me over a
test data team at the time right and
trying to to understand what what does
it mean to make a test data team work
and we we built out a technology
capability uh coincidentally it was with
with with with a past company of
yourself queue and um we had a solution that
that
was brilliant but didn't necessarily
solve a problem okay because we didn't
really look at what the problem was
underneath the covers and a lot of the
time it was around that fact that people
didn't really understand what they were
testing people didn't really understand
what how the systems were supposed to
work and back to my point go slower to
go faster what we found is actually
taking the time to do more analysis up
front and I don't mean analysis
Paralysis on this I mean analysis to do
enough to get consensus to move forward
to the next iteration
um to build out
and you know I I I I I I I don't know
whether Paul regrets coming up with this
at the time but the the kind of the new
model for kind of for testing to build
out a model of what we're trying to
achieve to get consensus to get
transparency that although perceived
possibly to be over analysis
I can't kind of uh applaud teamed enough
for doing that to get ultimately the the
the the the the the industrialization
fundamentals in place to actually
accelerate far quicker and I think there
is so much to getting those fundamental
pieces in place that allowed people to
be agile with a little a
far more than they ever would looking at
that are kind of the next kind of
technology that the the proposes to do
those things
um I don't know I'll open it up there to
to yourself Paul in terms of first
question do you regret that model
because I'm sure lots of people come
back to it [Laughter]
[Laughter]
no uh well I could say certainly not no
um what I would say is I mean touching
on a couple of themes you mentioned
there about sort of fun I mean what you
called analysis and just getting closer
to the problem let's say rather than
getting to and and battled and then
bittered with the supposed solution um
um
I mean the first thing I would say is is
you can't get close enough to your
stakeholders now one of one of the
things well I call stakeholders the
people who are the customers of what you do
do
uh you know so when you test and you
produce some knowledge some information
a report whatever it is in whatever
format that is going to be taken by
someone else to usually to make some
kind of decision either to fix a bug to
uh really system to transition to
another state in the another stage in a project
project
to abandon the project completely to
talk have another meeting about
requirements whatever okay so everything
you do as a tester I think has value
one of the problems we have is we the
value is in the eye of those stakeholders
stakeholders
so the closer we can get to those
stakeholders know what they want from us
the better
sometimes it's difficult because big
organizations often have layers of you
know hierarchies and layers and buffers
between you and the real source of
knowledge and so on and so forth but a
question I was asked when
um I get down and dirty with the testers
and saying look you know what's you know
what could we do better in this in this
part of the world
I usually ask her well who's your
stakeholder and they usually look a
little bit what's up what do you mean a
stakeholder I don't talk to the chair of
the management board you know every day
obviously uh what do you mean by a
stakeholder and I think oh my God here
we go uh because like I said well okay
who reads your reports and and people
say well oh
I don't know really uh and then you say
well what do you put in those reports
and who values what you do and well the
problem I've got is I don't feel valued
at all you know and so on and like
you're starting right from from day one
on the back foot so
so
I first say look I have a think about
who are the people who will take what
you uh whatever you provide who will
achieve value in what you do but the
other thing is like well before you know
what the value is you've got to go and
meet them and say look what do you guys
want from me they are your customers
literally they are your internal
uh testing customers testing
stakeholders so uh identify who they are
uh what they're about what they're
trying to do and Achieve which should
bring common knowledge but sometimes
it's not as liquid uh and then trying to
understand what decisions they need to
make and because the testing is going to
help them make better and more confident decisions
decisions
so understanding their decision process
what they're trying to get out of uh the
project how they think they're going to
get there and their understanding of
what is really of value and really
important and what is really scary to
them and what is a real risk and a real
challenge for them to get over yeah this
is all gold dust to the testing uh kind
of community like in a project because
then you can start saying okay uh okay
so it sounds like we need to pressure
the developers a little bit more to
figure out uh or to get a better handle
on the calculations that have been done
or the user experiment is a bit more uh
important or just the end-to-end flow of
data and you know the whole you know
linked uh components you know delivering
some value at the end of a long chain of
events you know these are the kind of
things that you need to get to
understand because they give you a steer
about what your test strategy should be
yeah yeah I mean I think
yeah I mean I think
I think if you're confident of I mean
you're using the phrase testers and I'm
I'm sort of slightly wary of that phase
nowadays I mean I think it's
um let's just say I don't know whether
the word quality experts let's just sort
of critical thinkers let's just think of
the tester as someone who's a critical
thinker that's really the primary role I
mean a lot of the stuff that you do with
some of your things you know it's two
two boxes on the screen how do you test
it you've got to be you know you've got
to be a critical thinker now if you're
engaging with a stakeholder what you'll
I think you know I've done this a lot
um is that they don't know what they
don't know so you've got to do a little
engage in a in a sort of optimistic and
positive conversation with them and
basically say oh do you know that
actually probably we're spending 70 of
our time hunting hunting for bugs which
turn out not to be bugs
um and that's generally is because of
this and they'll go oh I didn't know
that why why why is that
um and then you're sort of engaging them
and say well actually it's because you
know maybe when you send some of these
things through we don't particularly
have access to some of the pieces of
information and they'll say oh yeah
we've got that that's just sitting over
here all right well fine can we
democratize that out and when do you
make the decisions on that oh yeah we
normally have a meeting once a month and
then we decide on the new meta rules you
know oh great
um okay well you know it would probably
help us out if you could probably you
know if you could just give us you know
maybe get one of us to come to that
meeting or something like that that
would probably save us maybe 20 of our
time whereas we're you know where
because we're sort of two cycles away
from you and maybe try and get them to
to learn a little bit about what it
takes to um
um
improve a system and what what what the
effects of what they're doing is upon
you now that not that's the best way you
know there are different ways that you
can remanufacture the whole process but
even just getting them just to kind of
understand a little bit more don't be
dogmatic about it don't be just say oh
this you know that's that's interesting
you know let me just explain a little
bit about about what we're spending our
time on and then they might go oh okay
and then you're just opening up that
dollar which I guess is what you're
trying to say without without just
engaging with the stakeholders yeah
it it it's easier done in small teams
there's no two ways about it uh if you
are the tester in a large program of 200
people uh it's obviously much harder to
get contact with the senior stakeholders
who in principle are leading
the effort and so should know what the
goals are and should know what their
biggest concerns are but too often
they're too far removed from the guide
on the ground however whoever you work
for and whoever he works or she works
for uh they're the people who need to
have contact and make make visible what
testers could do to say that we're here
to demonstrate things working but we're
also here to demonstrate things not
working so we can fix them and improve
the quality of whatever's delivered
uh it's a tough one
um a little anecdote though if you're in
a I was in involved in a relatively
small project there are only about a
dozen people involved or so
and it was a kind of a new business uh
being put together a startup if you like
being put together by a large Financial
Services business
and the software development was
outsourced the service itself the the
the uh
the people who are going to operate the
service they were kind of outsourced if
you like and there's really just a
project manager uh a CEO a deskaphone
and so on and so forth that was it
anyway so I I staged a kind of a a risk Workshop
Workshop
uh to try and get to the bottom of the
things that were really going to scare
uh you know and and deflect if you like
from the success of the whole program
and they're about sort of uh seven or
eight or nine people uh coming to this
meeting that I asked for and the first
place to arrive was the CEO
who wasn't invited uh and I said oh but
God met him I said okay uh oh thanks for coming
coming
um I you weren't on the invite yo why
are you here at kind of and he said well
the things on the agenda are critical to
my success as a CEO in this business so
I would be remiss if I didn't show up so
they were very deaf he'd very definitely
recognized that the conversations that
we're about to have about what we're
really trying to achieve and what
concerning the way what could go wrong
and so on and so forth uh he was as
interested in the outcome of that
meeting as anybody and contributed like
anybody else so
uh quite often people aren't still
remote we we don't talk the same
language as the guys at the board level
so we don't talk about their business
goals and the risks that as they
perceive them when in fact those are
absolutely the the things they uh live
or die by almost you know their jobs are
on the line if they don't meet the girls
or the things fails you know shot down
in flames kind of thing so once you talk
the same the right language and you make
contact with people that uh
recognize what you're talking about
you're using their language goals and
risks yeah you're in a much better place
um so I don't want to dwell Forever on
stakeholders but uh it's not always
possible obviously I think it's an
interesting one in terms of mapping out
uh what kinds of things you're trying to
prove to stakeholders in the company who
might have an interest or be accountable
for certain things right and because I
think when we're talking about testing a
lot of the time we jump straight to
functional testing we jump straight to
Performance testing and everything else
around that starts to fade away quite a
lot and I think you know absolutely
right in terms of
you know if you went to a lot of teams
and said what are you proving around
resiliency I don't think you get much of
a response a lot of the time but yet
like you say talking to the language you
know companies will live and live and
die by the resiliency of their systems right
right um
um
but I don't think that it kind of transcends
transcends
uh the kind of the low level development
and test approaches into you know what
are the resiliency that's being built
into a system and therefore how does
that then translate into what
stakeholders are and aren't
um accountable for aware of or want to
implement I think that that there's
challenges there when I pick up on um
just to kind of move slightly off the
stakeholder thing and pick up on
something you said there Paul which was
contributed to the meeting now this is a
this is a big one with me and uh you
know I mean I've been running software
companies for a for a long time
um and my wife I think I've mentioned
this earlier in the podcast said
creativity is not jealous
now if you're trying to run a meeting
where you're trying to come to a
consensus come to an understanding come
to a new idea
I think if we're looking for some advice
to give to people who are trying to make
changes in organizations then the
running of that meeting I think was
absolutely critical and maybe it's
something I mean I've written down here
sort of small skill more small small
groups of skills improvements you know
sort of personal development Etc but I
think one of the ones is actually kind
of watching how some people run meetings
and you know pick out the best of them
but the best thing you can do if you've
managed to get that CEO in and and he or she
she
um basically
what contributed in a sort of open open
way that is massive that makes such a
difference the number of meetings where
everyone's grinding out an agenda
um I think we talked about men being the
main problem here
um you know in that you know you're
basically trying to come to a general
solution and if you can not have get the
egos out of there and actually just try
and kick it around and if someone's
being quiet and say what's what do you
think then
and they might say nothing for a little
bit and then I think and then they might
just come out with one little gem and I
think the best meetings especially at
grid tools I remember this we used to
come out of the room and I say right we
came out with two good ideas can anyone
remember whose idea they were and they
went no
which is the it's not jealous in that we
managed to be able to come up with some
with some solutions and they came from
really quiet people actually I kind of
did did write them down quietly in terms
of where where the Genesis of those
ideas came from and if you can run those
meetings then I think a lot of this
communication is is is much easier
afterwards because you've sort of you've
worked on it together you've got that
collaborative experience so if this if
there's ways I don't know whether you
know of any kind of training courses
that people can go on to sort of
understand how you can manage these
meetings and not just repeat what the
last person said you know because
they're the boss you know which is the
big problem with the hierarchies you know
know
but one one is if you drop the year if
you've got the ear of the chief
executive uh which I did on a large sap
project many years ago but I learned so
much from it
um I remember going to a meeting uh of
uh I don't know about 12 12 or 14 people
and it was one of the uh engine offshore
companies who were basically talking about
about um
um
testing something really quite
peripheral to this very large system
it's a 200 million dollar sap project
and as in my first week I was told just
go to as many meetings as you can meet
everyone you can get to know them
whatever my role's an assurance manager
so I was there to oversee the testing
and to give advice earlier on and to
police it later on if you like and so I
was going to be helping people initially
but also policing what they did a bit
later on
so anyway I went to my first meeting and
one of the uh things the culture in that
oil company as it was
that if you're not if you don't know
someone in the room you either ask them
to introduce themselves or you introduce
yourself as the unknown person
so we went around the room and I I got
to meet all these guys and I said well I
work for let's say let's call him John
Smith uh no one recognized that name
until I saw at the other end of the
table someone going I can't do it but
nudging the next person saying he works
with John Smith
hey I could see it going around the room
it's like who was God
and so when I said I think this test
plan is a bit light I mean I'm I'm very
I'm an innocent bye something I'm just
looking whatever they took it extremely
seriously because they realized Craig he
reports to God you know and that is so
powerful so on the one hand it's great
to have the influence of the
stakeholders in the room if you can say
I've got the authority to say certain
things and and complain you know if I'm
talking to external phone but also to
say look uh cards on the table it's a
safe environment uh we can say anything
you know if you've got a problem speak
up let's hear it and let's if you've got
a solution even better let's hear that too
too
so to me it's all about being safe it's
about knowing that you're operating with
the authority of more senior people that
you can say what you uh need to say to
get things done to avoid problems and so on
on
um you need to be a very good listener
sometimes maybe over time I mean there's
all this is all kind of old heart you
know so meeting management is a is an
art I think some people uh have a very
what's the word uh
uh almost like a disciplinarian kind of
thing and just take control of meetings
and basically bark at people and just
get them to do things and then oh it's
yeah but I think when I'm I'm sort of
talking about their creative meetings
here now if you if you need to get some
decisions made fine you lay them out
fine you know someone's prepared for it
but I'm I'm talking about your sort of
you know what's the best way to improve
our process this system this feature
yeah you know that that is the kind of
thing where I think some training in
that space is would be really useful
because it pays massive dividends
well you mentioned critical thinking
yeah yeah yeah I mean you mentioned
critical thinking and and uh
if if the people out there don't know
what it is uh they should look it up and
just find out because it's where you you
essentially don't take anything at face
value so if if person a says makes a
statement uh you have to understand who
person a is and what perhaps their
agenda is uh what where they're coming
from and what angle of attack they're
coming from in terms of making progress
whether they are a supporter or a
resistor to the system because that
person might be managing a big team
that's going to be laid off because the
software is going to eliminate their
roles so they might not be a supporter
so you have to understand where they're
coming from you also have to understand
what their kind of background and
mentality is or attitude is to software
development they may love software and
want to help and contribute they might
be a Luddite and just refuse to get
involved not come to meetings always
negative you know so you have to
understand that
but the critical thinking aspect is
really about
can I take this person's
at that word you know what they say is
is what they believe it could be true
and they are truly trying to help and
that goes for everyone in the room so
the information that's shared in
meetings and shared on documents and
emails and slack and everywhere else
uh can you look a little bit further
than just the text you see because
you'll find schisms in projects between
individuals who may not want to work
together but have to because of the
project and people who are really
totally enthusiastic and massive
contributors and other people who really
don't you know and so critical thinking
is about saying do I take what I'm given
at face value or do I look a bit further
into it into its uh completeness its
accuracy its consistency and whether
it's true you know so when it comes to
requirements usually we have lots of
gaps in requirements that we cannot test
against and you say well if I can't test
it you can't damn well build it you know
to developers and yet they have a try
anyway you know they can always in the
absence of requirements they'll make it
up now that's a bit of a harsh criticism
of Developers
but when people are under pressure to
deliver if the requirements aren't good
to the developers have no choice but to
try and build the best do the best they
can and they will try and build software that
that
um they believe meets requirements that
may not have been explicitly stated
now the Tesla's got a different problem
in that it's very hard to create a test
without knowing what the actual outcome
of that test would be just because if
you don't have a definition of a
behavior say
any outcome will do you know because you
don't have anything to compare it with
so typically testers are great people to
have in the room when requirements are
being uh elaborated discuss formalize
whatever terminology you want to use
and so the critical thinking comes in is
that critical thinkers would challenge
your requirements in and by that I mean
they don't get annoying with people they
would say here's an example you know
here's an example of the behavior of the
software if I do a b and c I think d e
and f should happen
is that right
now you might make that challenge and
give that example knowing there's a gap
in the requirements and the answer
cannot be found in the requirements and
that's why you've asked the question
and so by asking by providing examples
it's a
that's what it's like non-challenging
challenge if that makes sense you know
it's not a difficult thing to answer and
what tends to happen is is the users
analysts stakeholders customers
whoever's in the room
will either say you've got that
perfectly right and I'll say well okay
but I got that from my imagination not
from the requirements so is there a
graph in the requirements
but they might say well how do you get
that idea and I said well there's no
requirement there so we need a
definition of how this software behaves
in this circumstance
and occasionally getting meetings where
projects are under threat of uh
cancellation I mean I've had one project
canceled because of an awkward meeting
where it just hadn't been thought
through uh and it wasn't a late stage
one of uh challenge it was quite early
but even so
um the tested role I think and the value
of what tested to is they they
don't take things for granted they don't
say okay the requirements are good
enough for me to write some code that
may or may not work that's not good
enough for a tester the tester has to
have certainty about what the software
is about to do and what it's about what
should do and how they're about to test
it so they have to have a much firmer
understanding a firmer grasp the the
interpersonal skills required are asking
good questions being a good listener an
active listener uh being diplomatic when
it comes to asking some awkward
questions and saying I think we have a
problem here because here's an example
of uh behaviors that I think none of us
understand because we haven't thought
it's through and so on so there's a
whole raft of interpersonal skills
coming to play to try and get to the
bottom of certain problems which very
often at the start and the early phases
of a project are about all about requirements
requirements
and also saying you know has anyone
thought about performance has anyone
thought about security you know I've had
that yeah we've all had those meetings
where you say I don't see on anyone's
agenda on any documentation anything about
about
reliability and availability and stuff
like that I think it's important yes or no
no
uh and a tester quite often is a person
who asked because like am I responsible
for demonstrating that this system is it
fails over correctly uh the availability
is up to your performance and security
and so on and so forth so
so
getting engaged with the people as many
people as you can as early as you can in
the projects as you can
um by and large pays off I mean I think
there's a massive contribution to make
there Rich anything to add on that I I I
I I'll just go back I I think there's a
there's a there's a real uh
uh strong point around psychological
safety right and I think the seniors in
organizations and seniors in teams set
the agenda around
um the expectation around challenging
and candid Challenge and things like
that and some organizations have got it
right some organizations say they've got
it right but haven't some organizations
really don't care
um and I think you know that that's
that's a a large factor in the ability
to I think ask a lot of critical
questions and kind of go
uh resolve a lot of systemic problems
that kind of reside in organizations for
longer long long time and you know are
the years of so many kind of failed
attempts at lots of things we will do in
tests around kind of delivery and around
trying to get things automated lots and
lots and lots of things
um to your also to your point again I I
whether those things are strong or not I
think there's always an opportunity to
pause Point very early on when
projects are forming and storming in
terms of trying to figure out what kind
of their blueprints are to go and ask a
lot of questions around you know to the
point what is it what is important what
isn't important to set out the
expectation that these questions can
either be answered now or they need
answering right because if we get too
far down the line in a project and that
question's never been answered Chances
Are You Know by the time kind of
delivery is the only thing in the
crosshairs that's gonna code way down
the list when it gets to kind of should
we resolve this thing too difficult
let's pay lip service to it and fire it
out the window and you know yeah
I like the one where we you know it was like
like
652 critical bugs which just became 652
documentation they just re-categorized
them that was that was a classic
very large company never mind
um okay good I'm just going to bring in
one more thing we haven't really talked
about tech here today maybe we should do
another session on Tech and just talk
through that I think we've you've had
another session on uh kind of AI it um
Etc now there's one thing that I think
as well with my because I I've had my
65th birthday the other day I've been
doing this I think even longer than you thought
thought
and uh you know yeah look at looking at
the uh the you know the good and the bad
teams that I've worked with over the years
years
um I think there's a thing that also
people sort of forget about is the
balance of the team you know in terms of
the different types of people that are
in that team you know um you know do you
have a snowy for example which is uh you
know from from Nationwide who every team
should have a snowy
um so you know it's just Dean parent
when you
so you know it's like I I don't want to
bring in I don't want to get you on
football or whatever but I mean you know
you don't need everyone to be to do
everything you but you do need someone
who's sort of very very anal or sort of
autistic about details and you inject
them into a certain point you do need
probably two creative people now they
might be creative in a sort of UI type
of way but they might not be
um you know creative in terms of putting
together complex chains of systems but
you might have an old an old hand who's
seen everything that's gone wrong in the
past you know that literally if we don't
get the validation right on our on our
payments messages which is you know I
don't know how many times I've seen this
one then all that's going to happen is
the bugs are gonna data's gonna creep
through it's going to make it through
one help two hop three hops four hops
the fifth hop is going to pretty much
destroy the system now if you can stop
that stuff at the beginning now what you
need is kind of an old lag in there
who's sort of seen it all and said look
we really do need to focus on this and
maybe we should focus on a much more
rigorous set of
um rules to reject Data before it gets
in and you know that's a contribution
they would make you might have then
someone who's saying oh yeah yeah we're
going to use all this latest cool
technology we can do this that and the
other thing and you say cool that's
that's really good idea but let's try
and set that up as we're going to do it
we're going to go into prototype mode
for that let's go and experiment the
difference between you know Kafka and mq
or mq light or whatever it is let's just
you know because it what was what we're
hearing from the analysts who I don't
trust at all is this is
um you know fantastic
um but then you go eh let's apply a bit
of critical thinking on this and do some
experimentation and you put that person
on that and I think having that blend
allows you to move along much more
um much more effectively I mean in
Holland they use colors I think everyone
is allocated a color based on their
personality type and they try and create
teams which which have all the different
orange Blues Reds Etc so and you can't
have everyone in the same the same type
and I think it's almost like a transfer
system in in in in I've been in America
soccer football
um so where you almost say look we've
got three Strikers here you know and
it's just not really working so maybe we
can move them around between some of the
teams so what are any thoughts on kind
of how well that's always rich on this
one in terms of what you think a good
team isn't
so so I I think um
um
there's two answers to that right in
that you've got a team that faces into
the problem today and you've got a team
that faces in and starts to
start to resolve any team that faces
into the problems of of tomorrow right
so so by that what I mean is um
a lot of teams
when their first forming I think will
have you know if you if you look at lots
of organizations lots of test teams
they'll have lots of people with a lot
of head knowledge
and separately there'll be lots of
people that have technical testing
capabilities I.E the ability to code
some Frameworks or something like that
right and those smes probably have a lot
of analytical understanding that's great
I have a silo of a test team knows a lot
of things okay what are we trying to
achieve right and so by this I'm you're
probably by saying snowy you probably
Focus me on this a bit too much around
certain certain team in a certain
situation all right so that's great for
a time being we're able to get to a
certain place but we know that's not
sustainable we know that's not what are
our objectives right so what we want to
do is we want to codify our head
knowledge we don't want it stuck in
either testers or that 25-year Unisys
person that's been in the organization
is just about to retire we don't want
that stock in their head and actually
what they know is probably Limited in
terms of its structure anyway so let's
build back to Paul's model let's build a
model of common understanding of how
systems should work or what we're trying
to prove here right and how do we then
codify that and automate that because we
want to Chuck out something as quickly
as possible but we all understand that
you know that shared knowledge that
understanding that needs to percolate
around the testing actually we you know
we've already talked about collaboration
when we need to build out relationships
with Architects with designers to make
sure that you know we're not building
these things far too late in the
development life cycle they've got skin
in the game in terms of what we're
trying to achieve as well and they're
not feeling challenged from your thing
doesn't work right actually we want to
build this thing together up front and
you know what in time if we're building
a model who cares who builds it right we
know that we want to get the different
perspectives in a room to build this
thing because we all know that there's
benefit in getting different lenses
different contexts on this thing because
we all see it in a different light right
and therefore if we understand those
things we can build out automation be
that design build and test off the back
of that we we create a lean pipeline
right of things that if it goes wrong
there is collective buy-in around what
we did and why it went wrong so it kind
of eliminates the blame game as well and
I think you know to my point
we started with a silo a very good
individual Jewels but what we built out
is a collective capability that has
um a collective accountability about it
going right or going wrong I think is
kind of
a good Evolution Evolution if you like
of a of a skill set that I think we
should be building as a kind of a team
delivering test
and wider well thoughts I I I'm reminded
of um uh
something called Duncan uh the team
roles I think if you've heard of that
it's a bit longer than two so it's been
around a long long time uh but I only I
mention it uh because it's kind of
interesting I think I'd hope be an
interesting aspect of this is that
people tend to be good at and prefer
certain roles
so uh from memory I haven't done a bell
bin test for oh decades I'd say but like
I think I was a plant or I think it was
called a controller list I was either a
team lead kind of role or the ideas guy
you know they they kind of the problem
solver you know oh he's the smart guy in
the corner give it to him he'll stole it
and that kind of game I was definitely
not a complete a finisher who basically
do all the legwork and get the job done
and get it through the door and there's
a facilitator and from memory there's
someone called a facilitator I think or
they may have a different name but
they're kind of the glue that hold the
team together they provide like the
social context if you like of the
conversations meetings all that kind of
stuff and so on
um now one of the things about being a
consultant and I
uh mentioned this only because I don't
think people are too should be too fixed
in these specific roles as a consultant
when you come into a project and you
look around you think there's no
leadership here
maybe that's the problem or the or
there's a leader but there's no uh
thinker or as there's a leader a thinker
but there are no completer finishes
everybody's facilitating but no one's
actually doing their damn job you know
so you've you find you get involved in
these projects in that way and say like
somebody needs to go away and do some
leg work for three days to come up with
a spec for the work or a plan or whatever
whatever
to get this uh project moving again
um and so what I found is uh not that I
can do every role by any means but I
found myself very often dropping into
roles I wasn't comfortable with but just
to get
the you know you get called in because
something's slipping behind Okay well
what can do to do that okay we need to
in a hurry get the automation sorted or
we need to in a hurry clarify the
requirements get some specs for the
testing to be done so we can yeah I mean
I think that's cool it's actually a
really good experience
taking over those jobs because you
actually do understand the pain I mean I
remember we did uh yeah when we were
we were doing CA uh we were bought by CA
and I said well why don't we try and get
the the Tester the sales people to come
and be a tester for a day
raged outraged
um you know but anyway they trooped in
to enchant and we sat them down and we
did uh we basically got them to uh we we
found one screen and just said okay off
you go you you test it so we got one
there and they just they just randomly
clicked around and looked grumpy and
then we switched them around and said
okay what I'm going to do now is you're
going to test it and you're gonna you're
gonna look at it and you're gonna write
down what the other person is going to
do to test it
um so then they had to kind of do that
and then thirdly we said well why don't
we just model it and we'll just generate
all the automation code and test it and
by the end of it they went oh my God
that's what people do all day long and
they basically spoke to QA managers for
their life you know and it was like oh
you know so you know I I wasn't
particularly the point of where I
started with this but your comment about
you know having to put many hats on to
solve problems actually it's really good
experience for everyone so maybe maybe
that's that's something we should incorporate
incorporate
the whole thinking hatch thing I think
it's a debono idea where uh the hats you
know you get these multi-colored hats
you know like a red blue green black
sort of stuff and I can't remember I've
I've made a little experience with this
but uh literally you could be in a
meeting and everyone uh is wearing a
certain hat and by wearing the Hat you
say I'm gonna be the uh ideas guy
um oh I'm gonna be the black hat I'm
going to be and I'm going to get this
wrong but in terms of these roles but
I'm my thinking and my attitude to the
meeting is to be much more pragmatic uh
practical get things done another one
would be I'm going to facilitate the
conversation and so on so forth so it's
a bit like Belvin but whatever but every
now and then uh the leader of the
meeting whoever it happens to be at the
time so that's right that's also perhaps
and then you change your perspective so
I'm going to be the customer now and I'm
going to be the supplier take the
suppliers uh position you know uh now
you know so and that gives people
different perspectives which is exactly
like uh sending your uh sales team into
the test team
like a recipe for disaster but um uh I'm sure
sure
I think many years ago we did a
performance test but completely manual
we it was a a help desk uh application
being built in a in a call center
and it was a brand new building brand
new teams everybody was new but the
people were there were 100 people
already you know women who have been
trained but also were there to help us
with this performance test so we got
them all in the call center we had an
earlier early version of the software
and we brought some sales people in and
they said uh and they all got stuck in
they had kind of scripts but they had a
free hand they had to do quite a lot of
what they what they were doing and they
said they'd ever had more fun in in
business yeah yeah it was like I really
enjoyed it right
um we're running out of time so uh as
ever Paul
um it usually goes on for quite a long
anyway it's been a pleasure uh seeing
your happy face again
um thanks so much for your insights I I
do feel like maybe we should do another
one in a few months and maybe just focus
on Tech and you know stuff like that
yeah yeah
anyway thanks Rich yeah uh thanks we'll
leave it there we'll leave it there so
we're just gonna leave thanks so much
bye-bye thanks for listening to this
episode of the why didn't you test that
podcast to continue the conversation
head over to
curiositysoftware.ie and don't forget to
subscribe for more episodes [Music]
Click on any text or timestamp to jump to that moment in the video
Share:
Most transcripts ready in under 5 seconds
One-Click Copy125+ LanguagesSearch ContentJump to Timestamps
Paste YouTube URL
Enter any YouTube video link to get the full transcript
Transcript Extraction Form
Most transcripts ready in under 5 seconds
Get Our Chrome Extension
Get transcripts instantly without leaving YouTube. Install our Chrome extension for one-click access to any video's transcript directly on the watch page.
