258: Boozang A New Approach to UI Testing with Mats Ljunggren

At the end of the rainbow all my promises were lie welcome home to my broken promised land and that just.

So you know, I think I recorded you singing. I thought it'd be funny to add that as the bumper music. So just a heads up.

Oh, no, I was gonna ask you. I was like, no, I wasn't, Jordy. I was, I was, I was, I was just seeing if the mic was working. I'd love to sing, man.

Welcome to the Test Talks podcast, the place to go to geek out on software testing. And now your host whose mission is to help you succeed with Test automation, Joe Colantonio.

Hey, it's Joe. And welcome to the Test Guild Automation podcast currently known as Test Talks. As I mentioned before, I'm going through a rebranding effort and the name of the show, my blog, it's all going to change to be Test Guild. So just trying to prep you before it actually becomes official today. I know what you're thinking. Another show about an automation framework. So I really think that each team has unique testing needs and so that they have different options than my team has. And my option might be better for me, but not work for you. So. So you need to find an automation framework that really supports your truth. So today we'll be talking with Matt Youngren all about Boozing. And Boozing is a AI based web automation tool that is written purely in JavaScript. And so it uses something called an HTML snippet technology to allow you to run in any browser without any extensions or local installation. So has a bunch of different features that are kind of unique to it and also kind of a mashup of a bunch of other tools we've covered. So take a listen, let me know what you think. Check it out. Test Talks is sponsored by the fantastic folks at Sauce Labs, the cloud based automated testing platform that eliminates the need to maintain your own selenium grid and test infrastructure. Try it for free today. Visit testtalks.com and click on the sign up now link under the homepage sponsor section.

Hey Matz. Welcome to Test Talks.

Thank you very much, Joe. I'm really happy to be here.

It's really cool to have you on the show. You told me earlier about a new framework you've been working on. I don't know how new it is. It's been around for a few years, I believe, called Boozing.

Yeah, Boozang.

Awesome. So I'd like to talk a little bit more about that, about your thoughts on automation in general. But before we get into it, could you just Tell us a little bit more about yourself.

Well, so I'm Mats Youngren, I'm currently in Montreal. So I'm living here in Montreal since about 10 years back. I really love it here. I was working out of Sweden, I'm from Sweden for a small, small company that got bought up by Ericsson and that sent me around the world and I was working a lot in the United States and Latin America. And then basically I defaulted back to Montreal where I'm now running software test automation company.

Very cool. So what got you into automation? I believe your background is not in QA or development. I believe it was in development, not in qa. Is that correct?

Well, my real background is actually in physics and artificial intelligence. Like back in the day when it was like the second wave, you know, when people said this is going to change everything and then it didn't and it went away. You remember that, Joe, right?

Unfortunately I kind of. I do. I probably remember the first wave too.

Oh yeah, okay. I don't remember the first. I wasn't around for the first wave.

So that's awesome. So talking about AI, we'll get into it because I believe you actually built in some AI into your tool so you actually have a background. So it's not just like you're using a buzzword probably. But I think we'll dive into that a little bit more before we get into it though at a high level. What is boozing?

What it is really is a way to just similar to a lot of products out there. We're just one take on this codeless test automation. So the idea is to really quickly and easily to be able to build end to end tests using the web browser. So workflow tests, basically.

Very cool. And how long has it been around? I know you said it's been around for a few years, but you just got it to a point where you think it's really ready to be pushed over the edge to become mainstream.

Yeah, exactly. So we've been around three years. We had paying customers for like about two years, a little less than that. But then of course we're trying to develop this new automation language that was now the first was ready in around February this year. So before we had to have a pretty small customer base because as soon as you do a major change in your elemental language, the test automation language, you would have some customer impact. So if you have too many customers, it's just not possible. So I think now we're ready to scale up and commercialize properly.

You mentioned you have a degree in physics and AI. So that is a very hot topic in the software testing community. What do you think the role in AI is in test automation and quality insurance in general?

Well, I think we take a little bit different approach than a lot of the other companies out there. I mean, not try to say that they take the same approach. It's just that we believe that first we got to create the automation language in a very specific way and then the AI kind of comes next. I know a lot of companies are using kind of AI and learning technology to create more stable tests. We are trying to create a test representation and then use AI to be able to better understand and automatically create tests from requirements. So it's a little different. The approach we have, our approach is very, very, what would you say? Ambitious. Right. So it's a little bit, a couple of years forward in the future. So it's not. We don't know 100% that this is going to be like. We haven't seen 100% this working just yet.

So can you give an example of how it currently does work to give people an idea of what we mean when we say AI, the way it.

Works right now is we worked a lot in creating, instead of using CSS selectors and these ways to identify elements, we basically created. Even when you record a test, it records it in natural language. Basically.

