 All right, so everybody caffeinated? Yeah, am I audible at the back? Fine, fine. So hello everyone, I'm Irfan. I work as a release manager at Upgrad. It's a startup company in Mumbai. It's an online learning platform based in Mumbai. I have a website IrfanAmba.in where I write blogs mostly and spend a lot of time on Twitter. So my handle is no time waste. I'm also interested in writing retro game apps on mobile and I also do amateur standby comic, very amateur. So today we're going to talk about testing as a chat. So how many of you use any chat tool in your company during your work? How many of you keep your hands up? Okay, pretty much everyone keep your hands up. If you are also using the same tool to do some operations through it, like some deployments or something else, keep your hands up if you also use the same for testing also. I think one person does that, fine. Nice, nice to know that, yeah. So why we want to do this talk? Just to clear your expectations. This is like what we are, is it visible? Yeah, so not visible? Okay, fine. So we all get a lot of questions any time of the day and just like every superhero, like I get inspired by a lot of superheroes and I'm always interested in figuring out that how those superheroes are superheroes. They look like human beings, but how are they? So I figured out like if you look at Tony Stark he get a lot of questions, he has a lot of work, he has a lot of things to do, like he has to do laundry and other things, but what, how it is managed in his case. He had Jarvis, which manages when he's doing other things. So the question that we can ask ourselves is that who will manage our business when we are busy saving the world? There's a lot of ordinary things that we do in our day-to-day life. There's a lot of extraordinary things that we did do in our life. So how do we make sure that when we are doing extraordinary things, who will do the ordinary things? So this is the idea behind this talk to understand how there are a lot of ordinary things that we can do, we can automate and how we can use chat-based tools for it. So the outline is we'll start with why do we need to run our tests with chat? What, how are we going to do that? Does it really work? And what will the next steps, like how you can implement it and how you can take it ahead in your company? There will be some examples that I'm sharing. Most of the code is there in GitHub or so that you can take it from there. So why do we need it? The first question is why? So as team size increases, the communication gap reduces. So how many of you have a team size of like one or two persons? How many, two to 10? Okay, 100,000 million? Okay, so nobody's from Indian railways. So yeah, but I just see as a team, as a number of people in the team increases, the communication gap also increases. And there is a huge problem when we want to communicate something or we want to train someone about what has to be done and how it is to be done. So that's one communication problem. Also how we do conversations. So we use conversation tools like emails, chats, meeting and physical meetings. How many of you use emails for communicating, test results, anything related to tests? And how many of you use chat? Very few. How many of you do meetings or physical standups to communicate these conversations? Okay, majority of it. So a lot of time goes in doing this in cups and meetings and the amount of things that we share, the sort of things that we share, are pretty very basic things that we share some data, we share status, we share problems. And these are very basic things which can be very much included in our chat-based tools or any communication that we do and so that we can focus a lot more time on productive work. So the current scenario is that this is a survey which was done mostly in startup. So a lot of companies are still using emails, but the chats are, the chat-related conversations are increasing a lot and the future is more towards it. So what do we communicate? So on day-to-day life basis on chat or emails, what are the questions that as a developer, as a tester or as a product manager or like whatever it will be, what are the questions, what do we communicate? Okay, good, good. Anything else? ETA, yes. Anything else? Status, yes. And anything else? Test coverage, yeah. Yeah, so these are the pretty things that we share on communication, like we share some data, like what is the test coverage? We share the request, like when the build coming, test results sometimes scored, it's a pretty horrible idea, but some results, status, problems, defects, solutions. If you see clearly a lot of things, these things does not need to be asked or does not need the person to be available at that time. Like if you know the build status, it can be directly queried from somewhere. If you know the test status, anybody can run it from somewhere. Like you can be just sitting in this selenium con and running some tests from here. So a lot of these conversations, the activities that we communicate, a lot of these can be actually done and can be shared without the person being there. That's one of the reasons. One more reason is the DevOps is moving very fast. They're quicker release cycles. You see some companies shipping things daily basis, early basis. Also DevOps brings this CAMS thing which is a culture of continuously improving things, automation measurement and sharing. And this is very much encouraged in DevOps processes and everything. And yes, the visibility across the teams. But if you see the way how testing teams work or that how we run the tests or how we do it, this is not as fast. It is very difficult to catch up with the current way of doing things like somebody giving us asking for a build and then giving us and doing the things like that. So it's even though the operation side of DevOps has moved very quickly in terms of implementing the CAMS, the testing side is very lagging and this will affect the, they definitely affects our release cycles. So our entire presentation will be very much focused on chat ops. So what is chat ops? It's very simple. It's bringing the work that you are already doing in conversation that you're already having. So in simple words, putting tools right in the middle of conversation. So if you're having a conversation and you're asking about what is the build status, you get the build status without that person having to be present in that state. This is not a new thing. The chat ops is not a new thing. It was coined in 2012 or 13 I guess by GitHub and since then it's being used heavily mostly by ops operations people. Whereas I see within testing it's not being used much or even if it is used like I did a small survey to do that, it's not, that option is very less or very negligible. So this is one example I hope that you can see. So there's three people talking on Slack on one of the communication channel. The project is critical project. The product guy is asking that we need to ship the product today and the developer is saying that he has done all the bugs. Tesser is not sure. He's asking the bot. The bot name is Raj. So he's asking the status of a bug. So the chat bot connects to the bug database and informs about the status. And if it is all done then the tester redeploys it on one of the staging environment and tries to check it. This is just one example of how chat ops thing is there. And it basically makes the conversation flow easy like you don't have to switch on different places and go back to back. So if you see the types of conversations that we have, they can be categorized in four sort of categories. One is pushing context like you're informing someone that this is the status of this or you're pushing the context into the communication. Second one is that without having somebody tell you, you are pulling some information like you're querying that what is the status of this bug or what is the status of all the tests which ran for this app build. The third which is little bit more complex is bidirectional interactions. Basically when we are performing some running some tests and doing result analysis on that. The fourth one is doing custom tasks like running a Jenkins pipeline or doing a production deployment and doing all the checks. And all these things were initially designed for chat ops for operational people. But if you see these things holds very much true for testing, like these are the examples for pushing context, test results, for pulling information you can just query the status, running tests and performing releases with all the checks. But what we see was that chat ops is mostly related limited to ops and not much used in testing. So that leads to a conclusion that chat ops for testing is awesomeness. To bring more perspective to this, I'll talk about a story. It shows that how QA releases happen and what are the things involved and how the role of chat bot is can be made important. Like how important is the role of a chat bot can be. This is how some sort of companies choose to do releases. Like we also do release train. So every, on a certain days, on a certain schedule, we take out some code and start testing on it. And after that, we run the test and we mark it and then this is how the code is released. The period depends on what product is. Sometimes it's week or sometimes it's days. So here is the chat bot that you saw. It's the name is Raj. It's release automation janitor. It's role is chat bot. And the goal is that you also take out a new Simran to live every week or every day. And here is the software itself. Name is Simran, a software implementation of requirements authored by nerds. The role is a release build and she want to go live ASAP. But there's one more character. Is Babuji, bodyguard of agency, bugs in user journey and incidents. His role is QA and goal is to take care of Simran. Another character is mother of all apps. Role is developer. And goal is to see Simran living her life. And the final one is mother of all arbitrary assumptions. Can anyone guess who is this? Whose character is this? Okay. Yeah, product owner. The goal is to see Simran's children and family growing and bringing business. So this was just to add context to how chat bot can be made important. And this is how we kept the name as Raj to our release automation giant, the chatbot. Next interesting question is how we can do this and how it is done. If you want to start with using chatbots to test, the prerequisites are that you need a chat platform. You need a bot framework to work with. Basically you can start with any of the bot frameworks open source available. We'll discuss about that. Third is service integration. So basically anything that you want to do via chat has to be there available as a service. So let's say if you want to run a test, that has to be available as a service or it needs to be a part of capability of the chatbot itself. And the fourth, often not a problem in many companies but can be a problem is a culture, a culture of sharing and transparency and openness. Sometimes it can be a problem but if you want to implement a testing via chat, you need to have that openness. If you feel that you don't want to share something, you don't want to share your failures, so that will be a problem in implementing this. So coming to the chat platform, most of the chat platforms, they have capabilities to easily integrate with any other tool or bots or also known as apps. Like some people use Slack hip chat. So what different chat platforms do you use? Like how many of you use Slack, okay? How many of you use something else like hip chat, okay? We use both, okay. So and anything else, FlowDoc or FlowDoc, okay? FlowDoc is also very much integratable. IRC, okay, what else do you use? Skype, okay, so Skype is something I have not tested actually but will be interesting. Second thing is so all these chat platforms that we talked about has capabilities to integrate with these apps based on some APIs if they are available. Second one is Bot Framework. So you can choose any of these open source Bot Framework. There are paid SaaS based tools also but these are very good open source tool with very good community. The most famous is Hubot. It's very good, the plugins availability is very good. The only downside is that it's in, that you have to use CoffeeScript or JavaScript. Second one is Lita which is in Ruby which we will be using in our demo and GitHub projects that we have, that I have shared. It also has very good variety of plugins and support available. The another one is Airbot, then we have Cog. Airbot is in Python, Cog, I think it's in Node and YetiBot is I think in Erlang so based on your preferences, you can just see which suits you better. So as I mentioned, you need a chat platform, you need a Bot Framework and you need to have service integration. So anything that is available as a service or exposure service can be used via chat. So for example, if you use only native third-party integrations, so in majority of these in chat platforms like Slack or FlowDog, there are already apps available but the downside is that the capabilities exposed by these apps are very limited. They are very stable and easy to use but it's very limited. Like say, GitHub has an app for Slack and for also for hip chat. Same is for Jenkins and Victrops but the capabilities exposed by them is very less. It's all of them falls mostly in the category, first category of communication which is pushing the context. There's no much support of bidirectional and pulling the enquiring. So if you use third-party integrations, that's very good. It's very easy but there will be some limitations and we won't be able to use much of the capabilities of the platform that we're using like GitHub or Jenkins. If you want to evaluate Bot Frameworks, one of the things is if you're using a bot, how it differs from, okay, so if you use only third-party integrations, there will be like a lot of people talking to your bot and this will be directly exposed to the integration available from these platforms. If you use a chat bot, you will have the capability by these bot frameworks where you can write some scripts or handlers to handle some sort of messages and they will be having adapters to connect to different platforms. Or if it is not there, you can make your adapter to your platform. Like there's no adapter for source labs but we are planning to make it. So like the common ones which is available for all these frameworks are like Jira, Jenkins, GitHub, Confluence, AWS. So these are the ones which is available and you can use your chat bot framework to script and connect with these adapters present. Or you can use bot agnostic libraries like one of the platforms that I, the frameworks that I talked about, Yeti Bot has no language dependency which works on APIs if you want to go with that. So let's talk about how our tests will get affected. If you want to run something, so your test on a chat platform, what will be the architecture like? So if you see the user will see the main, user will come on these channels like Slack channels or IRC or HipChat or GitHub or Jira. They're different people communicating on these chat tools or platforms. Like let's say a developer is saying bug fix is done or a visitor is or like a product owner is saying what is the testing status and QA is saying that I'm running the test. So these are connected to different bots. So these bots are nothing but apps that you can make on the chat tools like Slack or HipChat bot or IRC. So let's say if you're using a Slack or if you're using a HipChat, so you will have different bot for both these chat tools. But your implementation of a test will be same. Like the same test will be running or the same capabilities that you're building will be used there. So the chat framework will communicate with these bots. Chat framework is nothing but that I talked about. They will have some APIs. So whatever capabilities that you're writing, they will be part of the chat framework. Let's say if you want to add a capability to run any test on source labs from a chat bot, so you want to script that into a chat framework. But majority of the times what happens is our testing frameworks, if you want to use any test in our existing test, we would have to expose them as a service. So just like developers share their work and expose their work as a service in form of an APIs. So how many of the testers, how many of you have written test which is exposed as an API or a service? Yeah, so if you have a test which is exposed as a service, that can be directly very easily used by any chat bot. So what will eventually happen is that when a QA is saying that run this some test, it will communicate to the channel. This will be communicated to the Slack bot. A command will go to the chat framework. A handler will be written, which will process this message and it will work the APIs. The APIs will trigger test which are some jobs on the test framework. And to handle this complex like these jobs, you can use some Qs like most of the test that we write, they are for many, many minutes. So you can use some APIs to trigger those jobs. They will be running on some Qs and you can store some logs and the statuses on database. So next time whatever information is there, everything related to test is part of your APIs. And whenever someone is querying through the chat bots, they can also, they will be basically going through your chat framework and APIs. And your test framework is intact. So your test, if let's say if something wrong happens with the chat bot, it does not matter like you can run your test in the current way also. So this is how the flow might look like, the one of the approach might look like. If you feel that you're exposing the tests as a service is complex or difficult, you can use another alternative is that you can use a CI platform. So most of the CI platforms, they have this capability of exposing all their operations as a service already, like Jenkins and Travis and Circle CI. You can run operations on them through an API. They already have public APIs for that. So instead of, let's say if you feel that you have tests, but you don't want to expose them as a service, you can use those CI tools like the green one and the chat framework will connect to those CI tools and will run your tests, which will be indirectly running the test framework, but here you will have limited capabilities because you don't have APIs and you don't have logs and databases. So only some part of the bi-directional communication will be automated, but that's a low hanging fruit to start with and it will give you a good returns initially if you want to start with the chat bot's base testing. So implementation wise, let's say for example, if you want to deliver an API and web test via chat to test a small example voting app and you want to run this, let's say you don't want to change anything on your test and you want to run over CI tool like Jenkins or second is by exposing them as a service and then showing the testing results and later on if anybody wants to know the status, how they can know. So the example and the code it and shared is implement this problem. So I have a example voting app. It has a front end, back end and database. We won't go into detail of this. This is shared on GitHub. It works. It's a pretty old app, but it works. It's a simple voting app and we also have another project which has implemented, which has test implemented for API and web tests. So let's say for the first one, let's say if you want to use a CI tool to invoke your test and run the tests over that. You can see that. So this is the sample app that started and this is the example project. So I'm using the second approach using the CI tool. So every CI tool has already APIs available which are exposed. So this bot will just use those. So I'm just telling Raj to search for Jenkins jobs which matches a regular expression or which matches to an app. It's saying there are two jobs. It will run this job. It will trigger the job from here where book is turned and it shows the link of the tests. This is the API test. The another one, the web test. We have more capabilities exposed by this handler, but I've shown just running part of it. There's a way where we can fetch, like we can do all operations like fetching the status, querying the database. Later on, somebody wants to know the status of the example app now that the two tests have run. And this is in a channel. So this can be a part of the conversation when people are talking together when they're discussing the status. So it says the final testing status is okay, which is what we communicate usually. The second demo is when we are not using a CI tool but we are exposing our tests as an API. So if you want to, if you already have a test, let's say if you have a Cucumber test or a test engine test, a Selenium test, let's say. So what you can do is you can use a simple API framework. Like there are very lightweight frameworks, like if you want to do in Ruby, there is Sinatra, there is Express in Node. You can just write, start writing, start having a database and expose these jobs, testing jobs, like the test suits as a service, put request will be made. And whenever this is called, the message will go send there. A message will be sent to your test and that test will return a link or somewhere. And after that, you can show the results of that. So we are using, like in the demo, I'm using a HIP test, which is another testing platform which exposes this capability, but you can run the same test on let's say Browstack on SourceLab or you can do, you can have your own customized setup where you can run your tests as a service separately. So the YouTube, the videos are also on YouTube. So there was a scenario made on HIP tests and I'm running the test demo, which we'll call the service. The message will be going through RabbitMQ and it returns the live status of where the test is running. It has only one scenario. Earlier, the status was not run. Now there is a run and you can check the result latest, which, yeah. And when you query the next time, it will show the result page of the latest test run, which happened here, yeah. And you got the webhook which returns, final testing is okay. So if you are implementing API, there is a way to add webhook also so that the bi-directional communication through your app will become more rich and powerful. So in scenarios like where you want to invoke a test or you want to run a build pipeline, so there may be a possibility that you want to retry or you want to do some other operation where you want to take input from the one step to another one. That time you may need a webhook support. All this API and webhook support will be extending your test project. It won't affect your test, like you can continue to still run those tests as a job like you previously were doing or currently you were doing. So as I mentioned, I have used Litabs. It's a chat framework. So if you want to, let's say, if the code is there, so if you want to extend the capability in the chatbot so that you want to run the tests on source labs, you need to configure the APIs. You need to extend the handler. So every chat box frameworks mostly works on, they have two, three components. One is adapter which connects to different platforms and extends the capability. And they're handlers for these different platforms. And what the user does it, it sends messages. So in the handler, you are just extending the capability of your bot. And when you are actually, what kind of messages you want to deal with or interact with, that you can write separately as a part of your bot. And these capabilities can go as a, they can be published as separate plugin. So there are a lot of plugins available for Lita and Hubot. Like I think for Hubot, there are like hundreds and hundreds of plugins available for Lita also, it's close to 100. What's interesting is that most of these plugins, they are very much related to ops works, like later deployments related to monitoring, but none of them are related to testing directly. Like there is no plugin for APM. Like we can create it definitely, but there's no plugin available for this because it's not used in that way that much. So once, so we can create plugins in this way. And once the plugins are available and they are published, they can be imported in your chat implementation, and you can handle the messages the way you want to handle them in your implementation. So in the beginning, we mentioned about some problems that we had in communication and how ops is ahead of QA in camps. So in terms of visibility, yes, definitely it solves visibility. It makes things visible. In terms of culture, it is possible that running tests as a chat will solve some of the problems. Automation, yes, definitely it's improving the automation. Measurement in terms, there are a lot of things that you want to keep measuring let's say test coverage and other things. These things are measured, these can be measured on pull request basis also or on emails also. But you know the effect of this, if it's available as service and it's available as a conversation, like let's say you are having conversation and you are asking someone that, okay, what's the coverage of this? Then it makes the conversation more meaningful and it makes the measurement available live. Sharing, yes, it makes sharing very useful. One more thing is that, whatever you do on a message platform, it also does a sort of a living documentation, like in our company we are using ticket handling through BOD. So when we are doing through emails and other ticketing platform, we saw that the time taken by people to learn and adjust and understand the capabilities of ticketing capabilities were like it used to take like two weeks or something. But when this was done through a chat platform, they can see like, okay, this is how it is done and this is how they can query and get the information. The, they were able to learn very quickly because it's there every time and it does a live documentation. So if you're running tests on, if anybody in your team can run tests via chat anywhere while sitting in a conference, so that just adds like that just improves the sharing. So from some experience of using it, the best practice is that you should have the cultural acceptance first and technology is the second thing. This is more about sharing and making your work visible. So if you have a problem with making your work visible, then it might not be a good idea. So cultural acceptance needs to go first. Signal to noise is important when you have a lot of tests, lot of things together. So it may happen that when you are using one channel or one group and you're discussing everything there. So it may happen that there is more noise and instead of improving the productivity, it reduces the productivity. So we need to figure out what is the signal to noise ratio for us and figure out a way so that relevant people are there having relevant conversation and these bots adding meaning to this live status and meaning to these conversations. Otherwise, it's going to be way more unproductive. The third is that which is the most helpful is API-driven tests, whatever test or whatever things you have as a test, you start exposing that as a service so that they can be used from anywhere else. Like today, they can be used, they can be run as a job, they can be run as an API from other third parties or they can be run from a chatbot. If you, there are some SAS alternatives also which are paid alternatives. I think VictorOps is one of them. There are a few more also. If you want to explore, you can explore that. But definitely, if you want to start with, with this example, you can just start with open source and see how it works. What will be our next is, there are some challenges that I see is the adoption of testing as a chat is very low or almost negligible. Whenever we are like people are doing it, it's not that mature. Like we have very less plug-in available open source for testing purpose. So I would like to see this growing more in future. Maybe next year when I come, we have a lot of other people doing this. The tool support is also not very much because people are not doing it. Signal to noise is one of the thing that is very relevant. Like a lot of people, we need to have, we need to give options so that people can configure how they can deal with the messages. Like I know Slack does that very good job, but we need to have this capability with our chatbots also. Security is one concern that people ask me randomly is that the authorization built within your chatbot platform so that it should not happen that somebody, somebody cracks a production joke and it deploys in production. So another thing is exposing test to a service is also a challenge because the kind of tests we are doing, like we do voice testing and other stuff, exposing them all their service might be difficult, but it is possible. So that's also one challenge. So that's the future challenges that we'll be facing and we'll work over it. Yeah, so that's it. The examples are on GitHub and the API docs are also available. Yeah, that's it. Thanks Irfan, we have any questions? Hey, it was a nice session. So I just have a few questions here. So one is like, how would you put your chat framework online? Like how would you make your chatbot online all the time? Are you taking care of it in Slack? The next one is in Slack. If you have created apps to it, so people may delete it. So how would you maintain that? So when you delete it, you have to create an app. Have you automated it or are you taking care of it? Yeah, so for the first question is about availability. So the availability of chatbot apps is not different from availability of any other apps. Let's say you are deploying a service, any API or something, it's same as that. So your chatbot is, let's say for example, of this Lita and Hubot, you can just start those services as a demon and run those over a demon service like Supervisor or and they will be there, they won't get killed. And it's the best practice is that to have those, to treat those your chatbot as a production service and not just for testing purpose. For the second question, it's more of administrative thing like if your organization doesn't have this, like if everyone has access to do everything with the chat platform. So in that case, because there is a restriction from the, if you see Slack or if you see a hip chat, they have different ways of dealing with how apps are added to the platform. So if everybody has access to that, then definitely it can be a problem. So that needs to be solved in an administrative way so that not everyone has access to that. Or the one way is that what we do is that when the bot comes up, it sends a trigger to a channel and when it gets killed, it sends a trigger. So that can actually remind us that. Okay, generally, usually the work spaces in Slack, most of the people have access to add and access to delete the ads. So I was just curious, like, have you automated that kind of thing where you create the apps directly if it is deleted? Okay. So I have one more thing. Let's say, suppose, whatever test services, all those things, it's not in same domain. So does the chatbot actually contact the one which are in different domains? So are you taking care of it? I didn't get the question, like, what is different domains? So your chat framework, whatever it is there, it is in some domain. Let's say, suppose, when I say in the domain, like on the same network. Okay. So your chat framework is on some network and your test scripts are in a different network. So does your chat framework take care of it? Like the access, I know the access key and everything, but can it talk to the one which is in a different domain, different network? So they need your tests and your chat tools. They may not, you don't need them to be in same network. Like, you can run a test on an APM which is running on source labs, which is on different network. What you need is a connectivity between these, the APIs which are exposed and your tool that you're using. That's it, that's the only one. So basically, if you have the APIs available in the same network, they can send the message and this can be triggered to run tests on different network. But ideally, I believe they should be having connectivity. Some connectivity is required to send the message. But it's not that simple as we think because it's method... Okay, so is there a VPN? Yes, you have to create that. Okay, so I've not faced that part of problem. Not at all. I was curious because I was working on that, so I was figuring it out how to do it. Okay. I have one last question. I kind of have the same question that my Jenkins servers, where I've actually put in my automation code, to run that particular automation code, I need to connect it to a VPN. So how does we actually tackle that using this Slack? Because let's say if I'm trying to build my particular automation code through Slack and if the code which is put in another server, I mean to manually run it, I need to connect to the VPN. But through Slack, how would we do that? Or have you done that previously or something? No, so I have not done it. But the solution needs to be... If it is automatable via VPN, then it can be possible. Otherwise, I'm not done. Yeah, and another question. To run a particular build, I need to have the access. So I first basically log in into that particular Jenkins and then I run that particular build. But through Slack, I don't see anything, any authorization key that you pass into the code or to the Slack. So how would we do that? I mean, let's say if everyone has the access, then it's fine. I mean, anyone can actually run that particular build. But let's say if it needs any authorization, then how would we tackle that? Yes, so I'll just divide in two parts. One is the authentication problem. So authentication is built into the, your chat framework itself. So a chat framework like Hubot or Lita, what they do is they give a, like you have a configuration file where you can mention all these things. So with that, you don't need to give passwords from Slack, like from the chat tool, but that is a part of the configuration. That solves the authentication part. Regarding authorization, that you have to support within your chatbot itself. So let's say there are like, if the request is coming from a user, he needs to be authenticated first. Just like in first example, the chatbot needs to be invited into the channel first. Similarly, the user needs to be authenticated first and then it can do operation. So that support needs to be given from your chatbot capability. First, the person should be on that particular group. That is authentication. And then you get authorization that to run that particular build. So Hubot has support for authorization also. In Lita, I think, Lita also has, so basically there is a way so that the first time you're doing some operation, you need to authorize yourself. There is a way for 2FA also that it sends SMS to your, so that nobody just does any production deployment by mistake or something else. Okay, okay, great. And I think to add to his first question, if you have access to chatbot and the chatbot internally has access to all your private networks, then you can trigger your builds using that. So it's a two step communication. Yeah, so the chatbot, if it has access to that server, you may or may not be connected to that. So it's one to two, two to three. Am I right Irfan? Yeah, yeah. Yes. Yeah, so thanks a lot everyone. Thanks Irfan for like expanding the applications of chatbot.