BDD (Beer Driven Development) - by John Pourdanis

In this talk, John Orianis introduces the concept of beer-driven development as a way to enhance collaboration and communication among software development teams. With over 15 years of experience in software development and quality assurance, he emphasizes the importance of understanding user behavior through behavior-driven development (BDD) methodologies. He discusses the use of the Gherkin language to bridge the gap between technical and non-technical stakeholders, promoting a shared understanding of project requirements. John highlights the challenges of poor communication and the need for a relaxed atmosphere that fosters trust among team members. He advocates for open discussions over casual settings, like sharing a beer, to build psychological safety within teams, which in turn leads to improved project outcomes and innovation in software development.

Challenge accepted. [music] Challenge accepted. Challenge accepted. P2 [music] is always challenge accepted. And now let's move on to something that fits perfectly between two beer breaks. >> Forget testdriven development or behavdriven development. Our next speaker is here to introduce you to beerdriven development. >> He started his career as a developer then moved into QA which gives him an unique edge. He builds test automation that developers actually

like. >> With over a decade of experience in software development, quality assurance, and beer drinking, Yiannis aka John is coming to our stage. >> Please raise your glass glasses metaphorically for now. And welcome John. [screaming] >> Thank you. [music] Challenge accepted. Challenge [music] accepted. >> Ready. Where is the one? Two. Test. 1 million to million. No. Let's see. We are in. Okay. Hello everyone. I think that

uh it's the uh right after the break from the beer. It's the beard driven development that uh needs to talk about, right? That's the it's not a consequence. We just talk about beer. We are here to enjoy the beer, right? not talk now talk about the development. So uh first of all I want to uh thank you for introduced me. Uh who is talking? I am uh

John Orianis. Uh I'm from Greece. Uh I have about 15 years of experience in software industry. I start my career my career as a developer. I'm corner of of coorganizer of a meetup the Saloniki software testing meetup. where I drove with my wife and my kids uh here to Sophia. Uh and uh I am prof I'm software testing trainer and I professional nothing nowhere. What professional nothing

nowhere means is that uh I think I know many things but actually I don't know nothing. Okay. So, who knows what BDD is, behavior-driven development? Who actually use it? That's a good number. Who actually use it? >> Use it. Used it. Use it. Use it. So, okay. Uh, many of you know, but uh, and it's a methodology as you know, right? It's a methodology that documents, designs

and develops software uh behind of the scen of the behavior of the user, right? We focus of the behavior of the user that interacts with an app. Uh what tries to solve this uh uh methodology is try to solve the try to bridge actually the gap between tech and no tech guys, right? your managers, your salespeople, your whatever uh you have in uh uh your company. And

it's uh improve the communication and the collaboration between stakeholders or business priorities, people with less or more technical expertise, right? And uh what we need to do this communication, we need a language, right? uh this language called Girkin uh given when then uh we will give an example it's a format it's a domain specific language it's DSL called DSL that uh uh the given is uh for

the preconditions and the context uh one describes the action and then uh uh specifies the expected outcome right simple enough and what we get from this uh gerkin language we get uh the the feature files. What's the feature files? It's a natural natural language document, right? That uh it contains the share understanding between tech and not tech people and it is associated with an automated test, right?

So each step of uh the document behind the scenes execute code to uh run the test. Let's see an example. So we have a feature that we want to make the developers happy, right? I don't know if it's so easy to do that but let's say let's say that we have this feature and uh the scenario is to add beer right to a pint the happy path

of course only the happy path uh so the given is an empty pint we have an empty pint uh when we the pint is full of beer then the developer smile and says bra passing test so this is kind of how the feature files look like, right? But what do we have here? We have the collaboration challenge, you know, uh thinking about be before coming up here

to to speak and I I attended to the most talks uh of uh each speaker. It's kind this talk is kind of a conclusion and summary of all talks and uh uh exactly is the the problem I will describe the problem that no AI no tool can solve till now. So the collaboration challenge what a developer can say usually I can fix only what is on requirements.

You have does anyone have hear that? Okay. Uh the other thing I tested already not only the API response the UI is totally broken. Uh it's a net case I have I it uh on my previous on the previous presentation this it's a net case he says it's a net case. Uh but the QA engineer what he says from his perspective uh bugs found on a beer

too abstract right what does that mean we have many bugs to do the deployment what is the severity that was missing from requirements again so we found the bug and we say oh no that was missing from requirements I didn't test it at all right as a QA engineer a QA engineer And the third person is the three the third amigo. If you know the methodology of

agile and BDD all on this kind of stuff you talk about three amigos. The developer, the Q engineer, the product owner, product manager, whatever. So but the customer want beer without alcohol. Do you experience that? So we develop a feature, we test it, but the product owner comes and say on the product review agile sprint review and says but we want something different uh or we found