If someone clicks the button Create Project, it says click Create project, not click XPath or click CSS selector. By doing this and using natural language, a requirement would read click Create Project. Our test would read click Create Project. So it allows us to do a lot of stuff from requirements and also to be kind of future proof for the kind of next wave of AI test automation tools.

How does that work? Is that similar to you would record a script and then you tell it what it's named, or does it have built in language that already is able to drive a browser?

It's able to drive a browser. You can do either or you can record the test, or you can actually use our language to write the test and then it would be automatically run in the browser, just the text you write. Usually in practice what people do is they record the test and then they might be like, okay, now I might use the text version of this to copy this test and save it and update it. So it's more like usually I would still say that the normal way to create the test is still through record replay, but this text version of the test also carries a lot of value. For instance, if someone reports a bug, you get A notification in your email and it's basically just says the actual text on how they got and did the bug. These are some of the advantages with our technology.

Very cool. And you know, some tools, when they use this type of approach, some people are a little put off because they think it's like a black box. They don't know what's going on. So as these tests are written, is anyone able to look at how the test is being generated or are they able to modify them with a code? Or is it just all behind the scenes taken care of for you?

It's a little bit of both. I'm just going to challenge that notion a little bit because without going into competition, let's look at how Selenium does it. Right. So with Selenium, you're basically writing something that is being translated over a web driver. So I remember using Selenium ide, you would record the test and everything is fine and hunky dory, but then you run it from the command line and you run it using the webdriver and everything breaks. For me, the web driver is the black box. It's the meddler in the middle. While we actually wrote our thing in JavaScript and it runs within the browser, as soon as it runs within the browser, it will also run within a headless browser and will also run from the command line. For me, I'm looking at it a little bit differently there just to challenge that notion, but otherwise you can take a look at the code, but it's not really that interesting because it's more like the language is just click create, project, do this, do that, and then our engine just converts that to actions directly in the browser using a JavaScript bridge.

Very cool. So I guess you touch on a lot of hot topics. I know hot button issues. I know people always ask me about. The first one is AI, which we touched on. The other one is codeless. So when you're saying it's a codeless test automation, it's a combination of the ability to record and playback and also the ability of your natural language just to write a test and not have to write any code. Is that what you mean by the codeless approach?

Yeah, it's a little more than that. We look at testing from. I come from an information theory background. We have a very scientific approach and I don't think it's for everyone, but the way we look at it is all the path through a web application is like an information graph. So as soon as you come to a decision point, for instance you have an assertion, then you can say add items until items are like, until 10. And then you can assert the number of items and then you can call other tests and create this kind of if else branching and drive a lot of logic testing as well. So we kind of look at as. Of course it's codeless, but it's very, very, I would say powerful in. You can plug in other tests. Tests can refer to test. Test can refer to other tests in a conditional manner. Right. So it's a little more than that as well. But yeah, in general, it's a codeless tool. It's a record and replay tool.

What technology is this only for browsers? Is it because it's not using Selenium? Does it only work in Chrome? Which technology does it support? And can you use it against API test as well? Yeah.

So not using Selenium. In the beginning we were starting with Chrome, but because we Write it in JavaScript, when you write it for Chrome, it was never a problem to support Firefox, it was never a problem to support Opera, it was never a problem to support Safari. So all those was working equally well. Then we had a big problem with Edge for some reason and now we. We just download Edge. Just. They released the beta version for the Chromium engine.

So now we've just tried it on Edge and now we support Edge as well. So now we're pretty. So of course. IE Internet Explorer. No way. So we're looking to the future there.

Cool. Can you also leverage. Can you leverage that against a mobile app or mobile testing?

Yeah, for anything that is hybrid. So anything that is web browser driven. So anything that is Corvedova works really well. Anything that is like there's a few of those hybrid things, but the key is JavaScript. We write everything in JavaScript. We believe the future is in the web browser. We never even touched on native or anything else.

We kind of nerds when it comes to JavaScript. We do everything full stack, we write our own JavaScript frameworks. We really like JavaScript, so that's our constraint.

Now I was speaking with another person about a tool called Open Test and I got an email response with someone saying, because it's codeless, how does it work with requirements in this particular tool? It doesn't really work with requirements, but I believe yours does. Can you tell us a little bit more? I believe it's able to generate tests for you automatically based on requirements. Do I understand that correctly?

Yeah, that's a little bit in the future roadmap. The way it looks now is now you kind of have to write your requirement. You got to take your requirement, write it in a slightly awkward way. The way I usually do it is I take user. If I have a user acceptance criteria, I'll just write the acceptance criteria in gherkin or behavior driven syntax and then those translates into pluggable tests. The first test will set you into the initial state and then you would have one or many when statements and then you have a desired outcome. And that way you can very much. You would use our tool to create all the test building blocks or the atomic units which are these kind of states and actions. And then you can actually just kind of use this to build it. So it's not like perfectly matching requirements to test just yet. So I would say we're on the first step of this.

