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,