 Hello everyone. I am Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So today we are having day 90 of this Salesforce Learning Bootcamp. And if I talk about Salesforce QA, so this is part four. And till now you have learned lots of concepts related to QA. So today Irwin will tell you how you can just create test cases and what test cases are. So I have Irwin with me for this session. So welcome Irwin on the channel. And I hope you are enjoying sharing your knowledge. And I'm sure like people are enjoying learning from you. And I can see number of views like daily on daily basis, lots of folks are getting benefited with the knowledge that you are sharing. So I appreciate your time. Okay, so with this note, I just want you to please introduce yourself so that if someone new joins the session, so they should know about you. So over to you Irwin. Thanks. So hello everyone. Good evening. And if anyone's who's across the borders or sees, so good morning to them. So I'm Irwin. I am someone who basically hails from a non-think background. And then came a day when I got fascinated by Salesforce after being exposed to it and looking at people working on it. And eventually I chimed in and got my hands dirty on it. Today I'm working as a Salesforce QA engineer in DuPont advisory. Talking about my experience, I am someone who is a certified nutritionist, a personal practitioner. Then I am a defense podcaster. And as I stated earlier, I was Salesforce QA at the moment. With regards to Salesforce QA, I have one plus years of experience with my nutritionist and personal fitness profile. Fitness training profile, I have nine plus years of experience. I recently launched my military podcast that goes by the name, question talks. Besides that, coming on to the technical ground, I am a certified administrator, as well as a pre-led nature. Great. Awesome. So in the next slide, I just want to show you this QR code so that you can join this telegram group. And if you have any kind of doubt, you can ask those doubts in the group. More than 3000 folks are connected. So they are learning and helping each other. And this slide, you can see next week also we'll be having one more session. So today we have part four and next week we'll be having part five. With this note, in the next slide, like if you want to receive all the session reminder, so you can follow Sanjay Gupta Tech School on YouTube, LinkedIn, Instagram, telegram, and all the important links are available in the video description. And please provide some reviews or feedbacks, right? So it will give us motivation. Okay, over to you, Irwin. So please proceed with the session. Thank you, Sanjay. Okay, so guys, today's topic would be test cases. So before we actually dig in, I would like to clarify one thing that when we talk about test cases and when we talk about test scenarios, those are two different concepts. People are tend to confuse between them. They get baffled when they hear test scenarios and post that when they hear test cases. Test scenarios are basically you can say the situations, right, or a particular functionality or a phase of that functionality that is being tested. And test cases, as we can find on the screen, it's basically a set of steps which we perform in order to execute the functionality in order to check whether the actual result is at par with the expected result or not, which also means these steps help us execute the functionality in the correct manner, also to make sure that each and every step is working and is not breaking at any point. Why test case should be there in the entirety of having the QA process being followed for the particular functionality or a set of functionality because of the fact when we are looking at a test case, it gives us a clear view of what particular functionality are we going to test in that particular set of steps in short test case. So the most important characteristic of a test case is to make sure that the test case title is very much describing or very well describing the functionality which is being tested. Let's say if we are just talking about the login screen that if the user populates the correct username and password and hits login button, it should let the user go inside to the mailbox, right? Now the test case, let's say if I talk about the test case title, I would say that verify that the user is able to login into his or her mailbox successfully after feeding the username and password fields with the correct values. So overhead, what has happened is we have clearly stated the functionality which is being tested so that the end user, always consider the end user as someone who is not a technique, who is just a naive, is not at all familiar with the functionalities, not at all good with the technical aspects of the functionality can only perform if diving. So the test cases should be that much elaborated, not lengthy, the steps should not be lengthy enough, they should be short and precise. We touched base that in the further slides. So now I would also like to mention, as it's mentioned, the second point is also great way to cover the maximum use cases of functionality that has been tested, right? In a technical language, we address it as test coverage. Test coverage is nothing but tackling the functionality or testing the functionality from as many aspects and as many grounds as possible. Now coming to the fact that while while we are creating the test cases that what should be the mindset of the user or the basically the person who is creating the test case, who is either a QA or QC, right? As I've stated earlier, the mindset should be always with the fact that our end user is naive. He or she does not know how to use the functionality. We are someone who is the guide for them. We are guiding them with the help of our test steps. Test case style should also be good enough in exactly explaining of what is being tested. It should hold the steps and the steps should be mentioned in a systematic manner to have the desired outcome received of the functionality which is executed. Before I touch base the test case components, I would like to show you something with regards to the fact that, you know, just a second, let me just quickly share my screen. Let's say, supposedly I log into my org and we are in the org. Our main aim would be while testing a functionality that we have the clear instructions on what we have to do, right? As of now, what we'll be doing is we'll be creating a test case title, just a title. I'm not moving on with prerequisites, test steps or test results, right? Our very first title is I'm taking a real scenario right now, wherein we are taking a candidate object and making sure that the minimum pay is not greater than the maximum pay. In that case, we have to be very specific of what is being tested in a test case title. Let's say we'll be writing it down as verify that the minimum pay is not greater. Then the maximum pay on candidate layout. This is one of the ways wherein we can write it up. The second way can be verify that the user is not able to save the candidate record when the value of minimum pay is greater. Irwin, can we zoom in? Sure, sure. I hope it's good. A little bit more. Yes, now it is. Okay. So, talking about the second one, now we are writing it as verify that the user is not able to save the candidate record when the value of minimum pay is greater than the value of maximum pay. What are intent? Intent remains the same that any user should be able to understand what we are trying to test for. If you see in both the scenarios, we have clearly stated that our main aim is to make sure that the minimum pay is not greater than the maximum pay on the candidate layout. Just adding one more point to it, let's say we write it down that at the time of creation, again another two aspects of it, verify that when the user creates a candidate record, I've actually reached the limit, the candidate record with minimum pay is value greater than maximum pay is value the user is not able to save the newly created candidate record. So, again, we have clearly stated that the main intent is to make sure that when this is the case, the user is not able to save the new record. Another scenario comes in when we are just editing it, verify that when the user populates a value in minimum pay in the field rather, in the field minimum pay greater than the value of the field maximum pay, the user is either we can say hit with a snack, which is more or less a completely technical language, or we can say that the user is not able to save the amendments made in the fields. Again, the intent is same, we are checking the same thing that the minimum pay is greater than the value of the field maximum pay. But what we did is, we have framed it in different manners and we made sure that in every single statement, it's clear to our user. We also covered the fact that one, one is a scenario when we are creating a record, two is a scenario where we are actually updating the record, just the values of it, right? So, switching back to our deck and now talking about the test case components. As we read, as we just practiced for test case title, quickly defining it, test case title is nothing but a statement that describes the functionality that is being tested. It can be a smaller functionality, it can be a major functionality, it can also include a functionality where it has a dependency on the other functionality. Like we did yesterday, the moment we marked our test case with that it was in FD and has defect, a defect gets populated, a related defect gets populated. So that's where a dependent functionality is also being covered in the test case title itself, so that the user gets to know what is being tested. Coming to prerequisites, prerequisites are basically the preconditions or the requirements which are a must before executing a functionality. For instance, if I had been talking yesterday about the fact that we should have the status FD or QN progress has defect and if you don't, if you market with this, we have our new defect populated, a related defect populated. So a set of prerequisites would be one, that test cases tab should be available, two, the user should have create permission on this very object, three, that there should be status field on the layout because we aren't getting this particular value in either of the fields. It's only configured for this very particular field status and it's specialist value, FDQ and progress has defect. And at the end, we also, in this particular scenario, we are not talking of the fact that, you know, we are checking the severity, we are checking the priority and we are checking the defect. Thank you. We are just more or less concerned about the fact that whenever we are hitting this value in the field, we are getting our new defect logged with the help of automation. That's where we talk about our prerequisites. So just for a quick reference, let's say the following should be configured before I am again taking the scenario wherein we were talking about the fact that the user is actually checking the functionality of the minimum pay, which cannot be created in the maximum pay. So over here, we would be talking like the first point would be that candidates tab is visible to the user. We can also specify our user that we are going to test it. Let's say, Candidate tab is visible to the system administrator user or if it's a standard user, then to the standard user. The other way of having the same point written could be that just moving it from here, selecting this at the system administrator or standard user holds lead permission for the candidate object. Thus, the second point for us in the prerequisites tab could be that minimum pay and maximum pay fees are present on the candidate layout. What would be, again, this comes in back to the picture, which is system administrator or standard user holds created permission for candidate object. It's very necessary to have these. Otherwise, you won't be able to create a record. If you're just editing the record, you're not creating in another test case. In that case, you can be like that these users should hold a permission. Over here, in technical terms, we say edit permission to that for candidate object. These are our prerequisites. If either of them is missing, we are not able to perform our functionality. The execution would fail right there itself. As prerequisites are more or less the must-haves to be able to test the functionality. Coming to the next one, test case ID. Test case ID is basically a number that we get which gets auto-populated on the tool that we are using. Many people use JIRA. There are people who use Test Rail. There are some people who use Test Case Manager and etc. Just to showcase that to you. Let's say if I just create this test case as of now, so you see that test case number is here. Consider it as that original tool which we are using. It's either Insta or Test Rail or any other tool. If I save it, we'll have this auto-number populated. We do have if we want it. Let's change the status and save it. What has happened? We got this test case number or test case ID populated. That is something which happens in our testing tools as well. Next one is link story, task or sub-task defect or bugs lookup. When we are creating a test case, we usually get an option to create the test case from our ticket itself which is either on JIRA or any other platform. In that case, the lookup is automatically generated on the test case of that particular ticket. If not, we can actually have the number or the ID of the ticket populated manually on the test case and it will be linked to that particular ticket. Now, steps of execution, the most important part. You can say that steps of execution is in a way the background of test case. Test case is the composition of the various steps that we include for executing a particular functionality. Now, navigating back over here, aiding this record so far. Let's say we are testing it with the system administrator user. So, our very first step would be log into, sorry, recruitment or using system administrators credentials. Here, we have been very specific about the fact that we are testing it or we are logging it with the system administrator profile. Next step would be data scenarios where people do mention about their landing page. There are also scenarios where people tend to avoid that. If we are actually performing that, we are considering that we should be like upon logging in, the user lands on the recruitment. Next step would be to navigate to the candidate objects. Navigate to the candidates tab. So, there are few, by the way, there are few specific terminologies which you should leverage. One is navigating. We should not say that now move to that tab. When having the technical tax to it gives it a little more relevance rather than using some casual or some other formal words which are not technical. In the initial phase, when I was talking about test case title, I said verify. I did not say check. I did not say look for. I directly said verify. So, similarly, navigate to candidates tab. Fourth step would be if you are creating the record, it would be click new. Fifth, let us take it as 4.1 wherein if you are editing a record, we would be like open and existing candidate record. Fifth step would be for the fact that we are creating, okay, let me just do one thing. Let us take the existing one later on as it will baffle you people. Once after clicking the new action, we would expect a dialogue window popping up. We should have it have a step like a dialogue window in the name new candidate or whatever window is named as right pops up or you can write emerges or whatever term you could use that would clearly state. The next step could be fill the fields with the required information and in addition to this step, we could mention feed the field minimum pay with a value that is greater than maximum pays value. So, again, we have clearly stated in the step that what we are intentionally going to do is we are popular. We are going to populate a value in the minimum pay field which would be greater than the value in the maximum pays field. Let us say I am saying that it is 1500 rupees for minimum pay and for maximum pay it is just 1000 rupees. So, it clearly stated it is an intention in order to check the functionality should be prompted with an error message for that. Next step should be click save. Right? We have saved it 8th step and the final step by creating a new record would be the user is prompted with an error message and do state the message stating minimum pay cannot be greater than the maximum pay. So, here we are very much clear about the fact that we have listed down all the steps. So, now even if I ask like a random person who is just walking on this platform very first time, he or she would be able to follow these steps and should be able to navigate accordingly. Let us quickly perform this as well. Right? Let us open another window and let us login. First we are talking about the fact that we are logging into the org. We said that which is clearly stated that log into the recruitment org using system administrators profile. Okay? Let us take this people.com. So, now that we are in I mean has just asked me for the authentication and we are in. So, as I stated initially the second step is completely optional. Right? It also depends upon the fact what the configuration has been made to. Right? As of now in this org there is no such configuration that we are actually landing onto the recruitment app. So, if I move here and I click recruitment, I have navigated to the recruitment app. Again, I navigate it. I did not move to the recruitment app or I need a switch to it. I navigate it. Okay? Now next would be navigate to candidate staff. We have the candidate staff over here. Here we go. Next step is clicking new. When we click new, our expectation is that a dialog window pops up with the new candidate or whatever the name is. So, here it is new candidate. Moving on to the next one, fill the fields with the required information and make sure that the minimum base value is the maximum base value. So, okay my bad. I have actually logged into the wrong log where I don't have this field as of now existing. Right? So, if I still show you the fact that you know how we are moving ahead with it. Right? No problem. I think if it is not required we can skip that particular field. Yeah. So, our main intent would be filling the fields with the required information, having the value populated in both of them and clicking save. And when we are clicking save, right, we should be getting a validation error stating that the minimum pay cannot be greater than the maximum pay. Right? And so here our entire set of steps have been performed. Things have been executed and our test case gets completed. Yeah. Now, coming to the point where we have our next point, which is expected result. So, now what is an expected result? As we talked earlier, expected result is basically the end result or the desired outcome, which we consider basis or requirement received by the customer. So, quickly moving over here, not taking much of the time, right? And let's copy this one up. And the first step is log into recruitment org using system administrator's potential. Right? We can frame it as system administrator user should be able to log into recruitment org. This is the first step. The second step would say is that upon logging in, the user lands onto the recruitment app. In this, we can reframe it as upon logging in, the user should land on the recruitment app. So, what we are stating away is we are stating the desired possibility of the outcome. Moving to the next one, we should be like, the user should be able to navigate, right? To candidate staff. Next one is click new. Indeed, you know, when we'll be clicking new, we know that we are able to click new, right? But the user should know that the user should be able to click new. And then the next one is that the dialogue window either emerges or pops up. We can be like the dialogue window in the name new candidate should pop up or emerge. Next one is fill the fields with the required information. Again, the thing that comes up is that the user should be fill the fields with the required information. In overhead, we don't have to actually change it, but instead we can be like, we can have them in brackets and here's the same statement stating that the minimum base value should be greater than the maximum base value. Last one is click save. Instead of having the user should be able to click save, we should have it like the user should be able to save the newly created candidate record. The last one is the user is prompted with an error message stating minimum pay cannot be weighted in the maximum pay. We can just rephrase it by saying that the user should be prompted with an error message stating minimum pay cannot be given in the maximum pay. So in our steps, we just clearly stated what we are going to do. In our expected result, we share the expectation of a desired outcome. Coming to the test result. In test result, which is over here, which is also our actual result, we are going to make sure that we are posting about the fact that what has actually happened. So it would be like system user was able to log into the recruitment app. Upon logging in, the user landed on the recruitment app. The user was able, again, to navigate to the candidate step and the user was able to click new, a dialogue window popped up or immersed. The user was able to click. What is the label of this field? Just a little bit scroll. Yeah. Now it is a test result. So the label of the field is test results. The user was able to fill the fields with the required information where in our expected result, what you mentioned was the user should be able to fill the fields with the required information. Now this remains the same. Moving on to the next one, which is the user should be able to save the newly created record. It will be clearly that the user was able. The last point is the user should be prompted with an error message. It will be refamed to the user was prompted with an error message stating minimum pay cannot be greater than the maximum. So over here, we have touched based all the test case companies and that's how they're important for us while testing and especially at the time of UAT, we do give some kind of test delivery, deliverables, right? Sorry for that or slip us down. And in the next session, we'll be talking about them. So even in my example over here, I have actually talked about this scenario where the minimum pay cannot be greater than the maximum pay. If I move ahead a bit, you would see that there is prerequisites. We are talking about the position tab as well, right? We're talking about the validation as well, which is minimum pay cannot be greater than the maximum pay. The test ID as I stated is a system-generated ID. We can like in Salesforce, we have auto number, we have text as a data type. So for system, for the auto number, it's getting populated like C-double-double-one. And the story number or ID again gets populated automatically in some of the tools which we leverage or in some cases, it's like we have to populate it manually. Coming to the next one, as we discussed about the fact, we have these steps of execution. We have steps we have expected results. These are those same steps which you have followed. There's nothing different in that. And so are the expected result. Coming to the next one, so this is the final thing as of now. But before we wrap it up, I would like to mention one more thing that when we are talking about logging defects, when we are talking about logging bugs, we again have to make sure that we have some defect titles or the bug titles clearly stated. If I navigate to the new, click the new action again, it should let's say the user was able to save the record and when the minimum base value was greater than the maximum base value. So here I have to be very much specific around what the error is. If I'll be quite unclear, my developer would not be able to get that and the defect would not be solved. So let's be very clear and be quick on this. Let's write it as the user was able to save the candidate record even when the minimum base value was greater than maximum base value. So it clearly states that our requirement was that this should not happen in the case, but it is the case. Talking about priority, having a defect and talking about this priority is very important because it helps us and the developer to work on it and prioritize it either on the top of our priority list or moving it a little lower in the priority list. So let's say it's P1, it's highly important. We cannot afford to have it you know face it later. When I talk about actual result, in actual result I'm actually talking about the fact that when I created this test case, I had actual result populated over here which was the test result. Over here everything seemed to be working quite well. Now when we're talking about actual result here, we'll be posting the result in a way that we are now considering the scenario that the user was not prompted with an error message stating minimum base cannot be greater than the maximum base. Also the factor user was able to save the new created record which in a way is against what was expected. So now coming to the expected result. Now expected result remains the same. The entire thing has to be here. So there are scenarios wherein we don't put the expected result in terms of steps. If not this, we can just write the fact that the user should be prompted with an error message stating minimum base cannot be greater than maximum base. If not the steps, we can have a statement over there stating what was expected, then what we got. Similarly, if you don't want to write the steps over there, you can actually have the user was not prompted and was able to save the newly created. So this is actually the actual, okay, if we are logging the defect, right? Yes, when you're logging the defect. Again, the ticket number comes in when we are logging a defect. It completely depends upon what tool we are using. In some platforms it's auto generated. In other platforms, we actually have to feed in the ticket number which in turn helps us in getting it related to that. Let's say it's TCAT-1. Next one, the test case title, right over here, we have the option to have a lookup. Again, in some tools, we do get the test case as a lookup. In some, we just don't get an option to have, sorry, the test case ID populated on it. Status, status is scamblery, but usually the most commonly used statuses are draft, accepted, defect or, you know, don't consider defect, it's just development, FT or FT in progress or FT complete. FT means? FT means functional testing. Okay. And in some scenarios, you will not find FT or functional testing, you would rather find QA. It's either QA, QA in progress or QA complete. Again, these are upon the discretion of the user who is using the tool. One, two, it is also dependent on the fact that sometimes some projects require their JIRA board or any other board to be shared with the customer. So it's customers call as well what statuses they want on the board. But again, there are some rare scenarios. Moving on to severity. Severity basically means how severe that defect is. Is it actually blocking you from performing the functionality and getting the end result? Or it's just a major one, it's not a blocker or it's a minor one, which is like the least impact on the functionality. Again, not a blocker though. So that's how we log defects. And at the end, we get retesting results. In some portals or some tools, it's named as retesting results. In some tools, it is known as actual result again. But in that case, the actual result is more or less like a separate feel altogether, the actual retesting results. Again, in this case, you have to mention when you said that expected result should be that the user should be prompted. So if it hasn't fixed, you would be like the user was prompted and was not able to save the record. This can be upon creation or this can be upon editing the record. So that's when that's when and that's how a defect is lost. Coming to a similar concept, you must have heard about bugs, right? The last part of it, bugs. So the difference between the defect and the bug is clearly around the fact that when I'm testing a functionality, I found an error or a glitch in that that's a defect, which is quite related to it. And we have discovered it while performing that functionality or executing that functionality. If let's say you're performing the functionality of checking this, you know, the fact that minimum pay cannot be greater than the maximum pay. And what you find is that another functionality is not working, which was that the rating, let's say, cannot be greater than five. You have put it as six and you're able to save it. Save the record when you're of course with this criteria, but you won't be able to meet that criteria. In that case, you can log a bug because that was wasn't a part of testing for this particular phase of the plan. So this was it for today. If you have any questions, guys? Yeah, Irwin. So there is one question, like, can you please tell negative task case at the same time? So I think you covered one task case. So can you just relate it with the negative scenario quickly? Okay, so for negative scenario, I would be picking the case where I mentioned about the fact that we are talking of the rating, right? Let's say the ratings as of now are only valid where we have the values one to five, right? So let's say if I'm leveraging the value one, I'm good to go. I'm able to save my record, right? I'm leveraging value two or five. I'm able to save my record. Let's say I take the value 0.99. I'm not able to save the record. That's where I'm bringing in the negative test cases, or the negative test scenarios, right? If I take 5.1 or 5.2 or 5.09, I should not be able to save the record. That should be prompting me with an error message stating that this is an invalid set of value. Similarly, if I talk about another real case scenario, where we can not actually, where we log in into a functionality, again, having the user logged in into the Salesforce org in many scenarios plays an immensely essential role to be verified, because if the user won't be able to log in, we will be stuck and the functionality will not be tested. You people must have heard about LAP, which also stands for login access policy, right? Where in our system administrator user, let's say, has the ability to log in as someone else. Let's say Sanjay is the system administrator user. I am a, let's say just a recruiter user. Sanjay wants to log in into the recruitment org as urban corona. So what he will do is he navigate to the system setup, sorry, the Salesforce setup, right? The next step would be to navigate into the user's tab, opening the user's tab from the drop down under the main user tab, then log in, opening my profile and hitting login. First step would be to just hitting the login action, getting into my profile and checking in for the candidate's object and performing the entire functionality. The other option could be he trying to log in besides login access policy while feeding in the credentials in the login page and populating a combination of either the correct information of username password or a combination where the username is right and my password is wrong. But he's still trying to log in by hitting the login action button wherein he should be actually prompted with the fact that the password is incorrect. Also, the fact having the negative test cases or the scenarios implemented for the login functionality, it would be more or less like being able to get stuck over there. When I say being able to get stuck, I'm actually talking about a scenario, having fed the fields with the incorrect values for the first three times, on the fourth time, he should be blocked. He should be asked for a reset of the password. Again, reset of the password is a positive scenario which you are testing, but for the very first three is the shots that we have given to it. We are testing in some different combinations. I hope you guys remember we talked about decision table testing technique. So that also came into the picture now. We took negative test case scenarios and we were able to find that out as well that it was working. At the end, while creating test cases, having the negative scenarios also helps us in working with our approach, which was to work with a constructive mindset but a destructive approach. I hope this answers the question. Exactly. So we have one more question and I think it is straightforward. So Dheera is asking how to attach evidence if the tester is trying to execute steps, sorry, step by step in Salesforce. So I think we can do a screencast, right? We can record something and then... Exactly. So whenever you are creating test results, always make sure that, as Sanjay said, that we should have a screen recording of the functionality. Why that is important? That is essentially highly important because it helps the end user or us as well to revisit the same in the latter phase if it does not work, that it was previously working and what could have been the possible defect. Also, as we say, for many things, we need evidence. This is our evidence of testing. So either post-screen shots, post-screen shots when required, like just for the UI essay, that's when screen shots are the best. Trust me, when it's about having a validation pop up, the best scenario would be to make sure that you are having a screen recording or if it's small as with regards to permission set, make sure that you are leveraging screen recordings. Okay. So I think we don't have much questions and today's session was very interesting and I just enjoyed whatever you explained because I can relate the things. In first three sessions, you were talking about all the concept related things and in today's session, like you explained everything practically. So I appreciate your efforts and I can see Sumoq is saying great session. So those who have joined live, so I think they understood how actually we need to do systematic QA or testing. Right? Because if we talk about development, so in development, we develop some things and we just check whether that functionality is working or not. But with these sessions, I think people are able to understand how exactly you need to run a process for testing something. So testing is one thing and to have a process in place, that is another thing. So guys, if you are following all these QA related sessions, it is very much important for you. So those who want to make their career in Salesforce ecosystem as a functional consultant. So I think along with admin, if you have QA skill set, so you can get a job because here you don't need to do any code stuff, right? Everything is functional. So we have two types of testing like one is functional and one is automation. So in automation, we need coding skill set, but in functional testing, like if you have admin knowledge, so you can just learn all these concepts through these sessions and you can just apply for the jobs. So even I think one more session is there that you will be delivering next week. And then we'll be having your journey session where you will be like telling guys like how you build your career in Salesforce ecosystem so that it will motivate other folks as well. Okay, so I would just like to add one small thing for the folks. Those who have been following the sessions, I would request you to do attend the next session because we will be talking about the deliverables. And that's the most important factor of the entire QA process because over there of having those documents and handing it over to the customer, that's where the entire thing comes on. And this will also have the factor where the bunny asked that how should we show the results. Those will also be created. Okay, so guys don't miss next session. So it will be happening next week. So I will send the reminders in the telegram group so that you can join. So I think this is it for today. Thank you so much for joining this session live and those who are watching the recording, thanks to you as well. And I hope all these sessions are fruitful for you. And I want to thank Irwin and I appreciate his time like whatever he is doing for the community. I hope lots of folks across the globe will be benefited with this knowledge. So thank you Irwin. So see you next week guys. Thank you so much. Thanks Sanjay. Thanks everyone.