Boozang from the Trenches with Gianni Pucciani

Foreign.

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast and today we'll be talking with Johnny all about Test, his new book Bozang, a Boozing from the trenches. I'll find out the exact pronunciation once I have him live. If you don't know, Gianni works as a quality architect at Touring Club Swiss, the largest mobility club in Switzerland and he is passionate for efficiency and of course test automation and he likes to share his experience and challenges and his thoughts with the community. Has a great blog and I'm really excited about this book. We've had the creator of this tool on the show in the past and really great product I think a lot of more people need to know about and I think this book's really going to help promote it. So you don't want to miss this episode. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Source Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment for Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsors section to try it for free today. Check it out. Hey Johnny, welcome to the Guild.

Hi Joe, very excited to be here.

Great to have you. Is there anything I missed in your bio that you want the Guild to know more about?

No, no, I think it was complete.

Is it boozing or Bo Zang? I always get it wrong.

I said boozing.

Cool. So I guess for the people that haven't heard of boozing before or didn't check out our previous episode, what is Boozing?

So Boozang is a codeless web test automation tool. It's a fairly new, well we can say fairly new. It started in 2014. I think we started using it since four years. It's a test automation tool which really focus on web automation.

So interesting is I think you've tried a few different tools before you chose this tool. I didn't read the intro yet of the book, but I assume you set it up. Like why did you choose boozing? What led you down to find out about this tool and then go, oh my gosh, this is great, I need to write a book about it.

Yeah, that's a Great question. So we had experience with Selenium. We started using selenium around 2013. We used it five years on Salesforce mainly. And then at some point we found that Selenium was not really fit in our organization because we were too reliant on developers and developers were always developing developers. Availability was always tricky to find. You know, they were always asked to develop feature and much less to maintain test automation code. And therefore we started looking for a codeless tool that would allow us to be more flexible in terms of test automation, have the possibility to include other different people, different skills, not necessarily experienced developers. And at that point we started looking for some web test automation tools because our focus was mainly on web application. This is important. We didn't want automate tick client applications or or mobile application. We really focused on web applications and I started looking at the top of the market, you know, Gartner, Gartner, magic quadrant of test automation. I tried the majors and none of them was really pleasing me because either they were too costly, we had also, I must say cost was an issue or they were too invasive, they were offering much more and they were changing too much our test management life cycle. So we are happy with Jira with X Ray for manual test. We just wanted something to automate web testing and to integrate with our current development process. So at that point I stumbled again on your excellent podcast with Mats and it was, I think the first interview, hey, you had with Mats. And it was there that I learned about boozing. The podcast caught my attention and I said, okay, let's give it a try. And then I started my journey with boozing.

That's awesome. Yeah, Matzah's a great guy. So you know, I love that you work for like a big enterprise as well. So I think it's interesting that this is a tool that can help at the enterprise level. And I like how you lay out the very first chapter. You have common test automation challenges and I guess to kind of set up how to choose a tool, you talk about culture, skills and resources, technology and long term maintainability. So I guess if you were doing a proof of concept, were these the four areas you were looking at when you were selecting those different tools before you found a Boozing actually does fit our culture, the skills and resources we have, the technology and the long term maintainability that we're looking for?

Yes, indeed. The first part of the book covers a bit business case for adopting buzang in an organization. So what I find that also a reason to write this book is that on many books on test automation, they take the use case of companies that are developing software products. In an enterprise like us, we tend to adopt custom off the shelf, commercial off the shelf products and we integrate them into our IT landscape. So this is a different poses, different constraints. Because we don't own the source code, we cannot do the unit test is the editor that does the unit test on these solutions. We need more to configure this application, do some custom development and then integrate them into with our other systems. And I think this is something that pushed me also to write this book because I wanted to show how we used boozing in this specific use case. You know, not developing a product from scratch but adopting COD's solution in an enterprise environment.

Oh yeah, I love that you're not jogging any other tools either. You talk about Selenium maybe a good match for their culture, someone else's culture and technology. But I like how you said because you're an enterprise company, you're not necessarily a software development house. It's a different approach and different tools fit in better. So you do go over in chapter two, Selenium, some of the pain points you ran into. But then you come into chapter three when you talk about boozing. So what was that proof of concept like when, like what did you use to say, okay, this actually is going to do what we need it to do?

