How Insurance Works

How To Get Quality Assurance – VLOXX E1 – With Albert Starreveld, Developer at Xpirit

I always compare test automation
with Gru and the Minions. Hello everybody.
Welcome to Xebia VLOXX. Today a nice chat with
my colleague Albert Starreveld. He’s going to update me on
what’s happened… since my experiences with
functional testing in 2007. We’re 12 years on, and he’s going to
explain to me its current state… and tell me what I’ve missed. – My name is Albert, I’m from Utrecht… and I’ve been a software developer
for a really long time. Predominantly .NET stack. I’m particularly interested in
clean code stuff… and from there,
I started studying: continuous delivery,
continuous integration… test automation
and security as well. And that’s why I’m sitting
at this table, I guess. – Yeah awesome, man. I want to talk about your vlogs,
because they’re about testing? – My blogs…
– Oh, did I say ‘vlogs’? – Yes.
– That was a profession deformation. Coming from the world of security,
I’m quite liberal in testing. My experience with security
and security testing is simply: ‘Let’s break it’,
you know? But I’m going back in time a little further,
because around 2007… Before that, I was in the Army,
where I also did a lot of IT and testing… but that was more for fun,
separate from my regular job there. But in 2007 I started working for a company
that is renowned for its testing. They hired me as a functional tester. And I really didn’t have a clue… so I got three days to study
the TMap book… but within those three days,
I was already assigned. And basically,
my testing looked like this: Someone’s describing
what they want… and based on that description
you’re figuring out how to test… and then you put all the tests
in a huge Excel sheet. Only in reality, the description was
scanty or not available… so you just did whatever. The handbook called it something like:
‘exploratory testing’… so I thought:
‘Oh cool, I can do that.’ Just dicking around a bit, you know… and I’ll see what happens. And during that dicking around,
I began to find security issues… which turned me into
a security specialist… and I left functional testing
behind me. At the time, I saw that
describing didn’t go well… and if it was done at all… then people were busy writing
all kinds of test cases. When it came to the crunch,
the test environment wouldn’t work… so it all took a very long time
and was sluggish. We’d prefer not to make time for it… because after so many months of building,
we finally wanted to go to production. So testing always got
briefer and briefer. All in all, a tricky problem. I remember that at that time,
test automation was emerging… and I can’t remember exactly
what it was called or what it did… but it was in the form of tools… that would check your screen
to make sure everything was in order. I’m sure you can tell me
what it’s called. It was that time period… and since then I haven’t really been
dealing with it… only rather distantly. So tell me where we are now. – Where are we now… Well, I think the most interesting thing
is not so much the technology. What’s most interesting is… the process of describing,
as you mentioned before. – Alright. – So basically what you see is: First, people started
designing a system… and then we’d build,
build and build. After that, fewer and fewer tests
before moving to production. Then there would be another design phase,
with design after design… then we’d build and build,
and then we’d test again. So what you’re basically seeing… is that at the end of such a process,
you’ll get exploratory testing. So you’re going through
an application… and then you may wonder:
what is exploratory testing? You may wonder
what testing is in the first place. And what you basically see
is that testing in such cases… is to discover the behaviors that are
intentionally coded… but perhaps also unintentionally. – Yeah, but how do you
make that distinction? – I’ll get to that in a minute.
l’ll finish my story first. Anyway, what you see is
that at the end of development… you check the system’s behavior
and capture it. Then you give your judgment on that… so that takes intellect to tell
whether something’s right. – But that’s a gut feeling? Common sense, so to speak? – Yes, but it’s also a bit of feedback
to your client: ‘Hey, was this supposed to happen,
or is it seriously going wrong?’ Eventually you will have a judgment
and then you’ll say: ‘It’s good enough… ship it!’ What you’re seeing these days is that
everyone wants to do short-cycle testing. If you look at old release processes,
you’ll see that testing takes a month. It’s often an entire month they’ve planned
and with so-called ‘code freezes’… people are no longer allowed to make
commits to certain branches and such. But now you see that developers
want to do trunk-based development. So we want to have one branch
and that’s where we work on collectively. We’ll add feature flags and then we’ll have
all the code in one branch. – ‘Feature flags’? – That means you can turn
off and on functionality. – Oh yeah, okay. – And so called ‘dark launching’,
which means: ‘I’ve built a feature and I’ll turn it on… but I’m already pushing it
to production.’ As soon as it’s good enough,
then you’ll switch the feature flag. And then the program knows:
‘Now it’s good enough.’ And then you can use it in production. But if you want to release
every week, every day… then you won’t have enough time to test. So you have to do something. Testing becomes the bottleneck
for getting to production quickly. – Yeah, exactly.
– That’s what we see. That’s where test automation
comes in now. So basically you want to make sure… that you can still test code,
very quickly and briefly. I always compare test automation
with Gru and the Minions. – Okay… – Because Minions are always
really silly… and Gru always has a master plan. So you tell a minion:
‘Go ahead and do that.’ – I can tell you what the title of this vlog
is going to be. ‘Gru and the Minions’
– Nice. But there’s this scene… in which a lab technician from Gru
blows up a Minion with helium. And those Minions are like:
‘Oh that’s fine, go ahead.’ Eventually, the Minion hits the roof
and he is stuck there, looking like: ‘Well, what do I do now?’ It’s the same with an automated test. You just tell it to do something… and then it’s going to do it. But the important thing is
that an automated test is not capable… to make a wise decision about
whether it’s a problem when it fails. – Yes, exactly. You need something or someone
to validate? – Yes, you kind of need to. Not just that… in automated tests you basically translate
manual tests into a set of checks. So things that you can easily
check automatically. So if the button’s still green,
and if it still displays ‘5’… and if the SSL tab is still green… then everything’s fine. But whether a green button makes sense,
within the context of a form… you don’t know. So actually, with test automation… we translate tests into simple checks… that you can perform
quickly and automatically… so you can get to production faster. But that doesn’t mean you don’t have to do
any more exploratory testing… or in other words,
click through your application and see: ‘What kind of behavior do I see?’ And: ‘That test
that I automated over here… does that still make sense?’ – Yeah, but if you look at
that piece of logical reasoning… which you’re not automating,
because it entails more than checks… where do you do that
and how is that no longer a bottleneck? – Right. There are of course
many different ways to do that. You often see that people believe… that it has to be done
one way or the other. Let me get that out of the way first;
that’s not true. There are a hundred different ways
to test software very effectively. You can do that automatically
or manually… that doesn’t matter. Let’s just assume that
you’re testing automatically. I think it’s important
to take a step backwards first… and to say: ‘Let’s do some testing before we even
start building the software.’ Determine what
you’re going to build first… in a very concrete, testable,
measurable manner. So translate every requirement
into a test case. Then you can discuss that
with your product owner and stakeholders: ‘This test case I’ve set up here,
does that make any sense?’ Now you’re thinking:
‘What’s that guy talking about?’ – Well, it’s going well so far… – I like behavior-driven development. Which means you basically use
the Gherkin syntax… as it is called… to formulate ‘Given – When – Then’. So you write out all your test cases
in the form of ‘Given – When – Then.’ So you got a baseline. ‘Given’ an employee… ‘When’ he tries to enter… ‘Then’ he is granted access. ‘Given’ a guest… ‘When’ he tries to enter… ‘Then’ he will be sent to the reception. So in such a form… …just very human sentences
that you use to describe… and you can communicate about that
with your stakeholders and PO. – But who creates these statements? – Well, you can get all kinds of
different people to do that. For example, what you can do… with a small delegation from
the team and the product owner… you can draw up
what the stories going to look like. Eventually you can discuss that
in consultation: ‘Is this what we meant?’ And the product owner could also
discuss it with the stakeholders: ‘Is this roughly
what we meant?’ By translating it in such a way… you can almost speak of
test-driven development… Maybe a little bit misplaced, huh? But actually, you came up with
a test right from the start… and then you start building. That functionality is not part of
your software yet. And as you continue
to build… you can just run all those checks
and test cases in your software… and see if everything
still works. – Actually, you’re saying,
if I may summarize briefly: Automated testing is purely about
performing checks… you shouldn’t expect to see
logical reasoning. So start with logical reasoning… and use that as a basis
for the checks you automate. Did I get that right?
– Check. Nice.
– Did it make sense? You must have seen this
go wrong as well? – Yes. – Give me some examples of
what not to do. What unpractical things
do you encounter? – Look, the whole purpose of
such an operation is actually… that you can check the approval criteria
of all your stories in a very quick way. What I find a little inconvenient
in such a case… is when you link that to
a very slow test mechanism. Which means you’ll have to wait
an entire day, maybe even two… before you finally get feedback on whether
the software works correctly or not. So that’s something
that often goes wrong. – But wait a minute… So that test mechanism is something manual,
or automation that’s just super slow? – Automation that’s slow. That’s just a waste. You want to accomplish a test suite
that can tell you within five minutes: ‘It’s working, ship it.’ So I’ve saw test suites
that ran for ten hours. And then there was one test in it
that didn’t work at times… so you’d have to run it again the next day. – That requires a lot of
maintenance, right? – A great deal of maintenance. So what about the costs and benefits? – If I go back to my times… 2007 you know, ancient history. Those testers back then,
what are they doing now? – What are they doing now? You need to be
a little more specific. – Test automation was really small
and very limited at the time… and there were a lot of people
reviewing the requirements… and make huge test sets for them,
figuring out how to test before production. You could add more weight to
what was important and critical failures. But they were doing a lot of brain work. ‘How am I going to make sure
everything’s in order?’ But what’s their job now? – What’s the tester’s role? – Yeah, that’s the question. Which is different from
the role of the automator… do you know what I mean? Maybe those two belong together. – I’d rather formulate it differently: ‘What role could the tester play?’
– Yes, okay. – That might be more interesting. I often hear companies say:
‘We don’t need a tester anymore.’ That seems to be a trend. And what you often see…
– But wait, what’s the reason for that? What’s their justification
for saying that? – In DevOps,
everything needs to be automated… and tests need to be
automated as well. You can often see that
the tester from 2007… referring to your example… is often not able to code,
or only mastered the basics. That can be a hindrance
when you start automating things. – Yes, of course. So people tend to say: ‘Let’s create a team of
developers only… and they will be able to
perform the automation… and they’ll be able to write
those automatic tests.’ And I think the art of testing
is a little underrated. – Yes, that’s mainly looking after
your own interests. I’ll build something first and then…
– It’s not even that… I think testing goes way beyond
just writing test automation. It’s not just a technical operation. I think testing has to do
with communication. Communication is by definition
that you are going to tell something. So I got this idea in my head… and my brain translates that
into movements of my lips… and its sound waves bring it
right into your ear… and then you receive the message. – Testing is physics.
– Yes, practically. Then you will process it… and you’re going to try and reconstruct
the image I had in your head. Now, by definition,
from everything I say… approximately 25 percent
reaches you. – In my case, maybe less. – Maybe even less. But that’s what you see
in software, too. So if you’re translating
your idea… then you have a very good chance
that the developer… who eventually receives and interprets
all that information… has gotten a different picture than
the initial idea behind the software. That is simply very likely. So the testing goes beyond
just looking at technology, but also: ‘To what extent does the original idea
match with what is built?’ So translating from
‘someone with an idea’… to ‘measurable,
concrete test cases’. That’s what you used to see
in those old school test cases… you already saw that in that Excel sheet
you were just talking about… in pseudo-code kind of things. So that’s still relevant. It’s often the part
that gets lost in translation. So I think it’s very important
that the tester continues to do that. – And by ‘that’ you mean? – By ‘that’, I mean checking if
what you’re building or what you’ve built… is precisely what was intended.
– What the expectations were. – Did you build what the client wanted? That’s not about checking,
but communication. And then you translate communication
into checks that you can build. When you start automating everything,
you get thousands of tests. Thousands of green lights
is in fact just data… how are you gonna distill from that,
if that big switch is green… that you’ve still built
what that customer wanted? Or if you change one feature… what impact does that have
on all the other features? – Actually, you’re describing
this scenario: ‘Green lights, but the product
doesn’t do what the customer asked.’ – That happens?
– That happens very often. And I think the tester’s role
is to secure… that what’s being verified
in an automated manner… also really makes sense. – So basically, the tester goes from
functional tester to testing automation… or not even testing, but validating that
automation measures what you want to measure. – Managing the automation. Also worth mentioning: Collecting specifications about
what you want to build. I also think that testers
could code the testing process… but I think that’s risky… because you often see that
developers build untestable code. Then it arrives at the tester… and he’ll face the greatest challenge
in writing test automation for it. – What do you mean by
untestable code? What should I imagine? – Well look, test automation
is a very neat concept… and in the beginning of
my career I even heard… that you can just test each piece of code
in an automated way. That’s simply not true. You have to write code in a certain way,
according to certain principles… and if you follow those,
you can run automated tests. If you don’t adhere to
those principles… it may turn out to be very tricky. – Explain something about those principles,
because I don’t quite understand. – A very important one is
the concept of inversion of control. Sounds really technical. – Explain the principle
I don’t need the technical stuff… because this doesn’t make
any sense to me. – It’s a tool that can help you
to make things testable. Let’s just say you have
a piece of code… and that’s linked to Equence,
a credit card service. As soon as you want to
test something… it sends a payment request
to Equence… and they’ll charge a credit card. If you’re gonna run a test there,
you can imagine what will happen. – Yes. – ‘Let’s see if we can charge
a million dollars.’ – In my time, we had stubs… so you’re were communicating with something
that just pretended to be Equence… and always returned the answer you wanted.
– Right. And in order to activate
such a stub… in a way that doesn’t slow down
your test automation… you need the principle that
you can inject such a dependency… but can also replace it. So what you’re saying: ‘I’m only dealing with payments… and then I have the Equence payment
and the Test payment.’ So for every module in your software,
you can inject that kind of code… so it’s not linked to critical resources,
so to speak. You have to apply those kinds of principles
to get testable code. – Yeah, I get that. But being able to code or script that… is that important for testers, or not? Let me put it another way: Can you survive as a tester
if you are not able to? – Not in every company. – Okay.
– That’s the reality. I think that should be possible. – You should be able to survive
if you can’t code? – Yes.
– So basically you’re saying… that writing the test cases
can be done by someone else? – Yes. – Which tasks remain for the tester? – Writing the test cases
is done by the tester. – Ah yeah, sorry,
but the automation… – The implementation of the automation
can be done by the developer. Only they have to have
the same idea in mind. – Yeah, I do think it’s important for a test
to be so straightforward… that you can form an opinion about it
as a tester. So if you have a unit test with
80, 90 lines per unit test… how are you supposed to
evaluate that? Suppose you have 6,000 unit tests,
2,000 BDD tests and 10 end-to-end tests. If you have no idea
what those 6,000 unit tests check… how can you assess
the quality of the application? So you should be able to
say something about it. And maybe a developer
should help with that. – In security,
we have secure code analysis… and that could be someone
who reads through the code manually… to see if you’ve made
any security mistakes… but it can be done automatically. Ideally, it is a combination… in the appropriate cases manually
and in most cases automatically. Why can’t you just test the code,
to see if it does what it’s supposed to do? – That’s possible, right?
– I don’t know. – Yeah, that can be done. You can use different tools for that. Security is an unpleasant subject…
– Thanks. – in the sense that when you build code,
you have certain principles… that you can follow or not follow. And if you don’t follow them,
then it works too. So those are often the areas
where security vulnerabilities are born. – It still functions
as much as you’d like… it’s just doing more than it was supposed to.
– Correct. So we’re talking about good intentions
for which the software is made. And we’re talking about…
– The unwanted side effect? – Well, unwanted…
the ‘not so good’ intentions. A colleague once said:
‘The use cases and the abuse cases.’ ‘The user stories and
abuser stories.’ That’s obviously very interesting. Are you going to build your software
from the perspective… that everyone uses it
in the way it was intended? Or do you have people
who want to break it? I was just talking about
how you can think of scenarios in advance. You could also think of those scenarios
in terms of security: ‘Someone might try this… and if he does,
then this needs to happen.’ So those are very clear specifications
that you can formulate… and that you can take into account
in advance. And you can automate that
in the same way. – Yes, of course. But I was also digging for: You don’t even need
a run-time application for code analysis. You just go through the code… and see where you deviate from
security standards and have to make changes. But is there also a principle
that says: ‘Over here you are deviating
from the required features… you should make changes.’ – I’m not entirely sure
what you’re after. – Not even bringing an application
to production, so you can do all checks… but that you let a tool run through
the code, that says: ‘This part is lacking
in terms of functionality.’ – As I said before, you have functional elements
that you could break… which you can capture
with specifications. But if you’re talking about wrong data types
or SQL injection, for example… it’s unlikely that you’ll cover that
with those kind of checks. But you want to know about that.
– Of course. – There are tools for that. You are indeed able to
scan your code. It’s called static code analysis. This allows you to scan your code
for certain patterns that you use… and then basically scan
the application’s source code… and it’ll tell you:
‘this or that could be hacked’. Or it might return: ‘Maybe it would be better
if you used parameterized SQL.’ Or: ‘You should use enum
instead of string, over here.’ – It gives you examples
on how to solve it? – Not always that specific… but at least it indicates whether
the underlying principle is vulnerable… and you could make changes to that. – But I don’t think you understand
my question… because you’re going back to security,
which strokes my ego, of course… but I meant to ask: Can you test functionality
by simply going through the code? So not security… but the expected functional behavior
of the application. Are there any tools
to see in the code… where you deviate from
your expectations of the application? – No.
– You really need that run-time application? – Basically what you’re asking is:
what is desired behavior? That’s a human thing… you need intelligence to do that.
– You can’t do without. – That’s the same for security. You can contain a lot of technical issues
with all kinds of different tools… but fallacies in the logic
of an application… you need humans for that. – It’s still a human operation. – That’s a reassuring notion,
don’t you think? Until AI becomes so powerful
that it can discern any human error. – I wonder if that’s going to happen. – Might take a while.
– Would be cool, but I’m doubtful. Yeah, you can check things,
but they’re really technical things. You still have to thoroughly think about
your application’s functionality… which is funny… because actually, security and
functional testing are very similar. – It’s mainly a difference in mindset,
I suppose? – Yes.
– And knowledge. It’s all about knowledge, of course. – Yeah, it’s about: Did I build what the customer wanted
and only that? Not accidentally too much? – Exactly. I just want to get back to
this functional tester… because we’ve just established… that it’s fine to be a functional tester
who is unable to code. But are there any more tests
that need to be done… than the functional testing
we were just talking about? You were talking about unit testing,
for example… that’s pretty early on
in the development process. Where is the functional tester needed,
between that and the final step? Maybe it’s a very naive question. – I read a book the other day
and there was a great chart in it… with all kinds of different test types
which you can perform… and the number of defects
you’ll find with it. It said that unit testing could detect
about 40% of your defects… but high-volume usage testing
up to 60%. – And perhaps not even
the same defects? – And that code reviews
can also reveal a lot of errors. Or that reviewing your design
can reveal a lot of flaws. What I want to say is:
test automation is a tool, a means. And you can use a lot of
different techniques… to ensure the quality of
your software. So to come back to your question:
‘What does a tester have to do manually?’ That depends on which technique
you’ve chosen. So you could choose a technique… with barely any manual tests
before going to production… or a completely manual testing process,
doing everything by hand. Both can be an incredibly
effective way… to check if your software
is working properly. But there is a limitation: Suppose you automate
as much as possible… that leaves you with a blind spot. The way I try to put it is: In test automation,
you define what you know… and your suite checks that your application
at least does what you know. But it doesn’t check
if it might do something else. – No, exactly. – So this search for
what else it does… and the side effects of
the changes you’ve made… that will always be
a manual exercise. – And that sounds pretty
creative to me… because you have no basis for
what you’re going to be looking at. Maybe experience. – Yeah, I always like to do
code reviews myself… and to investigate what happens in the code
and what the side effect might be. That way is becomes
more of a focused operation. But you could say that… –
How do you determine that? The code will be quite extensive… not a Post-It, but a lot of data. So how do you determine
where to check? – That’s a good question. You can look at recent changes
and go through those. But what I’d like to add is
that you’re biased at that moment. You’re only looking within
the scope of the change. Does that mean
you’ve looked closely enough? – Because it might interact with
something that hasn’t changed… resulting in unwanted
effects elsewhere. – Yeah, you don’t know that. You’re looking for
what you don’t know… so by looking at what you know,
you’re probably missing something. – Yeah, I get that. Hey, you’ve been doing this
for a while, right? You’ve been around for a while. I’d like to ask you for a statement. If you’d have to give
a piece of advice… to companies dealing with
this matter? – What is ‘this matter’? – How are you going to test? What role does
my functional tester play? Should I send him to
coding class or not? Testers themselves, wondering
what their place is in DevOps… because it’s all new,
automated and high-paced. What kind of advice would you give
to people in such an environment? About testing, about how to
position yourself as a tester… know what I mean? – Yes.
– A fairly broad question… but as a good conclusion
to this conversation. – What I have learned… and what strikes me the most is: Don’t underestimate
the role of the tester. – Okay, and who are you
telling that to? – I’ll tell that to the development team
and the managers. – So you’re basically saying that
you can see it’s being underrated. – Yeah.
– And what’s the consequence of that? – As a result, the tester
eventually leaves the team… everything becomes automated
and then the application slowly decays. Then it’ll take a couple of months… and annoying little things
will start to appear. – That you will encounter
in production? – Yes, in production. ‘How did it get there?’ Then you have to start
communicating… and then you have to regain the other half
of what that tester was doing… as a competence in your team. – And the other way around,
what’s your advice for testers? What would you tell those
who find themselves in this situation? – Basically the same thing:
Don’t underestimate your added value. – Yeah, that’s obvious. But what are you going to do? What do you advise them to pick up? – BDD.
– BDD? – Behavior-driven development.
– You’ll have to explain that. – Behavior-driven development is
what we were talking about earlier. Pre-define specifications… define the behaviors
of an application. And that you’re doing so before
you start building, instead of afterwards. I think if you study that carefully… and how you can use that
in continuous delivery… so those two subjects:
BDD and Continuous Delivery… and Continuous Integration. Well, the list is getting
bigger and bigger. – Yeah, you should teach about this. – If you study those topics,
so continuous integration… continuous delivery and
behavior-driven development. If you study those topics… excellent. – Awesome.
– Did that answer the question you had? – What question? – Next to the coffee machines… you were telling about your experience
in software development in 2007… and asked what that looks like now. – I was also asking that because
my wife is a functional tester… she also has the same background
and ended up in test automation… and has also started working on
test automation. I think she picked that up pretty well,
but it’s not what she likes to do. But she’s a little forced
into that role… because that’s the way it goes. – You see that often. – I think it’s a pity… because her ability to thoroughly
think about testing is really tremendous. But the spark is taken away… by forcing her to take on
that automation job. – I think that’s exactly
the advice I was giving: Don’t underestimate
the value of testing. – Exactly. And when I hear these stories… about the things she discovers,
and that if there’s a problem… that she’s the one who finds out
what’s going wrong and helps fixing it. Her analytic skills are really strong
and that’s beautiful. But it’s a shame that it’s
fading into the background… because you’re being forced
to operate in some way… that you simply don’t dig. – At the expense of quality. – Yes, that’s for sure. Then I recall what it was like
when I started in 2007… and I never really
enjoyed it back then. I can be frank about that. I saw the use,
but I never enjoyed it. That’s why I was happy to be able to unleash
my security talents in a new environment. – As developers, we tend to underestimate
the value of writing tests yourself. – Who should write them? – The developer. Because writing test automation… can provide very valuable feedback
about your software architecture itself. It shows you how maintainable
your code is… and how to make it even more
efficient and expandable. So I’d like to argue that if you test
your own software as a developer… it’ll make you a better
software developer. So writing the tests. – I can imagine that.
– Simply the technical plumbing. – Because you don’t just have to think about
whether it does what it’s supposed to do… but also how you’re going to
make sure it will. – It not only checks
the functional aspect… it also checks the way
you structured the code. It checks the construction. And that just makes you
a more senior developer. So it’s really a shame if you do not. – Does that happen a lot? That developers write
the tests themselves? – Yes and no,
it really depends on the organization. – If I want to bring this subject up
in conversations, what’s it called? – Well… First you saw test-driven development… and then you saw
behavior-driven development. Now you see that
domain-driven design is emerging. So there’s all kinds of
different approaches to it… let me put it that way. – But actually it’s just:
Go test your own code. – No, all concepts are different. – But if I want to discuss this
with developers… what do I tell them? As in: ‘This would benefit you.’ But how do I explain it or call it? – What do you call it? Personally, I find it important to look at
behavior-driven development. And how to call it, well… I think it’s more important to know
what you want to achieve. I think we’re talking about wanting to
move to production more often… and being able to deliver
what your client wants, in time. And that you can ensure
the quality you promised. That’s what you call it. – Fair enough, that’s a good pitch. – So how you do it… all roads lead to Rome. But I think test automation
can be very helpful. – Yeah, cool. I learned something, dude.
– Nice! – Thanks.
– You’re welcome, thank you. – And thanks to our viewers.

Leave a Reply

Your email address will not be published. Required fields are marked *