a bug and the product manager why did we didn't find it earlier. Is is al all all those faces uh and words familiar to you? And the third one, it's super critical. It will just deliver something that has a UI issue. The red button was red and the customer was the button was green and it's coming and say, "Oh, no, no, no. It's super critical. We need

to fix that now." So, let's be real. You know all these kind of quotes that uh uh posted on LinkedIn or whatever uh on Twitter. AQ engineer walks into a bar, what is one beer, order zero beers, order nine nine beers, order a lizard, order whatever he thinks. But the first real customer walks into a bar and asks where the bathroom is because if he drink a

lot of beer, he need to know where the bathroom is. the priority for the customer the real customer is where the uh bathroom is. So and someone would say we do we are in the new industry we do agile we do agile and all of this kind of agile that we do I I catch myself to from the previous ditation are we doing right the agile you

have read the agile manifesto what it says the agile there are people that had a a very specific problem the water for problem Right? And they try to solve this problem. So they write a manifesto and the manifesto comes and uh now what are the pitfalls? We have meetings that we have be mail too many meetings, right? We actually do not translate the business need into useful

software. Right? Useful. This is very important with I I go back to uh the previous presentation that talk about to know the actual customer right your software maybe you are a Q engineer that tested it and are we um are we the customers no we are not we are not the guys on on Ethiopia that using the the healthcare software so to translate the business needing usual

software is a challenge and that we won't do it. my my child is here. So we she likes the the telephone game effect. You know I told you something and you need I told you something secretly and uh you need to tell it to the other guy and to tell to the other guy and at the end we get something uh wrong information at all total transformative

information. Most of us we don't include the customer to the stakeholders. Who is the question and uh uh if someone's reply truthfully you will get the t-shirt. So who actually get the customer to spread the review uh of the of your products? Who? Anyone? No one. Okay. No one t-shirts. Great. So and uh as you as you know to get the customer the actual customer not a

not an internal person not someone that is from our company or we give it some call going to beta testers or something like that the actual customer. This is what agile manifesto says. And of course, the most common mini waterfalls are not agile sprints, right? The mini waterfalls means that the uh the testing starts when the be the development ends. No, that's not agile. If you are

doing you're doing something wrong. And but someone say the other guy say but we have automation. We have uh 1,000 tests run seven hours building nightly builds and all of this kind of stuff abstractions and uh they are they are all with the solid principles and all of this kind of stuff huge things right I don't I will not uh say the the reasons that this not

work I just uh select three quotes from uh one is famous the other two I don't know them but they uh good what on of what we they said he who thinks a tool can solve all problems has a new problem and the second one is automation not automagic is uh something that we need to focus and the third one from a famous guy automation applied to

inefficient operation we magnify the inefficiency Right. And the other guy say we are of course you know all of all of all presentation talk about it the AI the AI AI AI I [laughter] all all all of what I hear. So uh a really interesting research about AI uh says about the positive gains and the concerns right we have positive gains on code quality code quality right

the test confidence and the code reviews AI do a great job there but the two concerns is hallucination you know same prompt different response and context issues context issues. Why we have context issues? Because we don't comm we have the collaboration challenge. If we have clear context to the AI, he will give us the best response that he could give. It's simple enough. So what's the solution?

we need to introduce some beer. It's my suggestion. Right? First of all, I need to clarify because there are people that own companies here are not promoting your space alcohol use at all. Right? Uh I promote the casual and relaxed atmosphere. I promote the what what happens there is that naturally where people gather over drinks or food. You know, they have done it before the IT industry.

We are in the IT industry. this to uh move to a table and talk about their problems and how they can solve it or uh chitchat and feel confident they have done it before the IT industry and of course the honest communication there happens so what I I suggest to do something that fit with your team it's not a we don't have silver bullets on that so

in Formal communications in generally builds trust. You need to have trust with your colleagues, right? If you don't trust your colleagues, you don't trust the developers. You don't trust as a QA engineers because I speaking on a QA conference as a engineers, we don't trust the developers, right? Don't say it. We don't you test it. No, you you don't test at all. But we need to do

we don't build trust with them. Trust means better communication. All are feel safe to talk. This is important. This is important to be safe to talk is important even for the things that make you uncomfortable feel uncomfortable. Uh no I don't even tested thought it was an area that uh uh I didn't focus never was priority something like honest to be honest right you need to drop

the your professional performance per personas this is my suggestion and people ask dumb questions there's no dumb question all all of these things that you think that is dump there's not dumb you need something misunderstanding on your head and you need to clarify it and it's okay to ask that questions and what you will do with uh uh this to gain the requirements clarity. So you gather