You know, first we did a sort of proof of concept with our e commerce website. We tried to see if there were major showstoppers and I think the first scenarios that we did, like we wanted to create a contact and do a sales process using our e commerce site. And this was quite quickly to implement. You know, with Busan we can use the record feature and then we can optimize some steps. So this was the proof of concept. And then we did the pilot phase. We had six use cases. Pilot phase was to compare busang with another codeless tool. And we took six use cases that we had defined and we evaluate how easy it was to build them and like if it was simple enough for us to use and how it was integrating with JIRA and our organization process.

What was the other codeless tool you did? A plc.

Again, it was this Testim or Testim. I don't know, Testim.

Okay, cool.

Yeah, it was very similar in terms of approach, but there were some, yeah, some factors that were much better done in booze.

What are some of those factors that.

Well, I think it was easier to use. I think developing the six use cases was easier and Also the modularity, the data management part that was simpler to use in booze. And then at some point, I think a major factor was that we wanted something that we were not limited in terms of test executions. So with boozing, it's a SAS application and you're not limited in terms of test execution. So once you automate a certain number of tests, you can run them as much as you want. We wanted also a license approach that would allow us to do so.

So you talked a little bit about Codeless. A lot of people kind of wary of codeless solutions. Can you talk a little bit about your experience, what codeless means for you and how it worked for you, what the approach was, why it was important?

Yeah, this is something very, very important because, you know, I was part of the open source approach, so I was very fond of test automation as development and that's why we started using Selenium. And then I slowly changed my mind. I think that Codeless today, let's say it's codeless, it's not no code. So with Boozing, yes, it's codeless. We should see Codeless as an accelerator. It's not a solution, it's not a magic one that you can use to do test automation, but it's rather an accelerator that can speed up the creation of the test. And yes, I mean this should be seen as an accelerator, not as a magic solution because there is always some code and coding skills to do a robust automated solution.

So at boozing, what language do they use? If you do need to modify?

It's JavaScript.

JavaScript, yes, I know you mentioned Gherkin and BDD in the book as well. Is this an approach you use or is this what they use for the codeless front end? Or is this just an option you have when writing tests?

Yeah, using Boozing, you can use Gherkin or you cannot. We normally tend to use Gherkin to define tests, user acceptance tests in X ray. So maybe we talk later about the integration with X Ray. But yes, the option to use Gherkin is an option in Busang and I think it makes test much more readable. Right.

You know, you go over the setup, getting started, you have like a test case approach that you talk about and then you go over how, what buzang is and getting started with Busang. Is there any gutches that people know about when they're starting with boozing that they read the book, they'd be like, okay, great, I don't have to worry about that because you have it laid out how to get around it.

Yeah, I think you know one of the most important Part two, I covered more or less all the Boozan main features. The basic feature that to get started with booze, I think people should understand very well the data management part, how to pass data from one test to another. Because I think then the success of an automated suite, it relies on modularity and how well you manage the data in your application from the gherkin data through the lower layer tests.

Now I also like in chapter seven how you talk about some concepts that you used as well. Working in enterprise, I assume you have to work in multiple different environments. So is Busang easy to point to your different environments, say staging or development or testing?

Yes. Busang has an environment section where you can define the environment that you use. For example, in Turing Club Swiss we normally have a QA pre prod and production environment. And with boozing you can define each of this environment, the categories and the applications. And then you can decide to run the test suite either on the QA environment or on the acceptance pre prod environment. But the same test should run. Yeah, should be easily run on different environments.

Great. So I know another thing people struggle with a lot of times is element locator strategies. A lot of these tools have like, you know, they have features built on top of slim that make it easier to find element or not even have to worry about elements or weights. Does boozing have anything built in that helps you with located strategies or weight strategies?

Yes. So Busang does not rely on Selenium. They build their own locators. And I think what is distinguish them is that they are based on the text, the labels that you find on the pages. So if you want to select a button, okay, you say just button. Okay. So you don't need to mess up with the CSS part or dynamic IDs. They have their own locators which are very stable and easy to use.

You also have a whole chapter on exit conditions, conditional flows and timers. Is that like a drag and drop type interface where you're able to like code without actually coding to get that type of function you normally would have like an if else statement or something like that?

Yeah, it's not really drag and drop, but you can define easily the for loops while loops exit condition. You can say for example, exit the test if a certain element of the web page is there. So you need to know how the tool uses these two, these two concepts. And then. Yes, then it gives you the flexibility of a code tool.

Nice. Another Thing I know people deal with a lot with is data management. So you have chapter 10 talks all about data management. What's like a key point of this chapter you think is a good takeaway about test management? You do have a case study or examples from the trenches that talk about this. So maybe a real world example of what you struggle with and how boozing's test management helped you with it.

