 Hello everyone, I am Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So today we are having day number 87 of this Salesforce Learning Bootcamp. And from today onwards, like this week and next two weeks, you are going to learn about Salesforce QA. And for the same, I have Irwin with me. So welcome Irwin on the platform. And Irwin will introduce himself first to you so that you get to know who is your instructor for next five to six sessions. So Irwin is basically working as a Salesforce QA and he will be sharing his knowledge. So over to you Irwin, please introduce yourself to the community. Thanks, Sanjay. Thanks so much. So hello everyone. I am Irwin. I am someone who belongs to a one tech background for the starters. So it hit me back in 2020 that, you know, the passionation for the technology world chimed in. And I started witnessing people working on Salesforce. And that's when I actually got intrigued and wanted to learn about it. So as you can see that I am someone who is a Salesforce QA certified illustrator, a defense podcaster certified nutritionist and a personal fitness trainer. The professional journey started back with the fitness feed. Where I started as a nutritionist, then I got certified as a person for this training. And then eventually I got introduced to Salesforce in 2020. And that's when I got to know about the CR platform, which was quite intriguing. And eventually I got my hands dirty. And recently I've also launched my own podcast, which is a military podcast that goes by the impression docs. And yeah, that's all about me. Okay. Thank you Irwin for letting people know about you. And I am happy to say like Irwin switch from non technical background to technical background. And as you can see, he's having one plus years of experience and like you can search Irwin's name on LinkedIn and you will, you will be able to follow him on LinkedIn as well. Just verify whatever is written here, you will find it as true. And like he's working on like lots of projects as a QA. So whatever he has learned from those projects. So he will be sharing that knowledge with you so that as a beginner, if you want to think as a QA, so you will be able to understand those terminologies. Right. So moving forward, I just want to give you an insight like how our upcoming weeks will look like. So in next slide, I think you will be able to see. So even okay, before that, like if you have any doubt, any question you want to ask. So this is a telegram community where lots of more than I think 3000 folks are connected. They're interacting with each other sharing their experiences knowledge. So all 3000 folks are bigger. Those are maybe associated with any organization or searching for a job. So if you're a beginner, you can become part of that community. So even please next slide. So I think, yeah, in this slide, you can see in last two weeks, we have done LWC deployment. This week we are going to have two sessions on QA. Next week also two sessions on QA. Then again, next week, we'll be having two sessions on QA. And good news is like after completion of all the QA sessions, Irwin will be sharing his own professional journey with you. Like how he managed to become QA Salesforce QA export or consultant being associated as non technical background. So I requested Irwin like, please share your insight in one of the sessions. He decided like, let's have some knowledge sharing session first so that you will be having enough confidence and Irwin like really he has lots of knowledge. So in first five sessions, he will be sharing that knowledge. And then at last he will let you know like how you if you are belonging to non technical background and how you can jump to Salesforce ecosystem and can become a Salesforce QA or you can also switch to any other roles. There are lots of rules available. And after those sessions, we'll be having mock interview sessions where I will become the beginner, right? I have lots of experience, but I will become a beginner and I will let you know how you can crack interviews, how to answer difficult questions in interview, how to relate your simple project works that you have done in internships or training, right? So those kind of sessions I will be doing. So this is our upcoming timeline. And in next slides, like if you have not followed Sanjay Gupta Tech School, so just follow it on YouTube, LinkedIn, Instagram, Telegram and all the important links are available in videos description. So next slide please. And in next slide, you can see feedbacks and reviews are very much important. So I think for tech people, Irwin is doing it for the first time with this big community. Although he's already having his YouTube channel doing some podcasts, but if I'm not wrong like Irwin is doing it for the first time for tech folks sharing his technical knowledge related to Salesforce QA. So please share reviews feedback so that I can share those with Irwin and he can also get motivated like whatever he's doing for community. It is benefiting people, right? So with this note, I hand over a mic to Irwin and now Irwin will explain what QA is and whatever questions you are having, just type that question in the chat. And at the end of the session, it will gonna take all those questions and will be answering each and every question to you, right? So over to you Irwin, please go ahead with the session. Thanks Sanjay. Thank you. Okay, so introduction to quality analysis role. You know, before we actually dig in, I would like to say something like, you know, in our day to day life, we do have a habit that, you know, if someone is not doing right, we tend to correct them. Like, you know, buddy, don't do it like this. Do it like that. It's not the right way of doing it. You might not achieve what you're trying to achieve in that manner, right? Over there, we can say that we have like unofficial QAs of a life, right? And of others lives as well. But over here, as you know, we actually talking about the official, you know, a role, a persona that we play in our companies while being a QA. The most important part is that QA and testing is the most significant phase of the software development cycle, right? Because it helps us determine the product's quality. Also the fact that when we hand over the product to our customers during the UAT phase and post that, the customer should receive the functionality as they expected based on their requirement. In other words, if I say our actuals that should always be at par with their expectations, which also means that whatever they have requested us through their requirements, we should have developed that without having any sort of errors that, you know, goes beyond our ground boundaries to theirs. And before the sign off, everything works properly. When I say everything works properly, I would also like to mention being a QA, you just cannot cover each and everything. When I say you just cannot cover each and everything, I also mean there are n number of factors. Of course, we have to cover the highly important ones, the what we call it as a big functionality, right? The related functionality so that our main functionality does not break. But there are some subtle factors sometimes which get mixed, which is absolutely fine. Coming to the fact that, you know, when I said that our product's actual result should be at par with the expected result. Expected result is basically the requirement that we have received in articles, right? All I mean is that suppose let's take an example. We have got a requirement that let's have a candidate object where we have the minimum pay, maximum pay, and a few more fees like let's say email is our name and address. Where we do have a consideration to consider that the minimum pay should not be greater than the maximum pay. So over here, our main aim is to make sure that the minimum pay's value is, if at all is greater than the maximum pay, then a validation or an error message gets hit and the user should be prompted there and then itself. That's where we are actually stopping the user from having that kind of a value populated. And that's where our actual result is actually being at par with the expected result, which is the requirement of our customer. Also, you know, there's a fact that, you know, that broken product or we can say that even non-working or partially working product is not actually delivered to the customer. They are raised scenarios where we actually deliver something which has a minor defect. But in that case, we do have something which is called a conditional sign off. We've covered it ahead for starters for conditional sign off. All I would like to say is that conditional sign off is scenario or a document where, you know, you clearly state that during the phase of security, what thing has not been coming completely corrected is going with the package that has been delivered to the customer. Right? Coming to the next slide. Now as we are talking about Salesforce, right? Salesforce do have sandboxes. So what are sandboxes? Sandboxes, like, you know, we say people have doppelgangers, right? They have some lookalike moving around in the world. So these sandboxes, we can say in a way a copy of our production environment. Production environment is basically the original environment, or you can say the actual environment on which the customer is having their own actual data. Or it can be of their customers, it can be of the students, etc., etc. These four environments helps us throughout the entire journey of the development process. To begin with, we have developer sandbox, then we have developer pro sandbox, then we have partial sandbox, and then we have full copy. Which is more or less like a replica of the production environment. Why I said that it's a replica of the production environment? I'll get that. I'll get to it very soon. For now, let's start with developer. Developer sandbox is, you can say, you know, more or less the basic sandbox or with the most minimal amount of data storage capacity. It is basically for the developers who are working on it, so that they can at least have the metadata copied or made or fields or objects or metadata created over there. Which in a way would help the QA further to test each and everything that developers and figured in his own environment, which is usually the partial environment. So as you can say, read that it's fine data storage is only of 200 MB of file storage and 200 MB of data storage. And what you can copy over there is just the metadata. We cannot have the entire data over there. Now what is the refresh interval? It's just one day. That is, you can refresh it within a gap of one day's time. That's the smallest limit for any sandbox. Moving to the next one, we have developer pro sandbox. The advantage of this is that the storage capacity of this particular sandbox has increased to one GB in both the cases, file storage and data storage. It again helps the developer in order to create the metadata, get that copied over there in a bigger amount. The refresh interval remains the same. That is one day. That is in a gap of one day's time, you can refresh it. Moving on to the next slide, here comes the time where the QA actually changes it. That is the partial sandbox of Salesforce. It has a refresh interval of five days, which means that in five days time, you can actually refresh the sandbox. Data storage, you can see, has increased from one GB to five GB for both file storage and data storage. How that is very much helpful for the QA is because when we test, we make sure that we try to break the functionality. Of course, we work with a constructive mindset, but we work with a destructive approach. We want to entertain the smallest vulnerable point of the functionality that we have. That is only possible if we are able to create as many records as possible. Had it been a developer sandbox, we wouldn't have been able to do that. Therefore, partial sandbox comes into the picture and plays the major role for us to do the needful and make sure that our functionality is working as expected. You can see that what can be copied over here is metadata plus some sample data. Because it has that much storage that can hold both of them in a good quantity. Even if you want, we can create more. Many times it happens that while testing, it's not only about the basic manual testing, where we are just creating records and we are testing them. But it's more or less with regards to doing some bulk testing as well. When we have to upload many records, records in some big numbers. So that we can check that our functionality is working in that case as well or not. There is one question related to sample data. Someone is asking what is sample data, if you can elaborate. So sample data is like our test data, we would say. It's not the actual data for customer. Those aren't the actual records which our customer would be holding for their business. Isn't that what we are creating for our testing purposes? Again, it can be created manually or it can be uploaded to any of the platforms. It's either import wizard or data loader or even Salesforce inspector. So that's where our sample data comes in. And that's what sample data is. Going to the next sandbox, which is full copy. In the beginning I said that full copy is more or less like a replica of the production. The reason is whenever we refresh the full copy sandbox, it gets everything from the production environment, the actual environment of the customer where he or she would be holding each and every record of his business or her business. You can see that the refresh interval has increased to 29 days. We are not refreshing it on a very frequent basis. We do have almost a month's gap so that the data and data basically produced by the customer in there all can be pulled down to the full copy in a good number. Also you see that the storage, there's more option. There's a good option to have either 5GP or even more of storage than that. In here we can have all the data. The person who raised the question for sample data, I'll give you more clarity that you see here that it's meta data versus all data. When I say all data, I mean it's our testing data or sample data and other data. Other data means which is actually brought down from the customer's production. We aren't having to bring the customer's org and the customer's record which he or she is actually holding on for their business. We are just having a copy of that in our full copy sandbox. That also helps for one more aspect. That our data is in a way aligned to their data so that we could get to know what kind of values in the fields they actually feed in and what would they require so that this thing can be more accurate and we can understand their idea of generating values into those fields. Any questions so far for the sandboxes? Are we good? Yeah, I think Irwin will take all the questions together at the end so you can proceed. Okay, so let's move on to the next slide. Okay, so before we begin with regards to what exactly QA is, what exactly QA practices are, let me just show a situation in front of you. We have a number, a range of number between 1,000 to 100,000. And the QA needs to actually test that you know all the number fall between the range of the accepted range mentioned above in the fields, right? When I say this, I'm actually talking about the number of all the sizes. All the sizes or we can say of all place values between the shared range. So the question for you people is how will you approach this? I'm not literally asking you to answer that right away. We'll take it later on works. It's just a question, walk on it, think the best possible way out. Like what would you do being a QA, right? Because moving forward, we are going to learn about some good QA testing techniques as well. And that might help you figure out. But we would need the answer, you know, before that. Help you align it and you're being synced with the testing techniques a little more, right? Okay, so we go to this moving on to the next slide. Let's talk about tech case design techniques, right? So my very first question to you is like, you know, you must have heard about test cases, right? So what are those test cases? I'm not digging in deep right now because we have a separate section for test cases and everything, but just to be a little specific in a brief context, I would say test case is a collection of steps of actually executing the functionality that has been developed based on the requirement, right? So then what is basically a test case design technique? Test case design technique is basically, you know, the aspect of functionality, right? Which can be covered through various approaches, right? With a similar end result. In other words, our aim is to achieve the same end result, but we try that out, try stretching that out with different kind of QA test case design techniques. So that we have a larger test case coverage. By test case coverage, I mean testing the functionality from most possible ends and aspects, right? And every single, you know, individual technique is good in terms of finding a particular defect, right? And in a particular way, you'll get this small manual actually deep dive in the test case design techniques. And this will also help you understand the scenario which I have shared before jumping on to this slide. Moving on to the next slide, this is black box testing. It's a kind of testing and a testing technique. So over here, when we do black box testing, it is more or less with regards to the fact that we are just considered and very much concerned about the outcome of the functionality. We aren't concerned about what the code is, how the code is written or how well the code is written, right? But we are only concerned about the fact that we are getting the desired output. For instance, let's say, you know, you're logging into Instagram, okay? You enter your username, enter your password, you click the login button. What is the desired output? It is that we are actually logged in and we go on to our feet. All we are concerned about during black box testing is that we are actually in. We are not concerned what's going in the back end, you know, how the code is running or how the code is actually written. But we are just concerned that yes, we are successfully logged in. We are on the feet and we can go ahead and do a good scrolling over there. Similarly, if I talk about Salesforce, let's say we have an action button that says create a candidate from a position, right? So that over here, our desired end result would be that a new dialog window emerges that is either named like, you know, say new candidate or new candidate record. We fill the entire fields with the required information. When we click save, a new record should be populated. That's what black box testing is all about. Now comes the part where we talk about white box testing. White box testing, this is the time or this is the testing technique where we are actually concerned about the code. When I say we are concerned about the code, we are actually talking about the fact that was internal structure design of the code that has been written down. By our dear developers, we are talking about, you know, what input is going in and what all it's going through and then how we are getting input. Before taking an example of Salesforce, let's talk about, you know, we, there are many machines, right? So we, let's say we slide a 10, 10 rupee coin and we, you know, get a 10 rupee pack of lays. So over here, in the initial phase, all we are more or less concerned about the fact that we should be up. The lays, the packet of lays should be there in a hand once we drop down the coin in the machine. But if you are white box testing it, we'll be more or less concerned, you know, we have slide it down the coin. How is it going there? What if it is triggering that our lays packet is coming out in the bucket below that we are able to pick it up from there? That's where white box testing comes in. Also the fact now that if I talk about that, you know, let's say we are working on Salesforce. We are more or less like, you know, we are trying, we are creating a candidate record and from a position. And over there we have a contact related as well, which is of hiring manager. So when we have created a candidate record, we did not have any look up fee for the hiring manager, any kind of contact. But when the record is created, we have that contact record populated in the field hiring manager for that candidate. So how come did that happen? That's where we do white box testing. We'll be very much concerned about the flow that okay. In the first step, it was given a command that this record is created from this very position record. Candidate record is created from position record on this position record. This was the contact record of that very hiring manager. And that hiring manager record should be picked up onto the candidate record basis. The fact that we look up is populated. So we have considered about each and every single step that is going in that code. Also, in many cases, that is the case that we are concerned about the fact that the code should be well written. Even in that case, white box testing comes in for today, like I would say that this should be enough because let's just process it first. There will be a set of testing techniques with some kind of good examples and then we can try to dig into more practical sessions. Yeah. So with this note, like even we have a few questions in the chat. So it would be better if we can go through them one by one. So there is one question that I also want to understand. Like there is two terminologies, one is QA and one is testing. So both are similar or somewhere different. Okay. A very interesting question and thank you so much for who served as this. When you talk about QA, QA is more or less like quality analysis, right? Or the process is called as quality analysis. Over here, we are making sure of the fact that while the functionality is being developed and it's in the early stages of the software development, we make sure that we are detecting the defects. We are suggesting the best possible way of having the things well up. And so that in the later phase, we aren't actually experiencing or, you know, getting a big number of defects at that time, because everything is sorted in the earlier phase itself. So that the functionality does not break at that time while it's there in the testing phase. Talking about testing, testing is more or less a practice wherein we are actually executing the functionality on IM to test out and find that whether the actual result is at the power that they expect result and logging the defects or bugs as and when required. That's where the difference comes in. Yeah. So I hope with this difference, people are able to kind of understand the difference because I think testing is more doing some hands-on work, whatever we have developed, right? And the outcome of that testing process, if we do some analysis, then comes QA in picture, right? Yes. And maybe in some of the cases, one people might be doing both the things, right? It might be possible. Exactly. In the initial phase, yes, it is possible. So it happens when the functionality is great and it is being well up in chunks and we prefer to prevent the defects from coming in the earlier future. Right. One more question is there like, what do you mean by positive and negative scenarios? Like if you are testing something that is built, so with the help of an example, if you can elaborate what is positive testing and what is negative testing? So as the name suggests, right, just for in the layman terms, if I say positive testing is just, you know, inputting the kind of a value which is expected to be put in the field. And negative value is more or less a value which is not expected, but we would want to know that that value is not at all accepted when the user feeds the field with it. Right? Supposedly an example, let's take an example. We were talking about the fact that, you know, minimum pay should not be paid in the maximum thing. And now what, first we're talking about the positive scenario, right? Positive testing. What we're doing is we are in minimum pay we are saying is $1000 in maximum pay we are saying is $15,000. So that's a positive scenario, a happy flow. Everything works quite well, right? Now comes the point when I say that, okay, let's do one thing. Let's have the minimum pay as $15,000.01, right? And let's have the maximum pay as $15,000. Over here what we're doing is we are just increasing the minimum pay, right? We are trying to figure out that whether it's going to work or not. So in that case, it should actually hit at the validation rule error that the minimum pay cannot be greater than the maximum pay. Also the fact, let me give you one more example. Let's say we are logging into a website, right? Or any kind of an account. We know that, you know, for logging in successfully, we need both password and the username to be fed into the fields, right? So supposedly we just fill in the password, we don't fill in the username and we just hit login. It should not let us log in. We should have different scenarios as well where the user name is there but there is no password. Or they are incomplete values in either of the two fields. Right. Yeah. So I hope Ranjit asked this question basically. So I hope your question is answered. One more interesting question is there like, if I'm good in Salesforce admin, so how to become good in Salesforce QA? So any tips, those who are working as an admin, so will they be able to switch to Salesforce QA or what? Okay. If you're an admin, then that means you hold a real good grip on the Salesforce functionality, right? And a QA who is working either on Salesforce or on any other platform should know that very particular product or the software. Like you can say that, you know, as good as the person knows the back of their hand. Right. So you be the admin, it's very easy for you to become a QA. All you need to do is you have to learn the QA process, understand it basically and understand why QA, the importance of QA and be a little more creative when you're doing the functionality. Because as I said in the beginning, you know, we are working in a constructive approach but with a destructive mindset. You have to cover as much as possible as much as vulnerable aspects of the functionality, happy flows, edge cases so that we can check more and more aspects of that functionality. So all you need to do is practice the QA process, understand it, the significance of it. That's it. You're on good with the source of functionality. Yeah, I think this makes sense and Deepak asked this question. So I hope Deepak, you have answer now. And Jai is asking, we use any tool in Salesforce testing? So without any tool, we do testing. Okay. So if it's about manual testing, I would like to mention that, you know, when you're doing manual testing, you're more or less doing the functional kind of a testing that you would just want to consider, concerned about that the functionality is working quite well based on the requirement. All you do is you create records, you execute the functionality and you check the output or the end result, as we said. Talking about the fact that if you're actually asking me about the tools which are with regards to, you know, maintaining the test cases or, you know, updating the Gira tickets or any kind of tickets where we are actually maintaining our records or data around our functionalities which are being tested. And that is their various tools. Let's say there's Gira, there's test rate for test cases. But if you're only talking about execution and testing, then it's just you. I would say that, you know, as we say that we are the weapon, right? So in that case, you are the weapon. You are firing it up over there in the software and you are getting the end result. Okay, so one more thing, who is responsible for white box testing, tester or developer? Okay, so if you talk about white box testing, the testers do that, right? Because in most cases, there is a requirement that, you know, customers ask that the developers code should be reviewed before being tested. Okay, so one more question like which sandbox is used by QA? Is it partial copy sandbox or anything else or like all can be used? Okay, so QA is generally work on partial copies because they get a bigger, you know, data storage capacity where they can either bulk upload records, they can create as many records as they want so that they can test a functionality in a proper manner. QA has also worked on full copy environments, but that's when the case where they're actually hitting a regression suite. Once everything has been approved by the QA and the partial copy, things get deployed in the full copy. The testing is done in order to make sure that everything is working as it was in the partial copy. There are scenarios when the testing on a very lighter note is done in the production environment as well. Production environment, which is the environment of the customer, the actual or the original environment. In that case, the QA does testing, creates some records, notifies the customer or the project manager and then in most cases, the records are deleted post testing. So Suresh is asking with certificate required for QA, so is there any certificate that Salesforce offers for QA? No. Unfortunately, in Salesforce, you won't get any certificate, but if you actually want to become a certified QA, I would recommend do ISTQB certification. Yeah, ISTQB, that is for testing. So it is not related to Salesforce, it is related to QA role. The QA practice. Right, QA practice, exactly. Manu is asking, is there any automation in Salesforce testing, like manual as well as automation or we do manual testing only? No, there is automation testing as well. It depends upon the need and sometimes even the customers ask for the automation part. Right, and in continuation with this question, Sangeeta is asking, what's the most automation tool used for Salesforce testing? Okay, you know, it's more or less, I would say the testers choice. Okay, because after it requires language and every tester or every being cannot have a good commander each and every technical language. So most preferred combination is usually, you know, Selenium plus Java, that's what people pick up the most. Yeah, or it's Python plus Selenium, of course. Right. So Sangeeta is also adding in her question, like is there more vacancies for Salesforce QA now? So who? With time, yes, things are going better and Salesforce QA is also being interviewed. Right, and Sangeeta is asking, who is responsible for demo to the client QA or developer? Okay, a very good question. Like, honestly speaking, Sangeeta, for this question, when you're demoing the client, it's actually the QA response. The reason being, he has tested it out in a way that every single vulnerability of the functionality is the sender. Right. Of course, the happy parts are tested, but vulnerabilities play a major role. So the QA can actually, at that moment, you know, explain better, help them out with the what's the edge case, what can actually break their functionality and actually, you know, get them at a halt while leveraging whatever they have got to a lot. Yeah, exactly. And I think in real-time scenarios, when we work on the project, so we do not have one QA for one developer. Instead, like for three, four developers, or maybe two to three developers, we have one dedicated QA. So like developers develop one requirement, right? So let's say we have two weeks of sprint. So three, four developers are developing different, different pieces. And one QA is basically testing whole functionality end to end. So in that case, like you is having more insight, more broader picture as compared to developers. So QA is the best resource who can go and showcase whatever is being developed throughout that particular sprint. And hello, Irvin, am I audible? Yes, now you are. Yeah, actually there is power cut. So Internet disconnected and I don't, I'm not sure people are able to see the screen. So can you please confirm? Yeah, I think yes. And I am in like in dark room. So okay. So I just want, yeah, I was just explaining about QA thing. So one thing I want to add here, like if you are a good QA, so in that case, like there is one more role opportunity for you guys. QA becomes very good business analyst. Right. So they have end to end understanding of the project. So we have one more role in Salesforce that is business analyst. So if you're a good QA, so you will be like becoming a good business analyst as well and maybe in future project manager. Okay, so just would like to add one thing to what Sanjay said, you know, as the QA holds that end to a knowledge of functionality of the entire project. When the QA test, the QA is actually testing with the mindset of being the end user of that product. So that also helps, you know, in covering each and every aspect of it and thinking like the end user or the customer for whom we are actually developing the entire thing. Right. So Deepak, I already answered how to become a business analyst. So you just need you, you have two ways to become business business analyst. So if you if you have like some experience, I would say like if you have some experience working as a developer, then you can become a QA or if you sorry, then you can become a BA or if you have QA experience, then also you can become a BA. So it depends on your interest, but I would prefer like if you have a QA, then you will become a good BA. Because QA has end to end knowledge is respective to developers. Right. Yeah. So there is one more question. What is the difference between Salesforce BA and consultant? So Praveen basically consultants are those who has complete knowledge of particular cloud. So you might have heard about sales cloud consultant service cloud consultant. So consultant means who can consult about a product. Right. And Salesforce BA is like business analyst, the person who knows about the product and dealing with the client gathering the requirement. But consultant who can provide solutioning as well who can provide some suggestions as well. So you can say like if you are a consultant, so you can work as a BA. But if you are a BA, then it is not sure like you will be able to work as a consultant because consultant means, you know, a lot of things. You, you, you know, development stuff, QA stuff, BA stuff, you know, architect stuff, you know cloud stuff. So that is basically a consultant thing. So I think even we have covered all the questions which are available in the chat and yeah, so we can wrap the session here only. So thank you so much guys for joining this session live and I know lots of people will be watching this session as a recorded video as well. So thank you for joining it live and if you're watching recording, so thank you. Thanks to you as well and use thanks to Irwin for delivering whole insight related to QA and I know this is just a beginning and you will be delivering four more sessions in future. So that will be covering all the aspects of QA and very less platforms are having QA related stuff. Right. So I'm thankful to Irwin like he accepted my offer like to come on this platform and to deliver his knowledge. So I'm grateful enough like he's there and sharing his knowledge with the community. It's an immense honor to be on such a platform and sharing your space with you. Just for the viewers, a real quick word. So me coming into the technical world holding a grip onto the sales force. It goes to Sunday. Like I have been mentored by him. I've learned everything by him from him. So thanks to him and yeah, that is something you know, which is the kicking force behind me. I think we'll cover lots of things about it in in our last session. So I will reveal like we have like four to five years of bond like we know each other from last four to five years. And I saw like how Irwin worked as non technical workforce and then I saw and I was part of that transition from non technical like as a people who is working. In non technical area and converted into technical stream that twin sales force. So we'll we'll discuss this in detail. And I think Irwin story will inspire lots of folks who are learning sales force being a non technical guy and like never never lose hope because even tried tried a lot and prepared a lot. So he will be sharing all the insight with you. So maybe like after 15th of August that session will gonna happen. So you can ask any kind of questions related to that. So so I won't be telling much right now because if we discuss lot here so that that session won't be having much content. So we'll be waiting for that. So right now I can just thank you. And thank you Irwin. And let's connect tomorrow same time and lot more things will be sharing with the community. Okay. Okay. Thank you everyone. Thank you Irwin. See you tomorrow. Thank you so much. Bye. Thank you.