Thank you for listening and supporting the tekhelet journal
podcast. It is my ultimate pleasure to
serve you in the past two years. I hope the podcast serves you
well and gives a lot of insights that you can apply in your work
and Life as we are going to celebrate the 100th episode
soon, I would appreciate if you can drop a few words in our
survey related to your experience with the podcast.
And if you record your story or message in an audio format, we
may feature you in the podcast special episode.
The survey is I opened for both listeners and guess I'm looking
forward to hearing your message. Soon, drop me the message on
technology. No WF. / celebrate Dash 100.
Here's the link one more time. Technology?
Know, the baths. Let's celebrate bash. 100-mile
definition of acceptance. Test is any test the system must
pass in order to be accepted that can be provided by the
customer the users. The testers or anybody else and
if you can't ship the system without these tests.
Well, they are deep septons test.
Hey everyone. My name is Henry Surya with
Robin. And you're listening to the
technology, you know, podcast the show where I'll be bringing
you the greatest technical leaders practitioners and
thought leaders in the industry to discuss about their Journey
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our Journal.
Hello my friend. Welcome back to the tekhelet
journal podcast, the show where you can learn about technical
leadership and Excellence from my conversations with great
thought, leaders in the tech industry and this is the episode
number 99. I can't believe that we are just
one episode away from episode 100.
If this is your first time listening to package, you know,
make sure to subscribe and follow the show on your podcast
app and social media. And for those of you you who
want to contribute to the creation of this podcast,
support me by subscribing as a patron at technology.
No, dot f / Patron. My guest for today's episode is
Kenneth pube, also known as Camp, you can is in a claim
author and thought leader in acceptance test-driven
development or a TD and behavior driven development.
Or bdd in this episode can explain in depth, the concept of
acceptance test and a TD. He first describe what an
acceptance test. Is why it is beneficial to
deliver better software and why we should invest our effort to
automate. It can also touch on a few other
important Concepts such as the testing Triad test, pyramid user
acceptance test and table-driven specifications towards the N can
share some advice on how we can start implementing a TD.
I really enjoyed my conversation with Ken deepening.
My understanding of acceptance test the insights.
Can share regarding where acceptance test results in the
tests pyramid, and his view about user acceptance, testing.
If you also find this episode useful, I would appreciate if
you share it with your friends and colleagues who you think can
also benefit from listening to this episode, it is my ultimate
mission to spread this podcast to more people.
And I need your help to support me towards fulfilling my
mission. Before we continue to the
conversation, let's hear some words from our sponsor
definitely is Top International software development conference,
with an emphasis on coding architecture and take leadership
skills. The lineup for this year is
truly stellar and features many Legends in software development
names, such as Robert Uncle Bob. Martin can back Scott Hanselman
Franca subramanium, Carolyn honey, Alan.
Hello, Mary poppendieck and many other prominent names including
some of those who have also appeared in this podcast before
the conference takes place online.
So, you can enjoy it from the comfort of your couch.
We spoke to the definitey organizers, and I'm happy to
share that technology. You know, has got the 10%
discount code for you. Enter the promo code, awsm
underscore tlj. When you purchase the ticket on
definite e.com, here's the promo code.
One more time awsm underscore, tlj.
Depending on the time when you purchase a ticket early price is
still available. See you there.
Today's episode is proudly sponsored by skills matter.
The global community and events platform.
With more than 100,000 software professionals here members.
Can organize their learning experiences around the
technology topics. They care about most you get
on-demand access to their latest content thought, leadership
insights, as well, as the exciting schedule of tech events
running across all time zones. So whether devops our data
science is your bus or you are fan of General programming or
all things Cloud, you can make real connections with people who
share your interests head on over to skills method or Cam to
become part of the tech community that matters most to
you. It's free to join and you will
find it easy to keep up with the latest tech Trends, welcome
everyone to the new episode of the technology know.
Today I have with me, a guest named Kenneth puke or Camp you
in short. He is a very experienced,
thought leaders out there. So Has written a number of books
and specialized in acceptance, test-driven development and
behavior driven development. So as you can guess, we will be
talking a lot about a TD + VD. Today can read some books, one
of it, won the 2006 job Award winner, which is the pre
factoring book followed by his latest book called lean, Asia
acceptance, test-driven development and he's also a
co-creator of safe, Agile, software, engineering course.
So can really looking forward to have this conversation with you.
I'm going to learn a lot about 80 DB Really, I guess I'm going
to be here and chat with you. So can in the beginning, I
always love to start my conversation to understand about
your background. Maybe if you can share your
career Journey, any highlights or turning points in your
career. So, I graduated with an
electrical engineering degree. They actually not have computer
science much in those days, we need to digital logic
engineering and it turns out after about five years, the
until 8:00. Eight came out, not the 8080
with the 8008 and I suddenly realized that the future was not
a digital logic, but in software so I actually made a switch at
that time. I went into software, I did some
programming on radar systems on Long Baseline interferometry and
other stuff was out in the Marshall Islands for a while.
And when I came back, I started my own consulting firm and get
her. Custom programming.
Of course, those were with the PCS we're just coming out so
your programming was on a PC, no network, no nothing.
So it had to fit it, 64 K of memory, all the programs.
So then I was doing custom programming got need to training
in the C language. And then from there I've been
doing training, roots of books, read a couple of books on C and
then progress to more Consulting, agile came out
around. I was doing some of the tenants
that were actually in XP programming already.
I was writing tests for all my code in C code.
There was no see unit, but it was tested writing the test for
the code first. And then when you do Agile
Consulting as well, training, join with net objectives.
For a few years who's doing design patterns.
Test-driven development about 12 15 years ago.
Was when I started creating the course on a TDE Bdd, and then
eventually that turned into the book.
Thanks for sharing your story looking back.
I think it's a very long journey, right?
If you can share, what made you decide that software?
Is the future? What things that make you
believe that actually software is the future?
Well, many years ago, I actually, it spent over a couple
of months designing their digital logic circuit and then
when the 8008 came out, I realized that I could have done
the same thing. Just Firmware without trying to
hook up all the digital, logic, gates and everything and I said,
guess what? It's going to be software.
Now, there's talk. Where was it big in those days
in college had programmed, an IBM 360.
So I was familiar with Assembly Language and COBOL and
everything and I realized that the digital logic was being
taken over. You can write it for homework
program, it do the same thing. Instead of look for asleep,
drawing. Block diagram.
I see. So in the last few years I think
you specialize in a TD acceptance test-driven
development and bdd, right? Although in your early years,
definitely you started from programming practitioners of X
be a gel and all that but let's focus today, may be
predominantly on acceptance test.
So you wrote this book, lean agile, acceptance, test-driven
development, that the software true collaboration.
But first of all I think let's clarify the definition.
So what is acceptance test because I hear Here.
This term being used multiple times, sometimes means
differently to different people. So maybe if we can start from
there, that will be great. Okay, so my definition of
acceptance test is any test that is system must pass in order to
be accepted that can be provided by the customer, the users, the
testers because the tester still play a big role or anybody else,
and if you can't ship Without these tests.
Well, they are deep septons test.
Well it's very concise actually I was struck by your definition
of the tests that actually makes the system accepted and a lot of
people these days especially maybe in the startups we have
tests but we just deployed anyway what does it take for
people to realize that? Okay, you really need to have
these kind of tests before you can actually accept the system.
You've got a couple things here first.
If you know what you want the system to do as opposed to your
just experimenting. And it's hard agreed acceptance
test. If you're experimenting with a
system, it's like, you just want to try something out,
prototyping it. So we're not going to be ready
to acceptance test for those sorts of things because they
take draw all the time. But once you've decided in your
experiment that this is what you want the system.
To do, that writing the acceptance test.
Absolutely clarifies. The requirements.
You don't get into this issue of well.
Should it work for? 1000 or 900, you have a test for
it either. Test says line under the test
says, a thousand white documenting that test and it's
actually didn't become editor, be executable specification, if
you will means that. Now our description is the test
as opposed to a set of requirements that well, that's
nice. But what does it mean?
Are we sure that we're meeting the requirements in that
misinterpretation of the requirements is Probably the
biggest thing that goes back and hits people, it's like to get to
the end and the testers find the defect and the developers that I
know they requirement said this and that that's who said no, the
requirement says that. Why don't you guys agree at a
time with the requirements set? I think that's a very important
key point, right? Because you mentioned
requirements, sometimes is misunderstood.
Sometimes it's vague as well, and sometimes it's just one
line. Okay, built me.
This you bring a point in your book that you Mentioned that a
testable requirements should have acceptance tests associated
with them. So, I think this is also a key
discipline. When you define requirements,
you always have to Define it in such a way, that it is testable.
If you can, elaborate a little bit more on this point.
Okay. So there's a concept of a
testable requirement. How do you know the requirement
is testable by writing a test for it.
If you cannot write a test for requirement, then the
requirement is untestable. If an earthworm, it is
untestable. How do you know the system is
doing it? Why are you asking for the
requirement? If there's no way we can tell
this system is actually performing that behavior.
Yeah, that is actually true if you define a requirement in one
liner but then leave other people to test.
If at the end you think the software is not acceptable?
I mean, at the end, it's your fault as well.
So you don't actually specify the requirement that can be
tested in a way. There's a point where you
mentioned that acceptance test, if done properly, then be an
authoritative and reliable source of what the software
should do functionally. So, I think, especially we
mentioned by executable specifications.
If everything even is defined by using test, I think that's a
good way of getting the reliable source of truth.
About all the requirements that the software does.
So, we know about the definition, I think some people
also know about the benefits but can you, elaborate, what are the
benefits of acceptance test? Okay, so the main benefit, it's
always based on your content if I go into some place and I asked
them. So how many times the something
come back from the testing environment or for reduction
back to development with a defect?
And if the answer is point zero one percent, I'm gonna go.
Well there's not much I can do for you.
I mean we can spend some time but you're pretty good.
If the answer is 1%, I'm going well.
How much time does it take you to solve the defect if it's
starting to creep anymore than that?
There are places. That are why call them a
loopback? A loopback is when you send
something out and it gets sent back with a defect that you
should have thought about before as opposed to feedback, which is
you send something out and you learn something new to help
improve the product. If you can cut your look back
rate, down traumatically, they you can flow that business value
through your developmental value stream, much quicker and get
things out. So that you're actually always
working on new stuff as opposed to fixing defects and if I guess
the way I don't usually sell it to developers or no.
Hey guess what you're getting your requirements and a testable
for Your job is to write an implementation that passes those
texts. Now you'll still maybe have some
communication and collaboration because maybe the tests aren't
quite clear and so forth, but once you pass the test, you're
done, if we are able to describe as much as possible requirements
and test that would have normally been done in a post
implementation phase, that means that you won't have any defects
to fix Do you like fixing defects?
You spend your life, just going. Oh man, I just want another
defect. I can fix today.
So that's how I sell it to a development team.
Well, some people with wrong incentives might like fixing
defects because some people are incentivized by number of
defects found. But I mean, joke aside, I think
I get your point that if we can reduce the number of loopback
all rework or something that Goes back from your value
stream, right, from the last, back to the beginning.
Again, I think that can cut down a lot of inefficiency.
And you mentioned, I think that, if the product team or the
developers and testers actually write acceptance test prior to
the implementation that actually can double the productivity.
I think, some teams I observe as well after the requirements,
maybe it's a little bit big and then they will have a face
within the same sprint. Testers, write the test cases.
So, there are small. What do you think about this
practice? How can we change?
Okay, so it is a change because in many instances, it's like
developers just want to take their coat and throw it over the
wall to the test, even if they're on the same team, I'm
going to call it. It's a mini wall.
I've seen too many instances where all right, the developers
get a story done and they get it done at 4:45 on the last day of
the Sprint. The testers in have 15 minutes
to test it or they have to work the weekend and everybody's
after them because the story isn't done until it's tested.
And then, of course, what happens is this breaks into
Behavior go. Well, let's create a testing
store and for the next Sprint store, at least through say,
we're done with our development. This brand of the testing, your
next break. We, of course, obviously is
really opposed to the idea of Agile development.
And so the point is that if we and the testers and it takes
just a couple of days to switch this thing around, you've got to
be able to pull something off the backlog spin an hour, two
hours, and if it takes any more than that, do you have
complicated story but spend it our two hours creating all these
acceptance tests. And then start to implement it.
Now, developers run the acceptance test while they're
implementing or once they're finished depending on how much
of the application they need. And then the testers job at the
end is okay, let me run it through on my environment, if
necessary, or I'm going to spend my 15 minutes doing some
exploratory test to see if there is some unintended behavior that
We have not described by all the acceptance tests.
What this does is it puts an entirely different spin on
things. The number of defects that are
tester, has to report for purely the functional part.
I mean, the things that when you look at the requirements, it's
like okay this is the way it should work.
And yeah, we've got a higher limit here.
If it goes above that limit, we should get a message, it's put
up and it's like, oh well, that's an edge case.
That's what testers do. Don't let's write the test.
The education and developers can make sure that it works that
way. If the application is folks to
have a behavior for both good and bad input.
We can write all those tests for and then the testers can be
spending their job looking for all the unintended things.
What happens if we do instead of doing it ABC?
Like we thought we'd do a CB in our workflow does something
break, it puts an entirely different And to just give an
example, one of my things that I asked one team for months later
to give me a report how well it works.
And they said that t, that lead developer and Lead tester are
much more mellow because they're doing testing throughout the
Sprint, it isn't crammed in the last day and it creates the
we're the team feeling it. Isn't US versus The testers,
it's everybody's in it. They just found that their
defects would dramatically down. Yeah do things slip through,
it's going to happen. But with the number defects is
like you can use your fingers on one hand account them.
You don't need to have a gyro board to take care of these.
It's like okay, let's go fix them or will decide that well.
Okay, nobody's ever going to do that one.
So let's know. Worry about that.
That's a case that shown it show up in normal stuff.
Thanks for sharing this story and the impact that people have
done by following your advice. I like what you said that the
testing actually happened throughout the spring.
Not at the last one week of few days before the Sprint and
everyone is cramming and waiting.
When can we deploy this feature? So you mentioned that in the
beginning, the team should come up with these tests been 12
hours. You mentioned that the people
that should be involved in creating test, which is called
the Triad, some people call it. A Amigos.
Can you elaborate, what is this concept that Triad?
How should people implement this?
So I call it the Triad because that represents three
perspectives. Not necessarily three people,
The Three Amigos tends to be three people and everybody wants
to be Steve Martin so you didn't dollars.
I'm Steve though you're Steve so I call it the Triad and three
perspectives. The customer who is providing
the requirements, the developer who's implementing the
requirements and the tester who is critically, analyzing both
the requirements and the implementation, so they get
together. Now I give three perspectives,
the customers perspective, it could be the product owner, it
could be a business, analyst it could be a subject matter
expert. It could be all three of them
could be. Getting that perspective for
particular story. So that's why it's not just
three people. It's the three perspectives,
they meet with the developer with the tester and explain what
the story is, they work together to create.
And bde terms, we call it a scenario, just a given when them
scenario of what the state is, what the action, or event that
occurs and then what should be the output or the new state?
And they work on these while they're doing it.
They're defining domain terms. They're defining ranges out of
range stuff and they're defining to other things, which is what I
add to the normal, given wind in, which our business rules,
the business rules, which for some systems, take up 80% of the
code, or at least 80% of the work.
For example, for an ATM, everybody has the And given I
had some money in my bank when I go to my ATM and withdraw $20,
they'll I should have $20 in my hand and my cheek pouch, $20,
less. Well, it turns out that's nice
and that's a simple thing, but they're actually about in the
banking industry about 150 business rules on whether you
can withdraw that money out. How many times have you thrown
that money map, hello, much money and be withdrawn, sold for
that. Install one and I will not
elaborate them all here and it's really that simple flow.
That's easy to automate. But it's adding in those hundred
and fifty business rules. That need to be clarified
precisely if you're banking, if you're an investment firm,
you're letting your customers buy and sell stocks.
You better have your business rules right?
Or you're in trouble with these Securities and Exchange
Commission. So in addition, Should it gets
the normal given wind, then of what I call a flow scenario, I
emphasize business rules here. It's some inputs of my business
rule. What's the output here is?
How much money? How many times I've withdrawn
over how many days and so forth. Given all these inputs, then I
get my money out. Yes, or no?
And bones become very elaborate. I have seat business rules that
have over a thousand different Recombinations.
Each one is unique, and has to be done.
There has to be an answer for. It isn't like an algorithmic
sort of thing and then, the third thing is our domain terms.
This is a key where a TD meets DDD domain driven development,
because during this collaboration, we're going to
come up with those domain, terms 0, balance currency, so forth.
And so on, it's critical that you get your domain.
Arms wrecked all for example balance.
Yeah that's what you're all seeing that little ATM sort of
examples, but is it your current balance or Does it include
potential withdrawals that are going to be posted in the next
two hours and so forth and so on and we need absolutely clarify
these things to make sure it's right.
There, are some cases, where do you take Facebook or something
like that? Doesn't matter whether Either
you get this sent out to 5,000 people or forty.
Eight hundred people. Now, that's an instance of yeah,
you can write except it says for it, but you don't have to be
quite as picky. You.
And if you a lot of my Consulting is with Financial
Insurance investment, firms, and medical for where the business
rules are critical. Thanks for emphasizing all these
key points. So maybe if I can summarize, you
mentioned that Test should have the flow.
Of course, the scenario given, when then kind of thing you have
the domain terms. So I think in DDD, we call it
the weakest language, where you used the terms, that business
people use, and as much as possible, maybe you should be
able to see it throughout your code.
Try your test cases and all that and business rules.
I think you emphasize very clearly, depending on the domain
and the industry, of course, there will be some industry that
has a complex business rules. Maybe elaborate business rules,
as well, you mentioned Financial technology Healthcare And all
that. But many people don't work in
this industry. So they think writing a TD or
except themselves in the beginning is expensive or maybe
they don't even understand all the business rules that are
available, and they'll just leave it to the team to decide.
So what is your counter-argument to this a TDS expensive to
implement? Well, I look at it as we got the
user. We got a customer if the
customer cares about the details of how something works.
Then we are to create these accepted status.
If all they said it was all. I just want you to withdraw
money out of an ATM, will let the team decide how to do it.
You can write acceptance this. Well, I have an article on this
about the accepted says, very in the domain just as you're
saying. For example, if it's a video
that we're doing, suppose you have a video website and we want
to write an acceptance test for video.
Well, there's not much, we can accept, we can say, we don't
want it to pause. We wanted to start pretty
quickly and I want to be able to forward and backward on it or
something like that. That's a very high-level
behavioral thing. The developers have a lot of
work to do to implement that and our acceptance tests really are
just the external behavior and there's a lot of internal
Behavior whose result is reflected in the external.
Either but which can't be specified other than in those
gross terms. So it's perfectly fine, if
you're in a situation like that you can express fi she just a
gross external behavior and leave it to the developers to
write an application about that, but it's still good to have the
acceptances could see it. You sort of have an idea of your
gun. So I think that's a very
critical point know when you are done.
Because if you don't have these tests or specification, you
probably don't know when you're done sir.
I think that's really important. You mentioned that actually, it
doesn't cost a lot more, even if you write it in the beginning,
this is writing it at the end, so it literally takes the same
effort, probably, but the impact, right?
So you can imagine the number of defects number of rework.
Number of Miss clarifications, that needs to happen between
developers and their customers or business owners or product
owners. So thanks for emphasizing that.
Maybe we can go into one level technical.
Now, there are so many different types of tests in this.
Technology will be States. We have unit tests components as
acceptance test itself API test. So where does acceptance tests
actually get categorized? Is it the same all over the
place? Or is it different?
Maybe need your clarification here?
Oh, that's an excellent question.
Okay, we have all these tests in fact oh man, unit test
integration test and an tests and so forth and so on, what's a
unit test versus integration tests?
Like oh is it a single man? That well, I go along with
Google Google came up with the concept.
If you have a test here and at the bottom of the test pyramid
are small text and in the middle are medium tests and at the tone
bar large decks. So what you want to do is have a
lot of small tests, less medium disk.
That is very few on the end-to-end tests.
Now we don't get into an argument of whether it's an
integration tests or unit tests because is it a small test,
there's Run pretty fast. Regardless of whether it
includes 32, classes are not if it's fast, it's small and so
therefore we're not looking at trying to make these
discriminatory things of. So it's an integration because
we include two classes or dissing that on this level, the
three types of things that I've indicated, the flow, the
business rules in the domain terms, Well, in reality, the
business rules in their main turrets actually are small test.
They go against either single class or maybe even a single
method in the case of a business rule, although they evolved more
things. So they're pretty fast.
So we can't put them at the top there at the bottom with the
fast test and now this load test, some of them are eating
because we're only going to test the flow of something like
request. Years and it receives $20 and we
get back an indication that we're going to get $20.
That's a small little piece of the entire flow because we need
to log onto her ATM, then get the money out and so forth.
So we can have some of these ATD given with men's being medium
and then some of them are going to be the large.
Because I do want to run through the entire scenario, low
sticking my card in putting my pin in looking at the silly.
Vert Iseman. They decided to put on the ATM
and say, no. I really want to just get my
money and then entering my money, receiving money, money my
card it's a long test, what you got to do it but giving want one
of those so it's an intent test. Well okay so with that levels to
System test because it's testing the entire system meow.
So a TD balls on that level also falls in the unit level could
fall in the integration level. If you're A small little given
wind that. So where does it fall
everywhere? Now, you've mentioned ATI,
you're going to come up with an acceptance test for your API and
you're going to come up with test for the individual methods
or the individual calls, and then you'll probably have a few
tests that involve multiple calls that you want to say.
Okay, I call this, then I call Dan McCall that did everything
work out, right. Well, sir, acceptance tests
typically for an API, you don't be a customer.
However, it's a public API. You've got customers.
Are you talking to them? Are you finding out what they
want? Are you finding out how they
want their errors or anything to be returned how you want, error
handling, and so forth. So it works on a smaller level,
somebody's the customer for an API.
Somebody is Developer of it. And you might have a test their
come through once again, they could go, okay?
So what happens if I call this? But oh, this isn't working.
Well, this at least return me the right.
So you've got a smaller thing and it's an internal acceptance
test for API. It's not an external giving
somebody money out of the ATM. Thank you for clarifying this
using test pyramid. So if you can classify your test
into like small medium and large probably You can easily deduce.
Which test should it be? And you mentioned about
acceptance, tests should be everywhere.
Maybe one, kind of a confusion. May be also personally myself,
right? Sometimes we treat acceptance
tests as something to be reported, so think of it like a
user acceptance test, right before you can deploy your
product or your feature, you need to have this report.
And if you mention that, these acceptance tests can be anyway,
how do you report it easily? So that maybe is my question,
Okay? So They just part of your
question and then I'll get to the recording user acceptance
test. Okay, that's something you give
the user at the end and they go. Okay.
Is it working or not? How come you didn't talk to that
user ahead of time and say, look, when I give you this
application, what are you going to do?
Can you just tell me the steps you're going to follow?
Okay, well first of all that might change what you actually
implement but secondly why aren't you running that?
Why are you waiting for the user to read it?
We find those uses. We ask them how they're going to
be using this system. They're the ones who should be
helping create the test in the beginning.
I will make my exception so usability test, okay?
Because until they finally see what the gooey looks like, and
they're actually using it, while you can do some prototyping.
But in reality, they've got to have a Hands-On.
Now, this is too many clicks. You can only do so much with
prototyping and so there still is that usability, but the
functionality is, should already have taken.
Now as far as report goes, what are we reporting?
And why are we report? If I have accepted status for
every requirement and every requirement is required then, am
I only report is everything past And I should have know, we got a
couple of failures here. Well why don't?
We need to report we have failures fix them.
So your only decision is everything works or these few
things don't work and we're going to fix them which is a
no-brainer or these things that work.
And we're going to put a feature flag or something so people
don't see them. So we can ship the system or
these things don't work and we just decided we're just going to
take these out so let we can remove the test because we
remove the requirement. And we've gotten rid of the
failure by removing the required, so those are
decisions. But basically the entire
application should work as is so it's 100% except it's this.
So I think, yeah, go back to the CI CD pipelines.
Do you have the number of tests that you have there?
So if anything breaks, then even though it's unit integration,
whatever you want to call it, classify it, if something
breaks, Daniel you have is that the software networking place on
the specification, one area, of course about Ten steps people,
sometimes, heavily associated with the automation, part of it
writing automated acceptance test.
So many people call it bdd so maybe we can go there about the
automation part of the acceptance test or this given,
when then kind of thing that you must have seen in the industry.
This taser. So, how can people take
acceptance tests? May be defined by the Triad and
then automate that. So, if the old days and I'm
talking about early, Guinea the Millennium.
There was a acceptance test framework called fit framework
for integrated testing, and it worked pretty well.
It was tabled based system. It was perfect for doing
business rules and things like that.
And it had automation that it's now sort of turned into fitness
which is fit with a Wiki for I'll call it the modern day.
You've got the variations of cucumber.
There are other automation Frameworks but I'll call it the
girl. And the Kirk and style is the
one that I tend to use. It's simple to write.
If you're consistent, it's civil to automate and just a little
discipline, and how you write this stuff.
So, if I have a given wind then, and most of my given wind ends
have some data associated with them.
I've got a bank account, has a balance.
I'm taking so much money out. I'm taking $10 out, and
therefore, my balance was 20 now, my balance should be 10, so
forth. You can then automate those, you
can turn them into automation Ian, approximately 30 seconds to
a minute so we can convert that given win then into code and
whatever language you like Java C sharp, which uses their
version is called Speck floating set of cucumber or Ruby Pearl
python you did. So now you've got the template
that gets the data. The gherkin and now, you can
provide some production code if you want multiple asserts into
this statement, but then you gyrate some production code.
Here's my data. Here's what I'm expecting from
Ryan. Put guys.
Let's start coding because we got some work to do.
So the automation part is Trivial, in fact, both in
cucumber. And spec floats.
Basically you have a feature file that has the gherkin it,
you Push a button and it will actually create a skeleton code
for you. He even has hit your
implementation here, put your call to your implementation
here, some for it. So, it's pretty nifty.
And as I say, very little overhead, you mention something
that also piques my interest. So, you mentioned above table
driven specifications', forces, textual format, kind of a
specification guy. So that maybe three or blog
posts and things like that, that you promote a lot about
table-driven test. Met so tell us more way.
Probably table-driven is more beneficial.
May be more useful than the textual simple format so this
gives it that how much data you're having to deal with in a
standard opening? You might say given my balance
is $10 and I have had three withdrawals, something like
that. That's nice for simple stuff.
It works perfectly fine but But now, when you're starting to get
more complicated, given my account is, and now I want to
have a table of the attributes for that account is the account,
an object, I don't care yet, and we're not dealing with that, but
it's an entity and it's a domain term that everybody would
understand. And the attributes would be
something that product owners and the smees when understand.
So now we have balance in our header.
We have the number of withdrawals in the past week,
And so forth. Each of those data items becomes
a column header and then we give it just the data underneath.
Well, what that does is it draws out the attributes.
Those domain terms for each of those fields better than if you
just sort of string it in a sentence because it's like okay,
the balance is and it's like the term was well-balanced.
I do we just put that as a header.
If we put that as a hammer it's all Already parsed out for you
and every day. So having these step tables, if
you will, the data underneath, each step, in a table, gives you
an easy way to look at the Domain terms and easy way to
look at the values. Each, I always say it's in the
language of business and everybody looks at me and says,
what are you talking about? I said every business person
uses Excel, they're all used to tables.
So having this in a tabular format, it's like yeah, let's
easy to read than this 50 lines of here's some inputs and every
so that's why I emphasize that tables.
It also turns out. There's some other interesting
easy thing, it's very easy to add another column to a table
and it turns out you don't have to pass all the values in the
table. You can default them in a step
definition code itself. So it's both readable and can be
more efficient. Yes, 01 count Acumen that
sometimes I observed by business people looking at the gherkin
although it's in plain simple language natural language
sometimes. Yeah, it gets to maybe granula
in such a way that it's very difficult to grasp.
What this test is all about, just by looking it.
Simply so you mentioned that business, people tends to use
Excel spreadsheet in order to Define their business rules, or
maybe some examples of how this should be done, I think.
Yeah, that's correct. Actually by having tables, you
focus the attention into the headers, which are The
attributes and the domain terms, the important Concepts and their
variations of values that could potentially happen and what your
code should assist in terms of a correctness.
So thanks for emphasizing that. I think your table driven, I've
used it in the past as well for insurance calculation.
That actually is the main language that the Actuarial
people used to actually Define the formula for this
calculation. So can we are reaching towards
the end but before we go into the last question so I want you
to probably give us some advice for people.
People who are building products or building software, what
should they do in order to kick? Start this journey of acceptance
test-driven development. So it's not like acceptance
tests last sir. What should they do to get
started? Well, I would take class and I
want the team to adopt it. What happens, sometimes is what
individual goes off into class and comes back with this great
idea. And it's like, oh yeah.
Okay. That sounds like a lot of work.
And by having a teen, take the class because it's a team that
needs to collaborate together. They need to have a common
understanding of how everything goes.
So that's why I teach my classes to teams, not individuals,
having the T to get together. Do it on their own stories and
realize how much they may have learned from actually creating
these steps and how much the clarification of the
requirements come. Why do we do this first?
And which is of course the developers always biggest
completo the core requirements around clear?
Yeah test this absolutely you know it's yes or no either you
pass it or you don't and so that's how I would start.
I mean you can try it on your own.
I have workshops that I teach for teens.
We basically go through and use your stories as the exercises.
Not might ATM example, we use your stories and you come out of
the workshop. We Sunday your stories that are
fully developed and now you may be able to recognize, here's the
difference between what we were doing and what we could be do,
that is always nice to compare or contrast between what you
were doing before. And after the new knowledge, how
you should do it, it gets started from there and
hopefully, the behaviour and habits stays on.
And you have a much more improved software development,
life cycle. So, can it's been a pleasure
talking to you. Unfortunately, we reach the end
of our conversation, but before I let you go, normally, I would
have one last question that I always ask for all my guests
which is to share about three technical leadership wisdom.
So think of it like advice or maybe some kind of insights that
you have retrieved from your journey so far in your career.
So what would be your tree technical leadership is system
in or okay? Technical leadership.
Hey, trust your people you hire good people.
Let Make the decisions and let them do their job.
That would be number one, number two ecourage consistency so that
people can move from a team to team and have a similar process
or similar environment in which to work.
But don't demand, it encourage it because there will always be
cases and exceptions. To any standard you come up with
so go. Here's what we really encourage
you to do but we're reasonable for exceptions.
And then three, and it's sort of goes along with it.
You've got the best people read. You're making decisions involve
them in the decision, get feedback.
Now, there are always times when it might be, okay, we got to do
this because we got a half an hour and we don't have time, but
if you're making changes, let there be time for the change to.
I'm going to call it be accepted before the changes me.
So you're going to clarify why? We're doing a change, you're
going to ask for, is this the right change?
And what are the pitfalls in the chain?
So instead of going downwards, asked, upwards and Fry and form
a cohesion naturally. Now, there will always be the
tail ends of the gaussian curve and you will never be able to
satisfy everybody, but let's at least move the mean over to it.
Accepting the change that you wish to make rather than just
going. Okay, next week we're going to
be doing this. If I may try to relate it with
acceptance test as well, before you actually make the software
that decision. Make sure that you involve the
people, the try it to actually tip in and give comments and
maybe agree or disagree with all those before you actually down
to implementing it. So can it's been a pleasure.
Thank you so much for sharing everything about acceptance
test. I learned so much today for But
who would like to continue this conversation?
Or maybe get into your class or resources?
Is there a place where they can find you online?
Yeah, you can find me on LinkedIn can Pew.
And I am confused because I was the first Camp you on LinkedIn
or you can go to Kemp you.com Ian, D ug H.com and you've got
all like information there any books that you're going to write
lately? Well actually, I am thinking of
writing two books in there, sir. Art of parallel books.
One is an effective software development which is going to be
a book on doing agile or even on agile.
It going with patterns on how to develop software and picking the
right patterns in your development process.
Some of them if you pick one set of patterns would look somewhat
like scrum and other you might look like safe another by
kanban. So it will be a sort of a
pattern selection book and then there's another one.
I've Sort of like a, just a little basis for it.
And that's basically coalesce view of software development, it
takes in a value stream and acceptance testing and how to
break things into scenarios and become stories and so forth and
so on and it's sort of like a one way.
I always called it one week because there's always three
ways to do anything. The best way is whatever works
in your context. And so this would be a book on,
here's one way to do things. Things of all the possible
combinations. Looking forward to seeing those
books published. And if you have it published, I
guess I can have you back in this podcast.
Okay, sounds good. So, thanks again, Ken, thanks
for your sharing today. You're welcome.
Take care. Thank you for listening to this
episode and for staying, right until the end if you highly
enjoyed it. I would appreciate if you share
it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you are new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It helps me a lot. In order to grow this podcast
better. You can also find the full show
notes of this conversation on the episode page, at Tech Legion
l.f website, including the full transcript, In quotes and links
to the resources mentioned, from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on technology. Not deaf to get notified for any
future episodes. Stay tuned for the next
technology, another episode. And until then goodbye,