Yes. So I was saying before, the data management chapter is one probably one of the most important. So in our, in the book, more or less for each chapter I try to put an example from our project. So what we didn't mention so far is that this is a. I wanted to have from the trenches in the title because it should give the idea of a book that reflects a real experience. So this is all the examples are taken from a real project that we were just about to finish. And yeah, I think for the data management part there are interesting examples on how to locate for example dynamic tables, some tables whose lines and columns they are dynamically built. So these are the interesting exercises. And then of course for data management I show also how you can use data at project level, at module level or at test level. There are different context for data management that person should master.

Nice. So another thing people look for when they're choosing a tool is reporting. How's the reporting in boozing and how does it help you and your team?

Okay, so for reporting we rely a lot on cucumber reports. So therefore executing the test through Jenkins, we can use the Jenkins cucumber report plugin. And then one thing that really stand up for boozing is the root cause analysis report. So this is something that in the past I was spending a lot of time, you know, to analyze failures and see, okay, why are they happening? And then you analyze one day and the day after you need to re perform the analysis. In Busang they created the core root analysis report where you can have a sort of repository of known issues. So the first time you do the analysis of the automation results, you can say, okay, this failure is an automation bug, this failure is an automation issue, it's an application bug or automation issue. And once you record these known issues, the next time you will run the execution, it will remember what you set and therefore you don't need to redo the analysis. So you can do the analysis only for new failures.

That's a big time saver, I would think. A lot of times you'll come in, you run the test during the night, you come in the morning, you have an open bug and you're like, oh boy, there's a thousand defects. What do I start with this automatically? Then will tell you, hey999, these are already associated with the known bug. You don't have to look at them. Here's the one that you definitely should look at. Because it's new.

Exactly. It saves a lot of time and it complements also the test execution report. Because if you say 98% pass rate, okay, is it good or not? It depends on the 2% of failures. Are they known issues, are they new, Are they critical?

That's a good point. You know, also a lot with these tools, sometimes people just focus on the ui. Does this have the ability to help you with API testing as well?

Yes. So they do offer also API testing. I think the API module is free in boosing, but they offer the possibility to execute PI tests like other store like Postman soupui. But the advantage is that if you do it in boozing, you can test APIs and you can mix APIs and GUI actions. So in our scenarios, most of the time we create the preconditions via API to save time and then we execute the validations on the gui, for example, to create a contact. All the scenarios start with the creation of a contact in the CRM. And this we do it via API to speed it up. But it's nice to have this flexibility to use the GUI or the API in certain cases.

Absolutely. And I just looked at their website. You're right, Community API Edition is free, so people should definitely check it out. I'll have a link to that in the show notes. What's really cool though, it actually lists pricing, which a lot of companies don't, don't do. And it seems very reasonable. Still, from what I.

It's quite transparent and reasonable pricing.

Yes, I know that's something that Matt's talked about in the past, that you know it's price solution, yet it's affordable and you can actually see the pricing as well. Cool. So you go over API testing once again, you have examples of using it in the trenches and then you get into Gherkin. So are there any differences when you're using Gherkin VDD within boozing than if you were to use it, say using another tool or an API like Selenium?

Yeah, the Gherkin part. So we don't do real BDD in our case. So we use Gherkin but we don't have a real BDD approach. Something that we would like to try in the future. But we're not yet there.

All right, good luck.

Yes. No, I think in terms of options. So we define our tests in X Ray using Gherkin and then they are imported. Boozan offers you an API to import tests from X Ray. So therefore you can start the implementation from the Gherkin steps as in any other tool. I think probably the difference that you might have with Coded solution is that you are reliant on the existence of the gui, so you can set up more or less everything, but then the final implementation, they need to rely on the gui.

Absolutely. You also have some good examples and bad examples of bdd. People need to buy the book to find out what those are. So in chapter 14 you go over Jira with Busang via X Ray. So what's that all about?

Yeah, this covers how we used Jira and X Ray with boozang. So all the integration part, which is bidirectional. So with X Ray's test management solution, probably the best that is available in Jira. And when you define the test, the master of the test definition is always X Ray. So Busang will import the test definition in Gherkin, then in Busang we do the implementation and then when we execute tests through our CI infrastructure, the results are pushed back to Jira. And this is what I cover in this part. The bidirectional synchronization, X Ray boson and then back to X Ray the results.

Now, is that a plugin that they provide or is that coding you had to do to create that integration?