So it's almost like as long as you write your requirements in the natural language that your tool understands, it would work with requirements. Is that exactly? Yes. Cool. So also because it's a natural language, do you use things like navigate to browser and then click on this button? Or is it more like as a. As a. As a doctor I want to check out my patients and then behind the scenes it does all the low level type information.

That's a really good question. As a doctor, that's what we have now. We just kind of added that a couple of months ago where it automatically will kind of. You will insert all the.

Criteria for the different users and then you're going to do one login using a wizard and then it's automatically going to be able to shift between different users. Now we have that where you just hit the checkbox for a test and then it kind of does like if it automatically will force a doctor to run that test. The bridge we're missing right now is to be for you to say as a doctor and then it automatically runs that test. But I think that's a very small modification we need to do. So I think this is. It's going to be out there timeframe would be this summer.

I think it is based on AI. You do have some sort of AI technology in there. A lot of issues I see a lot of times is when someone specifies click on a dropdown. The team may refactor over time and then it becomes like a list box and then it's no longer a click, it's a tab. How does this tool handle something like that? Is it handled automatically for you where it'll know that not only did the object type change, but the action that needs to be performed against it changed.

Right now if you run a test in that scenario, it's actually going to complain and say hey, we cannot find this object.

And it will force you to reselect the object, but it will figure out what to do. That's where we are right now in the AI version coming. I don't know. I think we're doing our first release next month, but I don't know. General availability would probably be August or September timeframe. Then it will basically the test, it's going to interpret the test as it runs. So then it would be able to figure that out in many cases I would say.

Right. So as of today, if someone's using the current version, if for some reason does change and it does get that pop up, does it self correct all the other tests that may rely on that object, does it have some sort of mapping behind the scenes that it knows then? Does it have to do that for every single test that uses that particular field?

That's my favorite question. Yes, it does. It creates that mapping behind the scenes even with language issues. Right. So if it's says create project and you change that to add project, it also does a similar thing.

So we also speak earlier pre show about the emergence of low code and no code and what this means to testing. I guess can you just give us a little insight of what you mean by the emergence of low code no code?

Well, in our long game, right, we are clearly geared towards test automation. The but if we are fully transparent, what we are working towards is a way to convert to feed the machine requirements and build the whole software.

We really like the idea of having software that builds other software. And in a way if you're looking at a low codeless test automation platform, it's software that builds other software because it builds automation scripts. So if you really figure out the bridge between requirements and tests, there is nothing really stopping you right now when JavaScript is so powerful that you can have JavaScript that runs in the browser, that can build both the test and the code and that you can run on the fly in the browser.

We think that there was a few, you know, way back when there was this platforms coming out claiming you go into a user interface and it builds software for you. And we don't think that these, I looked at these tools, they don't look very modern. I don't think they're, you know, they're worth a lot of money but we don't know if their approach is the right one. So I think in the long run here we are probably going to take a stab at also generating certain types of software.

So it's almost as like model based testing.

Yes, it's exactly like model based testing. Yes.

Very nice. So you seem very ambitious. You keep saying down the road, so how big of a team do you have? Do you guys have a huge team or is this just.

We're a team. So basically what it is, it's in the core team. It's me and my co founder. So I'm doing all the business functions, just my co founder does all the development of all the custom technology, has been in the business for a long time and we are the core team. Then we rely on a lot of people working with us voluntarily in the open source community and people also on the business side helping us out. But there is only us two right now in the core team because we have actually, we're completely bootstrapped. We have not raised money from VCs.

So your partner must love when you say that's coming down the road. He probably has a very long list of things. So that's awesome. Yeah.

What I mean is of course is that we are looking. This is what we do right now. Right. This is not like a, it's a startup, but this is our direction in our lives and what we want to work on. So for us it's okay to have a kind of a long perspective. And then of course it's very hard to know what really will happen. We actually thought that the AI stuff that's coming out now, I think we thought was going to come out six months ago. But you realize so much the complexity of this and why so many people have, you know, tried and not really been able to deliver.

Now why, why do you think that is? Do you think people over promise or. It's, it's. The technology really isn't what people are selling us when they see AI.

One thing is. Okay, that's a good question. And of course I want to be as diplomatic as possible here. I think one thing is it's we, I think a lot of people go out there and they want to build a product that is like really, really quick and easy to use and then build on top of it. We went out the door and said we're probably going to build a little bit of a complex product. And then now we've been able to have better and faster user adoption because as our technology emerges, we can remove a lot of the complexity. While if you start with a very simplistic tool, it's Hard to build on top of it. I think that might be part of the reason. And also who knows what people are doing in secret, right? Perhaps people are sitting on super duper technology right now and they'll just announce it tomorrow and then we'll be like, oh, very true.