uh on a table, you open the beers, you talk about and of course you will talk about work, right? You are with your colleagues and you try to focus on what you talk. You talk about this feature, right? And say you need to focus on why behind of what, right? All the people on the formal documents or formal processes try to solve what this problem why this

problem we need to solve we need to understand it it's a share understanding discover the details of the formal meetings miss right as I said formal meetings we have the agenda we have all of this kind of stuff but there are things that are missing destroy the assumption of each member to the previous site I saw that developers has different perspective, QA has different perspective, product manager

has different perspective. We need to destroy them. We need to get from this room, this bar, this whatever it it is with all with the same uh to be on the same page and there the aha moments happen naturally. So many big tech companions like Google do a research for that right they don't [laughter] they don't leave anything to not have a research for that and the

research that say that psychological safety was the number one factor of team success right the numbers are impressive 21 31% more innovation 76% more engagement 27 introduction of internover 50% more productivity overall and 74% less stress among team member this is from the project Aristotle you know the Greek philosopher Aristotle right uh and also one of the most famous uh university in the world MIT do some

research on that from the other side what's happen if you don't have If you have don't have psychological safety on your workspace environment, toxic cultural is 10x more predictive of turnover than sal than than salary. Who agrees with that? If your workplace is toxic, even if you give me I don't want to say too much, I would say 2,000 euro. I speak in euro uh and it's

toxic, I I will sign off. No, it's not. You you spend your time there, right? You you you spend one 33 33% of your life, I guess, on your work, [laughter] right? So, if it's toxic, no. Say no. Coffee break study shows 25% of productivity. The number is huge. 8.8 trillion lost in productivity due and to an employee dis disengagement. The number is huge, right? This is

for the companies need to hear if someone is a company owner. And of course uh the fourth one is uh it's too it's too dangerous. 20 82% of employees at risk for burnout. Burnout is serious situation that we need to avoid. And of course if you have organizational politics increase the resignation intent by 200%. If we have politics, we are not politicians. We are engineers. Right? So

what is bearddriven development about creative safe pennies and honest honest conversation? This is about you argue with the colleagues. You you spend eight hours a day at least with your colleagues. So create a safe environment that you can uh talk see the person behind the role. We are all persons. We are all humans. Even your managers your whatever words CTO's they are humans also right. Try to

live with a shared understanding. This is the ultimate recite of high quality software. From my experience, all the teams were have about how many sponsors do we have? Uh, Peter 20 20 eight sponsors we have here to to try to hire someone that can collaborate Not we are problem solvers, right? They just they don't hire you because your hard skills you know best automation frameworks latest playright

uh cypress whatever you have uh 15 years of experience if you cannot collaborate with their colleague you are the problem that's the thing and so what happen next if this happens we have the hangover right not from many beers >> [laughter] >> not to to get drunk and you have a head deck but the the effects that happen uh from uh from the beard driven development. So

team now can actually problem solve. If you are you if you have built trust with this relaxed conversation, if you have beat uh all the kind of communication that need to happen and someone understand that you are also try to solve the problem. The other thing that can happen in hangover someone suggest completely different approach that never took action. This is this is also huge. Think about

it. They to have a solution in your mind and because the environment doesn't have the condition to talk about it. You never told and this is just happened after that. And another person this is totally huge offers to help a task outside of his scope. developers write automation test because we try to release on Monday and we don't this this can happen I have experience with it

and of course the last one is all care about the output we are a team we success together or we fail together right there is no single person team that can do all these kind of things to do the development to do the QA to do the product management but the information from other roles it's too valuable for and my favorite quote I I shared with you

three quotes but my favorite quote is something that I have written is uh it's totally huge as a software engineer be because or we are engineers in software I can guarantee you that we'll meet people who act that they they know everything Okay, I have met many people that they try to know that they know everything. I know I'm a best developer. I'm a best QA engineer.

I'm a best product owner. Never be a talented jerk. Being easy to work with is a great quality. And this great quality that takes you far in your career, in your uh uh whatever, in your life, right? to to communicate easy to communicate with other easy to um work with other and produce actually problem solving as I said is something that will uh upvote your career to

the top. So key takeaways, BDD invaded to boost the collaboration, No tool until now can solve this challenge. No AI, no uh automation, nothing until now. The collaboration challenge cannot be solved. Psychological safety increase quality. This is a fact and I'm not saying it. Research said it. Okay? And of course beer is awesome. Uh or if you know about the Greek uh it's curo. So Nazraia I

think that I will wait the uh the hosts but of course I don't know if you have questions but if you have questions come to Shane Dra to the speaking corner and uh talk about it. Okay.