No, it's just simple configuration. In Busang you just need to specify the filter that you want to use to select your test in X Ray and then it calls an API from X Ray.

Nice. So it seems like it's extensible too. So if someone had to integrate with something, it makes it easy to do.

Yeah, they have more integration than just Xray. Yeah, perfect, perfect.

Also you have a chapter on CI CD using, I guess, boozing the runner with Jenkins. So any gutches here or things people need to know about when they're using Boozing with the CI CD tools?

Yeah, I think in that. I think one of the most interesting part is that I put formation on our pipeline in Jenkins and I put a lot of information on how to do parallel test executions. So Busang has a docker image to run the tests and you can use multiple docker runners. So they are called boozing runners. So in our project we use 10 runners and we can dispatch tests to these 10 runners that are executing in parallel And I think the cool aspect of these runners is that they can execute parallelism at the iteration level. So not just a single scenario, but each iteration of each scenario when it's data driven, each iteration can be executed in parallel. So therefore it allowed to increase the execution speeds quite a lot. And then we have integration, other integration with Jira also to get the environment from JIRA and to create the test execution with X Ray. I think the pipeline is quite complex and I think it was one of the most interesting chapters too. Right?

Yeah. I like how you list it all out, exactly what it is and to get that working pipeline. So this book really goes with the title Trenches from the Trenches because you are sharing pretty much like you said in every chapter, real world example, how you did it with Buzang. So people can actually see it's not just like going off a documentation that they provide, it's actually showing how you actually implement it in the real world, which I love.

Yeah, there are no dummies examples. There are real examples. They might not be perfect, that's of course the case. But this is what we used. Yeah.

So how is it with collaboration? I know you have I think a chapter on here with boozing with teams. Does it help you collaborate with other team members? Does it have any features that help you work with others?

Yeah, I think one of the most interesting feature for using busang in a team setup is the branching and merging. So it allows you to create branches as much in any other development process. So in our project for example, we use the feature branch approach. So every time we want to create test automation for a new scenario, we create a new branch from the master branch, we implement the new scenario in that branch, the boson branch. And then once this scenario is run correctly locally, we push this scenario into the master branch and therefore it will run in the nightly suite.

But that's a good way to separate concurrent development.

Oh cool. Very nice. So as I mentioned, the book is 16 chapters. I think it's like 350 pages. And just curious to know who is this book for? I mean is it just. It seems like someone could read this book even if they're not using boozing to try to get an insight into real world problems people are facing and how they overcame them. But who did you write this book for? I guess the question.

Yeah, I think it can be interesting for many people. So not just for test automation engineers, but I have also chapters about the ROE of a test automation initiative. So like managers can understand also how to evaluate test automation initiatives. It can be interesting for delivery managers, business analysts because they get some input on how to collaborate with developers and testers. I think it really shows a real experience with a test automation initiative in a real project. So could be interesting to different kind of profiles. Nice.

And this book is going to be through a press so it's a legit book, technical, but when I release this episode the book will be available. But just curious to know like when is it going to be available? So if people are listening, where can they get it?

So it should be available before Christmas. So the date that I have is the 23rd and it can be available on Amazon and the main bookshelf.

Okay Gianni, before we go, is there one piece of actionable advice you can give to someone to help them with their automation testing efforts and what's the best way to find or contact you?

I wrote the contact of via LinkedIn. I can be available of course there is always via my blog. I wrote a blog about the construction of this book also they can comment on these blogs. Piece of advice. Well, everything in test automation or every solution needs to fit an organization. So there is no one size fits all solution. So in our case which is I think it can be representative of many enterprise context we found this solution and I think in even if without adopting Boozan, the approach mentioned in this book can be interesting with other web automation tools. And then in terms of test automation, really it has to be the modularity of the automation suite is the success key because if it's well built and modular it will be always easier to maintain and therefore that is where you see if an automation initiative is a success or a failure.

Love it. Thank you so much Gianni for this book. I think it's much needed and Matt's a great guy so hopefully a lot of people are going to pick this up and really give Boozanga a spin because I think it really is a helpful tool. So thank you so much and I.

Hope there will be more experiences like this shared in the future because I was yeah, I think it's good to share real experience, not just tutorial books.

Exactly 100%. So get your hands on that book and get a real world experience of an automation tool put through its paces in a real world environment for sure. Thank you Gianni.

Thank you Joe.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode head on over to testguild.com a429 and while you're there make sure to click on the try for free today Link under the exclusive Sponsor section to learn all about Sauce Labs awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.