So Matt, I don't think we mentioned it at all. Is this tuliped or is it open source? Is it a mixed model?

So what we do is we have a mixed model. So you have an entry level which is free. And this is just to get a lot of user feedback and adoption. And the way we limit that is only on the number of actions. So the entry level.

Licensing option, the paid one, starts at $100 per month.

And what does that get you? Reporting or parallel running, what does that get you?

It basically gets you everything for two users. And then we basically be like, if you want to have a little more. So what we'll do is now we're just doing it kind of seat based. So if you want a team license, we'll just charge that at a different point. So we want to get into the companies, get one or two people started using it and as your team grows, you pay more. So that's the idea. So right now for 100 bucks you get everything.

You know, we touched a little bit on, we touched on AI, we touched on creating the test. Once again, the role of automation is changing. There's been a lot of approaches in shift left and shift right. Is there anything with this tool that helps teams make that transition to not just focusing at the end but also shifting left and shifting right in production?

Yeah, I was actually listening to a talk about the shifting left and shifting right and I was like thinking about how our tool plays into that. And I think when we talk about shifting left and testing early in the process, I think when you're a small organization, right. I talk to a lot of these software as a service companies and they have this ambition to do test automation. But it stays at an ambition and it can stay like that for a year or two and they keep doing manual testing. So there our tool would help them to be like even a non technical product owner could use our tool. So then they can create the acceptance, testing and all that stuff and then they can move that. So the developers kind of, it acts like a gatekeeper for the developers and they get instant feedback when they break something. So that's kind of the shift left that we are doing. I think that's our biggest role that a non technical person can go in. Because otherwise when you scope out all this test automation, but you're a small company, you're building features, you never want to prioritize test automation over features. So the test automation always loses. But if you have a product owner or a QA person, they might have the bandwidth early in the sprint to do this work for the shift. Right. I think what we're doing is because we're pure JavaScript and we have this fragment technology, we are working a little bit to see if we can use live traffic data and also for users to be able to report bugs directly using our tool. And then the bug will show up like an automatic test in our tool with an annotation saying here something is.

Wrong with any type of AI technology, any changes or shift in an industry. People are always worried about how is my role going to change if someone's currently a QA engineer or a automation engineer that really focuses on selenium writing code, do you see that role changing at all in the next few years as these AI type tools become more and more popular?

I actually do. I also think that the traditional QA role is changing as well. Not just how they were talking about manual moving towards automated testing. Now I think when we're going to have a lot of tool in the market, we'll be able to to do a lot of the auto generation of test code. I think it's important that the QAs are able to imagine the test scenarios, model the tests and understand the customer. Just like before, the developers would code in their silos and then it would come out to the customer and it would completely break and the QA would be a bridge to kind of stop that from happening. I think now more than ever it's even more important that the QAs understand what the customers do, because what AI will never do also is to be able to report is this good usability, does this feel right? And also to imagine all the scenarios the closer the QA's are to the customer understanding. I think that's where the shift going to be. So I think that's my answer. But who has a crystal ball, right?

Absolutely. Okay, Mats, before we go, is there one piece of actionable advice you can give someone to help improve their automation testing efforts and let us know the best way to find contact you or learn more about boozing?

Well, I guess I should have prepared something to say here because I don't come from a QA background, perhaps I'm not the right person to listen to, but one thing that I've been doing more and more because I used to work for a big company, big telecom. I wouldn't used to be kind of. So I would be so interested in the current and not the future. But right now I'm so interested in what's happening with these technologies. You know, through Medium you see a lot happening and a lot of people posting. So I'm just really keeping my, you know, I love testing new technology, I love following, you know, what's happening on product hunts, what's happening with new tools. So I would say keep listening to podcasts like this one and see what's going on in the industry because there's also a lot of opportunity with these big changes. There's a lot of opportunities. I think if you stay hungry and stay current, then you can identify trends early, do stuff that not a lot of people are doing, and then there's a lot of interesting stuff that can come your way.

Very cool. And that's the best way to find contact you and learn more about boozing.

It would be go to boosang.com b o o z a n g dot com and everything should be available from there. I think there are some social media links and you know, just contact me directly.

Thank you. Mats for your automation awesomeness. For links to everything of value we covered in this episode, head on over to testtalks.com for.

And while you're there, make sure to click on that. Sign up for a free trial link under the exclusive sponsor section to learn all about Sauce Lab's awesome products and services. So that's it for this episode of Test Talks. I'm Joe and my mission is to help you succeed with creating automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Talks podcast. Head on over to triple W.TestTalks.com for full show notes, amazing blog articles and other automation awesomeness.