Hi everyone, my name is Patrick Akio and if you're interested in
the role of a QA engineer nowadays, this episode is for
you and it might not be what you expect.
It has a lot to do with developer way of working and how
to deliver value for the business faster with quality in
mind. Joining me today is Augustine
Zocway, QA Lead, and I love his stories, He's an amazing
communicator. So enjoy this episode.
What does quality mean for you when we're talking about
software engineering? So quality, that's a buzzword,
right? And it's quite a broad word.
So quality means different thing for different people.
Yeah, if, if I'm an auto engineer in a building cars,
quality is a whole different thing, right?
The tyre don't need to fall off when a car's driving, you see.
So quality is a different thing in the medical section.
Quality is a different thing. Well, so quality depends on what
we're working on, right? We need to have a defined set of
qualities, attributes that we need to track based on the
application, the users. So yeah, quality means different
things for different people. So I can, I cannot have a single
definition of quality right now unless I'm looking at what we're
talking about, what is the application or the, the subject
we're talking about. Then we can define that quality
based on the risks, the the usage, the uses, the impact.
So you can come together and then define what quality level
are we talking about. Yeah.
Is that also nowadays the role of AQA engineer within a team?
Because I've never worked with a person that had that role, let's
say within my team, quality was always kind of how do you say
that conventionally understood by developers were at least
spoken out and we tried to uphold it, but there was no QA
engineers. I don't know what their role is
nowadays within a team. I know from history kind of what
the role was, but I think it's evolving.
Yeah, QA has evolved. I, I hope that he has evolved,
at least definitely for me, he has evolved, you know, moving to
the right direction as well. So yeah, to your question, yes,
I think that could be part of QA role also depending on the
level. So let's say in QA world, you
have different levels of QA, right?
You have people focusing on different things, right?
Automation, general QA practices.
You have some that are coach in AQA, you have QA lead just like
I am. And then you have people doing
different things. It's quite the broad world,
right? So in terms of defining quality,
I think is where we can take a lead.
Yeah. For whatever team or teams that
we're working on, I think it's something we can take a lead,
get the awareness out there, help engineers understand that
quality is not just testing or writing test automation.
It has more, more broad practices in order to achieve
specific level of quality that is defined, that is needed.
Yeah. So I think QS can take a lead on
that. It should be.
It should be part of QA role. What are some of the practices
that you've seen kind of work out in practice or are some of
your favourites to kind of implement within teams to up the
quality there? Pragmatic practices, more
flexible practices. So when we talk about QA
activities, OK, which practice is one of them?
It's many. So the one that I, I think that
worked very well, I wouldn't say the one that worked very well.
It what works for a team a might not work for a team BI like
that. So the, the, the, the role of
AQA should be to assess those, look at the problem itself.
Don't be flexible, open minded while you're looking at the
problems. So you can actually draft what
can help, which practice, flexible practice, pragmatic
practice that will help that team move forward.
So one of them is, I think one of the experience I had in
mirror is, you know, I started in mirror, you know, things are,
you know, working, finding out things, defining things.
But then my manager came one day and said, you know what, the
experiment we're doing, it's taking too long, right?
And why is it taking too long? Well, then I was like, OK, we
need to write automated test. We need to do some manual
testing. And engineers will continue, of
course. And bless them, they were
listening to me, right? They start writing automated
test. But at some point AB test is
about getting it quick out there to get a feedback back, right?
And then you can see the winner and then you can, you know,
implement the winner, right? And that stays right.
So at that point, my manager said it's taking too long.
So when I went back to the team, you know, they're writing
automated test for the things that we might throw away.
So at that moment, even though I said like we need to write
automated tests for the features we're giving to customers, it's
just for me to take a step back and look back and said, OK,
let's discuss this, right? Let's talk about how we're going
to remove the waste. Let's be practical, kind of
pragmatic, right? Let's do quick manual test
during the AB test and write specific unit test that we know
that that component stays, but the UI will change.
Let's just not write end to end test so we can move quicker,
right? And during the clean up, we can
have that task defined so we can write an end to end test.
That's just small example, right?
And then we win the time, we win the lead time, you know, you
know, So for me, I looked at it in a different perspective.
OK, now we need to stop doing this, right?
So we can clean up that. Another thing again is when
we're even with automated test, when you have monolith, things
can go wrong, right? So defining, finding out that we
ship something, it comes back with the issues.
I just decided to find a better way.
That means, OK, let's do test session every time before we
deliver. Let's just come together, take
an hour, 30 minutes, whatever the engineer needs and go
through the application and give the quick feedback to engineer
so we can actually move forward and deploy what we have, even
with automated tests. So these are little things you
can actually be flexible in fixing and and yeah, so this is
how I look at practices that are beneficial.
Yeah. And not go into the mainstream
process and those are good. You need to have it in place,
but you need to be smart based on the situation of what you
what you're building. I really like that flexibility
in the example of AB testing because in the end, you're
right. If we develop a feature that is
going to be AB tested and it doesn't deliver the value that
we think it needs or it's actually more harmful than
helpful, then yeah, we can throw it away, right?
And I think less is more. And I think more and more that
mindset is there as well, that if you keep on building
features, then at some point you just have a bigger application.
And a bigger is not always better.
It needs to be effective in what it's doing.
And at some point, people don't want a toolbox.
They just want one tool to solve the problem they have.
And if your toolbox doesn't solve the problem, then it's a
waste basically. And the same is for then the
quality that you put in that feature to make it future proof.
But if it doesn't have a future, then it's a waste of time.
Basically. That flexibility in how you then
align with the people that say, OK, things are not going as fast
as well as with the development team to still build in that
baseline of quality that it needs because it still is going
to go to production. It still is going to be AB
tested. I think that's very helpful in
the situation because I've also had people, and that wasn't
necessarily in QA, but engineers can be dogmatic or people within
tech can be dogmatic when it comes to their practice, right?
I've had people from architecture starting from
scratch where we already have a journey and we're just trying to
involve them for their opinion, but they want to have
everything, according to the book, basically without any of
the context or without any of the kind of fast pace that we
want it to be. Same for security.
And I think in QA there's probably similar people also in
engineering. So that flexibility and open
mindedness, I think that's very helpful there.
It's definitely helpful. I I understand that as AQA
probably talking against myself, not to follow process.
Yeah, we need to process, but we need a smart process, right?
I think today in the world of software, it's about how quick
can you get the feature out there, you know, how fast
because everything is online, right?
So we can have a process we follow, but we can also have
that process but adapt the process.
For me, it's all experiment, right?
It works when things change, application matures, team
matures, engineers matures. So at the beginning, you might
define as best set of process, but as they mature, some might
be taken out because it's a waste, because they already know
what to do. Things have moved on.
If you used to find 20 bucks in application and all of a sudden
you start finding 5 bucks, you can adapt the strategy, you can
adapt the approach and even be more quicker.
So you remove those waste. So I think focusing on removing
the wastes, by the way, that's the whole point of Agile.
Finding that way you can remove the the the the waste and
improve as you go is very important.
Yeah, I think it comes with team maturity as well.
And it's it's very interesting for me that you can have many
senior engineers with the years of experience and when you bunch
them up together, it doesn't make a team yet, right?
Those people have still have to figure out their own way of
working within this new team, regardless of what past
experience they have. That might even be an anchor to
some people 'cause it kind of closes their mind rather than
being flexible and open new suggestions and new ways of
working. You said the word ways of
working. Yeah, yeah.
So in my experience, I've seen really senior developers, but
when I sit down with them, my previous, previous companies,
they have not actually sat down with a QA or anybody to do like
pet testing. OK, so and that doesn't take
anything from the experience of what they do, but it's just like
they haven't done it. They usually have someone that
would test what they do right and then give them a feedback
and they continue. So, so when I sit down with
them, it's more like, OK, this is new, you know, then that's
where why I have to explain why am I doing that?
What's the benefit? What is in it for him, right?
This is not just me trying to do something, but what are we
doing? So some some engineers coming
together doesn't necessarily mean delivery will be fast, but
we need a process in place. We need an approach, we need
strategy. You know, when 234 people speak
one language, it's quicker, you know, to have a communication
and work together, right? Because they, you know, they
have and aim and role the goal, you know, to deliver this
quicker. But if front end is developing
that side and back end is developing that side and all of
a sudden front end is waiting for back end, there's no
communication, there is no process.
We're both can actually walk together in one.
So you see, you could lose one hour, half a day, a day.
Winning those things back will actually speed up delivery.
So I like focusing on how can we deliver quality of speed and
yeah, keep working on that in a different ways, right.
You meet different situations, step back, open minded.
Listen, I learn a lot from engineers and those people, even
though they have not worked together with QS sitting down
one place, yeah, there's a lot of knowledge you can pick from
them as well. Why you give them that little
piece they don't have. You can learn a lot from them.
And yeah. That's awesome.
Yeah. But that, that role, how I had
it in my head, that's an involvement from how it used to
be, right. You already mentioned that some
engineers are used to, some have not even written their own
tests. And then that would be the role
of QA right next to actually writing the tests.
Also then functionally going through the application.
And then from the engineering side, my assumption is that they
wouldn't really know what actually goes to production or
what a user experiences with regards to what they produce.
Now you're saying this role has evolved, and I agree it has
evolved because from my side, I haven't worked with QA, which
means QA is kind of integrated in engineering, which I think is
a good thing. But then you still have to have
someone, whether that's an engineer or someone that
fulfills the role of QA, figure out that base level of quality.
And indeed having the conversation and being flexible
and making sure that delivery also has quality there.
Yeah, I mean, definitely evolvement is part of AQA and
there's a lot of story in that. But I just like the way it's
evolving, right? And the mindset is more the
difficult part because engineers, which are good
people, we, some of us still have that idea that someone have
to test my work, right? And give me a feedback that I
did well. I want to believe at least my
version of QA is, I want you to be able to confirm your good
work and sell your good work and be happy about it rather than
waiting for someone else to confirm it for you, right?
So it definitely have evolved. And I think every QA tester,
while we do what we do, we do test, we still find bugs.
It's still on our responsibility to help engineers to understand
the craft there, right, the craft there.
Because those days it used to be that testers will go all land to
find issues and bugs. I think the engineer himself
that's writing that code will know the place to press a button
and that breaks. What if he gives us that
experience and finds a way like, OK, I know how to test this and
I know where it's going to break.
I wrote this code and I know the soft part and the weak part.
You know, senior engineers knows that and with the craft of
knowing what to test, how to write, automated test, they
would just do that immediately. Even it doesn't matter which
lower level test he's going to write or higher level test and
QA is right there with him to go through that.
So you all I'm saying right now comes to collaboration.
So this strength, the strongest strength in software development
right now for me is collaboration.
If you collaborate with these different disciplines in a team
and you push the software, you are more happy and you are more
confidence in what you're doing, right?
So yeah, they all have evolved. And I, I just cycling back to
the question of Q as I think we should be more participating
with engineers, you know, and take lead.
It doesn't matter whether you're a lead or tester or just take a
lead on project you're working on, on the story you're working
on, and bring that information to your team.
Possibly teach them how to do that, because then they can
already clean up some of those things before it gets to you.
Or maybe it doesn't even get to you, it just goes straight to
where it's supposed to be. So and yeah, I think we should,
it's a very good thing that we should evolve and take lead on
that QA. When we're talking about this QA
career path, you mentioned tester, you mentioned QA within
the team and also QA leads that are more so overarching within
the team. Is that like the typical path
that you might grow into this field of QA?
No, not really. It's it's, it comes from, it's a
personal thing, right. So I've seen I used to be
chapter lead in previous company and I have one of my direct
report changed from QA to dev op.
He was just too good to be just QA.
He was really good at scripting and all that.
You know, move on to dev op, that's where you need it.
So I think it's, it's a personal thing where your passion lays
and some, yeah, it's a personal thing.
It, it can go many ways. So Qas can be, I've seen a QAB
product owner for QAB engineering manager.
So QA is more like crossroad from there.
Experienced QA can actually be anything.
Some can talk to developer, you know, developer and test.
There's a lot of stuff you can do when you're a good QA.
So I think sky is, is your limit what you want because you touch
all those things you get experience from engineers from
if you look at the whole entire QA practices, it involves all
these things, right? You know, I'll say project
manager, even developer, engineering manager, team lead.
So there's a lot of stuff you have in active building a
software that Q is involved in. So you can be any of those.
Interesting. Yeah.
Do you think from a career perspective, cuz that's some of
the questions I get from the viewing audience, is OK.
I'm trying to, I get my first job in tech and I want to be
developer. I want to be XY and Z or I'm
trying to transition into a role and that could be anything, but
I'm trying to figure out what a good start would be.
Would you say a good start in this field of tech could also be
QA? Because from the Contra side, I
do think you need kind of a base understanding of a lot of
practices and indeed how you would collaborate effectively.
I don't know if you could have that when starting out.
As an engineer, to transition to QA is possible.
I've seen that. It's not common, but it's
possible. Yeah, it's definitely possible
because I've seen there are some engineers that I've met along
the way in all the companies I've worked with here really,
really good. So QA has have this instinct or
intuition, call it intuition. If you have 6 developers that
are, once they focus on more and there are ones they just said,
OK, I, I, I know he's, he got it.
OK. You know, so those engineers
that you know that they know all the things they need to do in
testing, literally might not even find issues on, on whatever
they create or they've gone through the steps.
Once they have the process and strategy and approach defined,
they just go through it as fast. You can just leave those ones a
little bit. Don't bother them too much, just
leave them because they know what they're doing.
So I think those ones, some of them might develop even more
passion into going into QA, maybe more like develop
developer in test to develop more frameworks, writing test
automations, coaching about that.
So yeah, it's possible, but it's not common.
Yeah. And also for people then
starting out, would you advise kind of QA as a starting point
or would you advise kind of gaining experience elsewhere
first? That's a good one.
So starting up as a QA it's possible.
There's a lot to QA, but starting up, I say a tester like
you learn things about QA these days.
The word QA is actually, yeah, it's it's used a lot.
Yeah. I would say you can start up as
AQA, but there are basic things you need to do.
You need to understand how software has been built.
You need to understand how project is works.
You know, you need to understand a lot of technical stuff.
Then you start with testing. You have to touch, you have to
use your hands and test stuff. You know, I short story, I just
started as a normal tester. You know, I just have to test
the application, go through it, run through it, check all the
type of things before I even move to automation, right?
Because things have to work before you automate.
So as this starting out, I think the person can call himself AQA,
but I think the content of what he needs to do is to understand
the basics, which is how to test the software, right?
How the software works, how is it being built?
Understanding the simple methodologies, The functional
part of it, yeah. Yeah, I think that makes sense.
And the only way to go through that, I would say, or a more
standard way to go through it is indeed more functionally first
from a user perspective than trying to figure out how to
automate more and more and indeed work more collaboratively
with developers, right? That's how you gain that
experience in, OK, how do we work together?
What is this way of working and how can I influence that to
indeed improve the quality there?
That's a mindset to you these days.
I think you can even start quicker because if you look at
the tools that is coming out these days, right, a lot of
people can just start by automating, right?
Yes. You need to know how to use the
software, use application, know what it is.
Of course, you probably have that computer, probably I'm too
old in there right now, but I think people can start quicker.
Actually, people can start quicker just by writing
automated tests. Just do a little bit.
Not even functional test, like every other experience QA
started. Yeah.
I think young people these days can really just jump into it and
learn how to code. Now tools are making it even
easier these days to write automated test.
Yeah, yeah. And the little knowledge they
get, they can get it by just building the pro, you know,
that's online project everywhere that you can just keep
automating and learn how to do those things.
Yeah, I think to start up, it can be quick, you know, So I'm
not too sure of my old way of doing stuff.
I think things are much, much easier to start up right now.
Yeah. I'm curious to hear your take on
kind of the future of this QA role, because if I take my
experience with operations, it's now no longer in most
organizations a separate role. I think more bigger
organizations still have an operations department.
But indeed we're moving from developers and operations to
more DevOps and engineering where the operations part is
also done by partially developers in the end.
And I've been on the operation side and I would say, OK,
ideally you don't have operations, right?
In an ideal world, you go to production and there's no
issues. You don't have to investigate
anything operationally, but in practice that's still the need
for it. I think for QA it's kind of
similar, but I'm very curious to hear your take on how this is
going to evolve in the future. So it's definitely evolving now
how it's going to evolve in the future, I don't know, but here's
my take. So my take is the teams
structure and the way software has been built is changing.
It's becoming faster that automatically will force Q as to
evolve. You don't have, you don't have
option to stay back. You go with it.
That's that's the whole point. That's the passion I have about
QA. You just go with it.
It's changing. You build teams that are
changing, you just go with it. And so the evolving part is to
take lead of what is happening on the testing world and evolve
with it. My personal view it's I see
teams are teams are needing more a way to build software quicker.
Now we used to say, oh, you build too quick, you can
compromise the quality and you build too slow, you can
compromise the speed because we need to deliver.
My view is how can we balance those?
So I think every QA will learn how to evolve on their own path.
But what I can say is evolvement is definitely in the package
that we don't have option to stay back.
We need to evolve. To your question, I think in the
future there will be. It's already happening that you
get about 5 teams. You don't get 5Q as now you
might get tester, functional tester, but it will be
overloaded to work for five teams.
Yeah. So when we say QA, it has a
different meaning. So that means that this QA have
to find a way to operate in these five teams and that means
that the QA have to zoom out, how can I help the teams.
That's a whole different story on it's own.
But yeah, evolvement is based on that.
We are becoming more broad than more specific, so I don't even
know if it's tea kind of. It's like queues are becoming
more of. You have to be a good
communicator in the 1st place. You have to know how to design
processes and approach. You should be able to solve
testing problem on the fly as they come because they're
different issues that is happening.
So there's a lot of just to name few of this, there's a lot of
stuff that QA need to do in order to get those X teams
working and have that quality mindset and tell them, you know,
help them build that software moving forward.
So yeah, to cut it short, I think evolve evolvement in the
future will be more like taking a lead.
Now I'm not talking about QA lead, I'm talking about every QA
person, every tester have to take a lead.
And that lead, well, if you take a lead means things have to
change. You adapt with what is happening
and you help find a solution, testing solution, of course.
Yeah. So I don't know the package of
what tomorrow evolvement will be.
But right now we are on what I call a different level of
evolvement in terms of QA. We are expanding.
Yeah. And it's basically because of
that trend that you mentioned, right?
The competition is now so high, I would say everyone can pick up
a programming language and start executing.
But then the way you execute as well as the speed of your
delivery, how fast you deliver value in comparison to your
competitors is starting to matter more and more.
What have you seen in kind of either way of working or indeed
in executing that helps engineers or companies deliver
software faster while not compromising on that quality?
So what I see is a QA plays a a good part in that anyways.
So what I see is for a team to do that, there has to be some
level of collaboration. So I remember I that's it's a
framework I designed. So this framework I designed.
So that means that to deliver anything you need people.
Yeah, right. You have the product you want to
deliver, you need is process for that.
So in those three things team need to figure out a ways of
working, right. And when I say a ways of working
could be a lot of stuff, but it's just a team to agree on a
specific set of quality activities you focus on the
quality of what you want to deliver, you focus on.
And how are we going to not even how to code it because we're
building a solution first. We need a solution which is a
product. How are we going to build that?
How are we going to test it? How are we going to automate the
entire pipeline, right? Because to deliver fast, you
need to have some set of automation in place.
That's the only way you can speed up the, you know,
delivering fast after building it might take you a day or two
before you even get it to your customers.
Now how can you get it shot? So I think for team to do that,
there has to be a level of defined ways of working that
everyone is on board, on board with.
And there has to be a certain level of collaboration between
the team. You know, don't wait too long,
don't go online searching for something you don't know for 3-4
hours. Why don't you just ask the guy
next to you, for example, Hey, I'm going through this, do you
know, can I get a, get a help solved next?
You know, so these are the level of things the team needs to
have. So all this will be in the ways
of working. Yeah.
Remove waste, be pragmatic, be flexible.
Meetings, know the real ones, how to test the application.
Most importantly, automate the entire process if you have to.
If you can't, then automate what you can exactly in terms of the
process. So these are the things team
need to have if I'm forgetting something.
But at least I believe in collaboration in team and ways
of working will bring team further, of course with a
quality mindset, of course, yeah.
And this standardized way of working, I'm assuming it really
helps for the person that has what you've had in the past
where you are the QA lead, let's say across multiple teams,
right? Because if you have to adopt in
ways of working across teams and then also get the context, it's
way harder for you to go in, help A-Team and then move on to
the next team with a different problem if you have to adopt
every single time. Yeah.
So walking in multiple teams was really fun, I would say.
Oh, that's good, it sounds fun. That doesn't mean it's easy, but
it was fun. It was it was challenging.
So I think the path to that is focus on one thing at a time and
you focus on one team and if you see all the practices working,
you pocket that and then look at another team and see where you
can help them with what you have and add the new stuff because
everything is different. I have these teams, but they're
all different people. Yeah, different characteristics
in a team. They're all working in different
domain of the product. So it's not necessarily that
solution for A will work for solution for B.
So that's where the fun part comes in.
So it works for this guy, this team, beautiful.
And you go to this team, they have a whole different kind of
thing. But some of the things you've
done there are basics that can adapt and then you flexibility,
you step back, look at the real problem and find a testing
solution for that. So this is just how you get to
trickle those to the around the teams.
And, and as I do that, you'll, I learn a lot and learning that a
lot based on the experience of practical working solution is
not a theory. I actually don't like the I, I
come up with the theory theory, but I need to see that it's
working. So learning that will help me
help other teams quicker. It's not the same, but it's
quicker because I already have some set of things that works
here or they didn't work. I can advise them this doesn't
work. Look at that.
It doesn't work over there because at the end it's one
product. So, so that's how you can
actually in a nutshell, work across the teams.
Now there is all the problems as well that comes with it.
Because while you're you started from team one and you're about
team four, the team one will be having problems, right?
You need to go back and say, OK, guys, you know, what are we
doing? So this is how it works, but
also fixing the issues and going back.
And then the only key you have is collaboration.
You know, you collaborate very well with the team.
The team knows you, you you lead by example.
That's the point. I say that Q as also need to
lead. You need to show the team this
works. You know why this should be that
why we should do this feel that pain with them.
The problem some of the QA's have is we get stuck in a
process and we don't feel the pain of developers, engineers,
you know, you need to feel that with them, have that
conversation with them and they will know what is in it for
them, what you're trying to tell them to practice.
So that's very important. And and that's how you just sell
it to the teams, trickle down to the teams.
And and of course, there is cost of maintenance that things, you
know, things evolve. Yeah, some sudden things might
not be necessary for this team and just remove it.
Allow them to evolve. You know, I won't stuck on, oh,
you're not doing this process and we need to go back.
No, you're wasting the time. You know, you see them doing it
and they're moving forward. Push them, you know, to move
forward. Yeah, but how much do you push
them? Because when you get into a
team, let's say you have in your toolbox some ways of working or
some suggestions with regards to improvements, what you're going
to try out and you're going to experiment.
And at some point you might be anchored and you want to say,
OK, we have to try this further and actually see if it bears
fruit or the engineers have to say it doesn't really work for
us. At some point you're going to
say it doesn't work. But there's this balance of
being flexible or not being too flexible, let's say.
And at some point, proof is in the pudding.
I wonder how you judge, let's say, what works or what doesn't
work and what to incorporate or what to drop.
That's a very good question, by the way.
So being too flexibly, it's easy to become complicit with what
you've done, right? Yeah.
So I just try to avoid that. So I do look ahead.
It's not always like thinking of something and I'll come and give
it to team to try. No, it it doesn't work like
that. But I do look at the I do look
ahead. Sometimes I identify gaps in a
team and I'll approach the team and said, have you noticed this,
right? I think this might be that or
this right now, these are professional engineers.
They know, you know when they understand when you explain it
to them very well, right? So that allows me to to not be
over flexible, you know, because I know if they say, well, we
know, but we don't need it now because of that.
I listen to them as well. So that's the only way it works.
I listen to them, they listen to me, right.
So we need to understand each other.
So I try as much as I can not to be too flexible because there
are still some necessary process that we need to follow.
Yeah, we need to make sure that requirements are there before we
start developing. There's no other playroom for
that. If you don't do that, the the
cost of that is having issue of building something wrong or
going back and forth and don't waste time, right.
So we need to agree on that, you know, so everyone knows that.
So with that we have set of rules.
So it's not even being flexible. The flexible part is, for
example, hey, we have definition of done check box for example,
right, If you finish check box, I've done this, I've done that,
I've done that. It's good at the beginning.
But these are professional engineers when they do it often
checking a check box becomes a big problem.
It's second that is wasted. Yeah, Why force them?
Leave them. Just leave it.
I remember asking one of my teams, I want to know why you
guys are not checking the check box.
And I give them a set of question.
Is it because you don't see, you don't know it exists?
Is it because you already know what you're doing?
Is it because it's just too much work?
All the questions, you know, I'm paraphrasing now, but they just
agreed that we already know what we're doing.
That's a that's good. That's great.
Yeah. So, so I don't push them on
that. I just leave it.
But the good thing about that is if something is happening, they
have retro, they will remember we used to have this, can we
bring it back now? I think it's the role of AQ way
to make sure that those things exist.
That thing can always cycle back to that.
Yeah. OK.
So there I'm not flexible and there I'm flexible right on the
other one like requirements and that you know, refinement the
outcome of those scrum ceremonies, if it exists or
Kanban need to be clear. Now you still cannot force the
team to do that. They have to see the value in
it. So it there is flexibility which
you present things to the team, I think is on a queue a person
to be able to convince the team. You know how it how hard it is
going to convince 1 developers. I know, yeah, yeah.
And I think in my sub stream I think we have about 30
developers. OK, gotcha.
A different story, yeah. So I, I just, it's not credit to
me, but credit to the team, the professionalism they have to
understand what this guy is saying is good to try, right.
So we get that done, put that in place so everyone can at least
follow all the stuff. Yeah.
So I'm probably too flexible in some things that I don't know,
but yeah. And you're very conscious about
it, at least how you're explaining it, which means
you're well aware of what to be flexible on and what is, let's
say, what you cannot. Compromise on, yes, I think.
That's important. Yeah.
And collaborating with the team talking helps to understand what
they need and what they don't need.
And if, if, if Qas do that, it's hard to be of a flexible because
you need to understand what the team needs.
And we work for the team, not for us.
We are part of that moving one thing from A-Z, getting
something built a solution and deliver it to customers and make
sure customers have usable product.
So we're part of it. So we need to talk and
communicate with them and reason with them as well how we can do
that. So with that it's it's hard to
be of a flexible. Yeah, it makes sense.
One of the things you mentioned kind of triggered my thought
process in something we do as consultants, right?
CB As a consultancy organization and as you come in an
assignment, one of my goals is to make sure I find a
replacement and at the end of the day, make myself obsolete
because a corporation is better without consultants.
Basically, you don't need help if you don't need it.
At the end of the day, the role is either to make myself
obsolete or to make the role obsolete.
And one of the things you mentioned in QA, in educating
people, helping with ways of working, when things are a
smooth operation, you are kind of making your own work obsolete
in a way, shape or form. What are your thoughts there?
Is that something you take pride in fulfilment in or is that more
of a scare? So the first part indeed, you
make your work, well, not the work obsolete.
You make yourself obsolete. Yeah, exactly.
Yeah, yeah. And I, I take a huge pride in
that. That's weird.
You know, you, you, you're happy when you're obsolete.
That's weird. I recognize that, though I I
also take pride in that. But I, I, I, I really feel
fulfilled when I see the team try when when I'm needed less
with the deliver quality stuff out there and customers are
happy and I'm part of that team. That's beautiful.
I like that. So that drives me like, you
know, at some point, yes, the team doesn't need you, but
that's good. Yeah, for the team you might not
be good for. Me, but it is a mission
accomplished. But I feel good about it, so I
have to find something else to keep myself busy while I wait to
see how we can maintain what already exists.
You know, things like that. And so yes, we do feel obsolete
at some point, but there are so many other stuff that we can do
as well. So we can help the team identify
Q as can see, you know, gaps and see, you know, if we continue
doing these things can change and communicate that.
So as much as it looks like we obsolete, there are other ground
works we can do. We can also prepare something
new. You know, I remember I worked
with, I have to mention his name and Danielle, also consultant
from Sabia. So he was on mirror.
So that was when he came as an agile coach and I was working,
you know, we had a conversation like, oh, OK, how's the team
doing? You need to do that.
Don, have you done this? Your team done.
And he looked at me and said OK. Good stuff, yeah.
My question was, what can we do next?
You know, I'm always looking for the next.
I'm always looking up to where else can I improve the team?
Where else can I help the team improve?
Where else can I even help software development improve?
Wherever I am, if I'm in any team at all, can I help them
improve what they currently have?
And that is always my outlook. And I, I remember we came up
with this framework, you know, you know how we can evolve.
When you meet a team that's already evolved, they do things
themselves. Like you said, I'm obsolete in
some sudden things, a lot of stuff because they're doing it
themselves, which is good. How do you evolve them further?
How do you ident help them identify things they've not
because team can be delivering fast, but there are other things
that can actually improve to be better.
Yeah, as opportunities, so. Yes, opportunities, that's what.
How do you figure that out? So yeah, we sat down and
developed this framework and we start working teams through it
like, hey, you can identify your level of performance here and
see where you have some. Maybe you're missing some
observability, you know, maybe you're getting the data but
you're not using it. Things like that.
I don't want to go into too much details about that, but there is
always next. So we're not completely
obsolete. If the QA himself wants, we're
not obsolete. Exactly.
There's always problems to solve.
Yeah. I love that, man.
I think I've really enjoyed this conversation.
I love the way you communicate and it really shows that you
also take pride in communicating well because otherwise I don't
think you would have done as well on this podcast.
I've really enjoyed it. Before you round off, is there
anything you still want to share?
Yeah, what can I share? I just so I'm moving on to a
different life that that that I never thought of OK, being
outside employment, just being contracting like so I have this
few period. I think every QA, just what I'm
going to say, every QA or tester or whatever, I take a lead of
what you do. You will evolve from there.
You know, sometimes we don't know that we can actually take
that lead. The title doesn't matter.
Just go for it. Take a lead, you know.
Beautiful. Yeah.
All right then. Thank you so much for listening.
Let us know in the comments section what you thought about
this episode and we'll see you on the next one.