 Hello everyone. I am Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So today we are having day 91 of this Salesforce learning bootcamp. And as you can see, we have came so far. I started this bootcamp in January and in August, like we are having this 91th session. And I have Irwin with me. Welcome Irwin on the channel. So Irwin will be delivering a last session of this Salesforce QA series. So this is fifth session of Salesforce QA. And if you want to become Salesforce QA and you want to know the concepts, terminology, how QA process actually works. So all these five sessions will be beneficial for you. Okay, so I just want Irwin to share about himself, what he has done or doing. So over to you Irwin, please introduce yourself so that if someone new joined this session or someone is like for the first time on the channel, they should know who you are. So please go ahead. Thank you Sanjay. So hi everyone. Irwin this side. I am someone who belongs to a non-tech background to be precise. So my journey started back in 2014. But it started as a nutritionist and a personal fitness trader, which if I talk about today, so it marks like 10, 9 plus years in that very industry. And one plus years of experience I hold as of now in Salesforce QA. With that, I am a certified administrator. And recently, I also launched my own podcast, a defense podcast that goes by the name person docs. Great. So I'm happy like I was able to have you on my channel because I just wanted to give some different insight to the people like even if you're having different experience, still you can jump to IT industry and Salesforce is very good for them. And as you already shown to the community, like you are the real example, you work nine plus years in the non-technical area. And then now one plus years, you have spent an IT debt to in Salesforce ecosystem working as a QA. And maybe in future, you will do wonders in different roles as well. Right? So all my best wishes with you. And I hope lots of people will be motivated through your journey because guys tomorrow we'll be having one more session. And in that session, Irwin will give you some insights like how he like shifted from non-technical ecosystem to technical ecosystem. So whatever your questions will be, you can ask in that session. Okay. So with this note, we are moving forward. And even next slide, please. So if you want to become part of a group where lots of beginners and intermediate professionals are connected, they are helping each other, solving problems together. So you can scan this QR code and you can be part of that group. Okay. And this is week 29. So like soon, this bootcamp will be ending. So after these QA sessions, we'll be having more interview sessions starting from next week. Right? So do follow those as well so that you can prepare and know like how you can answer questions. So I will be answering, I will be showing you like how you can answer questions. Those are being asked in the interviews. So those will be targeting freshers as well as experienced professionals. Okay. So moving forward, if you want to receive timely session reminders, then you can follow Sanjay Gupta Tech School on YouTube, LinkedIn, Instagram and Telegram. And all the important links are available in the video description as well. And please provide some reviews or feedback. With this note, I hand over mic to Irwin. So Irwin, please proceed further and give more insights about QA. Thank you, Sanjay. Okay. So guys, in our last session, what we did was we learned about test cases, where then we also talked about some bugs and defects, right? But we, the thing that we left for the session was that what is exactly the bugs and defects life cycle. Talking about bug and defect life cycle, I basically mean that the stages to which a bug or an defect moves, right? So when I talk about the stages, these stages remain the same. So basically the drill of the movement of the bug through the set of the stages remains same. In other words, the stages remain the same. They are no like, you know, as in sales, we said that they are global pick list value sets. We can say that, you know, in our tools of where we manage our test cases, where we manage our bugs, where we manage our defects, over there as well, the statuses, all the similar values, which are more or less universal. So moving to the next slide over here, in this small chart, what you see is that when a bug or defect is created, the very first status which it holds is dropped because at that time it is only created with a set of information that should be there. For a quick reference, quickly navigating to the Salesforce org, right? So let's say this is a, you know, a random tool where we are just managing our bugs and defects. And the very first thing is that it's in the status dropped, which means all we have done is we have mentioned the bug title. We have stated the priority of it. We have shared the actual result. So when I say the actual result over here, what I mean is the result that we found while testing the functionality basis of test cases in the primary phase. And this is the, this result gets us the error that we received or the faulty portion of the entire functionality or the faulty step of the entire functionality that we discovered or spotted. Coming to the expected result, this, as we discussed earlier, this basically helps us understand that what is the expected outcome? Just a second. I'm sorry, are you able to see my screen? Yeah, we are able to. This is the wrong one. So coming back to expected result, expected result is something which states that what should be the expected. Sorry to interrupt, just zoom in because text is too... Yeah, sure thing. I hope this looks good now. Little bit more. Yep, now it is good. The expected result is nothing but the expected outcome of the functionality that has been tested. Right? So the expected result, even in a bug or defect, remains the same. Next one is severity. We have provided the severity of it. For this way scenario, we are saying that, you know, it's a block of us. Next thing is retesting results. In many tools, you will find this field, but in some of them, you will not find this field, which is normal. Right? And last one is test case. In some of the tools, we find the lookup to the test case. And in some of them, we do not. And the last one is a ticket number. Ticket number is again a scenario which is just seldomly found. So now moving back to our concept that we were talking about, the very first stage of our bug or defect when it's created is raw. That's when we have just fed the bug or the defect with the requirement condition. Then comes the next step. The next step is basically when the bug or defect gets accepted. In accepted, it means it's basically accepted to move further to the developer's basket. Right? The further stage comes on, which says that it's open, open, or we can call it as in development. Right? In some tools or some teams also address it as with developer. It completely varies from person to person how they are actually going to define it. But the stage remains the same. Which is open. Next one is retest. So when the developer is all set with rectifying the error and finally moving it up in the QS basket, it moves to the status reset or in scenarios, we also have ready for QA or ready for FD. FD stands for functional testing. So once now here comes, here comes the catch. You all must have read about Salesforce, of course, and you must be aware of flows. In flows, we do get a point where we take the component of decision. Right? Over there, we are either taking selecting A or we are selecting B. Over here as well, here comes the point wherein we either move to the status retest past or retest failed or reopen. So this basically depends upon the retesting that the QA does. If now the actual result actual result is at par with expected result, then we move this bug or the defect to the status retest past. If in case the expected and the actual aren't par with each other, in that case, we move it to retest failed or reopened. This clearly states the status retest past that the error has been rectified by the developer. The QA has verified and validated it. And finally, we are closing that particular bug or defect. Let's talk about the scenario where the error was rectified by the developer, but actually it did not work when the QA was testing it. So in that case, it gets reopened. When it gets reopened, the thing that happens as of now is that it either is moved back to the developer and the developer either marks it as duplicate or rejected or therefore. So over here, this might look a little confusing. So let me reiterate it in a different manner. Whatever I said, this happens at a stage prior to the stage when it's with the QA back again. Supposedly, when we move back to the stage where it's accepted and it's with the developer, the developer will either mark the bug or the defect with the status duplicate or deferred. Duplicate stating that there is already a defect or a bug with the same bug typing, targeting the similar kind of an error. Talking about deferred, deferred is usually leveraged when the defect or a bug is not of that very sprint which is going on or not a part of the release which is going on at the moment. There might be instances when you have raised a bug, you have raised the defect, which is of the latter release or a latter sprint. So in that case, the developer's action would be to mark it with the status deferred so that the current timeline of the sprint or the release is not hampered and the developer can actually invest his or her time in the set of tickets which fall in that sprint or release. This was the basic lifecycle of bug and defect. Quickly re-iterating it before moving on to the next slide, the bug opens or the defect opens at the stage draft. It moves on to accept it when the developer accepts it for the further action which is to be taken on it. When it's in the depth, developer's played. Developer actually looks for the fact that whether it's a bug which is a fresh one or duplicate one or the one which falls in the latter sprint or release. If it's a fresh one, it moves in to the developer's plate and the developer starts functioning on it, starts rectifying the error. If it's a duplicate one, the developer marks it as duplicate and it straight away is marked with the status done. If it's a bug of the latter release or sprint, in that case, the developer marks it with the status that worked. Moving back to the very first status where the developer is working on it, the developer has rectified the error, the developer moves it to the QA's plate and once the QA is done testing, if it's a positive result wherein they expect it is at far with the actual result, the QA marks it with re-tested and passed and eventually it gets closed. If not, it again gets reopened and moves back to the developer's plate. Coming to the next slide, whenever QA is testing, it's immensely important to make sure that we are sharing the test results. Our test results is more or less a way to prove what has been tested and how it worked at that point because as we know that at some point, our code breaks or even just the basic or standard functionality or the configuration breaks as well. We can take an example of a basic sales for slow. We are working on it. It was working absolutely fine but suddenly when a record was created out of it, no record actually got created. Nothing got saved or even if it got saved, no values popped up over there. Just showing it for a quick reference. Those who are doing it again might be a little familiar with this flow that we had earlier as well. Let's take it as the defect test type and let's give it a B1 priority minus severity, just major severity, status as graph. Take a number as eck we had one. It's just the expected rate and again let's upload something and let's save it. So basically what should happen now is when I save it, it should help us in creating a new defect. But over here we got an error that an unhandled fault has occurred in the flow. So basically this is now a defect if you are actually working on it. So now this being the case we have to showcase it further and how we can show it is with the first part being the screen recordings. So when to prefer screen recordings when we are actually trying to showcase our functionality being executed. How to record it in the right manner is it should cover each and every step. That is either from where you are logging into your org or you are on your home page and then you are navigating to the particular tab, let's say candidate's tab or test cases tab and then you are finally moving ahead with the functionality that is to be executed. And the most important part you should or you must cover the URL because the URL holds the fact that whether you are working on a partial environment, a full copy environment, a production environment or the developer environment. So that holds the utmost importance because in case when you are referring it back in the future you will get to know very easily on which environment it was performed on. Moving to the next slide I have a couple of short screen recordings for you for the sake of reference. The first recording is when we are starting from the login screen. The second one is when you are already logged in and you are starting from the home tab, right? Let's move it on the login screen and check out how the recording has to be done. So now what you see is I fill in the details and I get successfully logged in. So now when I have already logged in, my next step is to move to my application which is QA wisdom. Once I'm in the application I have landed on the home page and I'm now we get to the test cases tab. I create, click new, a new window in the name, dialog window name, new test case pops up. I fill the fields with the required information, I give it a severity value and a priority value and I save it. So what I get to see here is that I was successfully able to create a test case record out of my demo. So over here I showcase the entire functionality being executed through my new action on my test cases tab. So this is one way to showcase a test results. The other way is you're already logged in and you be like you start navigating from the home tab and now you navigate to your test cases tab, you click new, a dialog window pops up, you fill the fields with the required information back again and at the end you'll save the record and your expectation would be that you must be able to create a test case record successfully. So now that I have filled my fields with the required information and I click save, so here what we get is we got our expected output which is we were successfully able to create the test case record. So I hope this has conveyed you the major point or the most concerning point of the fact that whenever you're sharing a test result with regards to showcasing a functionality being executed, make sure that you're covering each and every step of it. That brings a clear view for the end user to go through it and if he or she has to perform it further, it's quite convenient for them without missing a single step. Moving on to the next tab, the other way to share a screen test results is with the help of screenshots. So when we talk about screenshots, the best time to prefer it is when it's more or less it's UI related or you have to show any specific validation message being popped up or any screen flow where we are talking about a display text that we have leveraged. That's when screenshots work the best. Over there, you don't actually have to show the entire recording of it. If you prefer, it's not at all wrong. It's a good practice though. Moving to the next point that right way to take a screenshot is again, do not forget, do mention the URL, do capture the URL. I'll repeat, URL holds the name of the environment you're working on, whether it's Vellapa, it's Vellapa Pro, it's full copy, partial or production. That's highly important to have that captured because in the near future whenever you look back at it, it will be helpful to figure out what the environment it was. The next part is that whenever you're capturing it, basically you're testing some UI functionality and you're capturing it, make sure that it's specifically checked at that point. Use some kind of pointer, use some kind of arrows that will help you specify what was being tested because there will be many things on the screen. The last one is, as I mentioned earlier, highlight the points if possible. Moving to the next screen, you'll see a screenshot for the same. Now, over here what we have tested is one, we have made sure that the URL is included. Two, our error message, which is actual result cannot be left blank, is mentioned right below the field. So over here what you see is here's the field actual result and here is the error message stating actual result cannot be left blank. What I've done is I have used these numbers and I've used this arrow so that I can highlight the same and the end user is able to get it clearly what was being tested. Also the fact, over here this is more or less a dev environment so you can see it's written, it's dev. If you talk about the paid version of Salesforce environments, you would get it. If it's either a developer environment, a partial environment, a full copy environment, or a production environment, everything will be stated there. So these are the best practices of how we can showcase test results. It's not only for ourselves but also the fact when you'll hand it over to the customer, the end user, it will be helpful for them to spot the errors that we encountered or the testing which we did and also the fact it proves what all was tested. Not because just having the test cases jotted down won't help you clarify the fact that you tested that. Moving on to the next slide, sign of documents. So what are basically sign of documents? Sign of documents is a part of or you can say the sign of documents are the test deliverables. It's one of the test deliverables but the most important one. There are many more but for today's session I've picked up only sign of document because of the fact this is the document wherein we formally declared the fact that what all was tested and how it was tested. By how I mean whether only function testing was done or regression testing was done or system testing was done, what all kind of testings were performed. We mentioned each and everything over there. So to begin with whenever we create a sign of document we make sure that all of these pointers are covered which is test plans, test cases, regression test cases, epic stories, tasks, sub tasks, bugs and defects. So when I say all of these points are mentioned what I mean is the number of these points which were there, like number of test plans which were there. In a single release there can be more than one test plan existing. If we talk about a single sprint there are chances that we just have a single test plan and we have executed it all. Moving on to test cases, by test cases what I mean is the number of test cases which were created and that basically as you guys remember test cases are nothing but just a collection of steps covering a test scenario. So by test cases we are basically sharing the number of test scenarios which were covered during the entire sprint of the release which was pulled on. Next one is regression test cases. How many test cases were leveraged out of the total test cases created initially for the regression purpose? The total number of epic stories, tasks, sub tasks which were entered in and worked upon also executed in technical terms. Last two bugs and defects, again a very important part. Taking out bugs does not show that you know you are actually showing that how badly your functionality of the product was developed. Where it clearly states what all errors were found during the testing phase and the fact that they were successfully rectified. Because we all know that you know there is last modified or if you talk about the GitHub panel over there as well he can see that when the changes were made into the repository we are leveraging and finally which has been deployed into the Salesforce org. So again never hide the number of bugs or the number of defects that have been logged by you. Also the fact that whenever, okay let me showcase it to you as well. Let's say what I've done is for the reference sake I've created a sign of document object and here's our record. So whenever you are working on a sign of document make sure that you have every single thing mentioned clearly. To start with what was the project? Project's name is highly important to be mentioned so that it can be easily written like so. Let's say our project was due a bootcamp. We have mentioned number of epics were 10, number of stories were 120, the number of tasks executed were 200. Let's say there were no sub tasks. So we haven't mentioned any but over there you can mention it in two ways. One n dot oh sorry it's a number feel I cannot enter alphabet as of now. So you can either be like n dot a dot or straight away just put a zero. That would be acceptable as well because it will be giving a clear in view to the end user that is our customer. Next one is number of defect that 30 defects were logged. The next one we can bugs we are saying that 10 bugs were logged and then when we are talking about number of test cases we have clearly stated that total 340 test cases were created for this entire release that we are talking about. Now two very important fields one QA completion date when was the QA completed right because we have to say that clearly in order to make sure that right after the QA gets completed our customer tends to start the unity process which is user acceptance testing and it's highly important to have it have the right value the date value in the field. Last one is data documents when was the document created. This also plays a major role because this is mostly done when our testing is over. You cannot have a date have a date value which is actually you know let's say our date of completion was 15th of August and my documents date is actually like 20th of July. So this is an invalid scenario. It's fine if it's like you say my document also got created on 15th of August acceptable. You say it's it was created on 16th acceptable it should not be before the date of completion of Q right. I hope this makes sense and always make sure that whenever you're creating a sign of document you're stating each and everything clearly nothing is being missed whenever you are stating the number of you know either of these make sure you cross check twice the number should match always and for test plans be specific share the link of the test plan that you're being shared that is being shared in the sign of document. Okay there are more sign of documents as well but today as I stated it was only sorry they were they are more test deliverables as well but today I'm only left with sign of document it being the most important one. Just stating two more globally that is we share a functional document and we share a technical document with our customers usually functional documents usually hold the screenshots and the screen recordings all the functionalities that were executed during the release and it is more mostly delivered by the QS right. Coming to the technical document technical document comes from the developer's side in there in the technical document they mention each and everything which is with regards to a code that they have jotted down the order. So make sure that whatever you are performing with regards to the functional testing or the regression testing you have it clearly stated in the functional document and the recording should be precise the screenshots should be precise as we looked back earlier the screenshots should have the pointers so that the end user is quite comfortable in looking at it and in and also recording that in case the user is finding any kind of a bug he or she cannot state that it was never tested initially by our team. Okay last one last part of it what is the conditional sign off conditional sign off is basically the scenario wherein we are cognizant of the fact that something is not working but because it's our go live date and a sign of date we are delivering it to the customer with that defect we moved along. So as we looked here that you know our flow wasn't working well our flow actually broke at that time. We have deployed this application which was configured with each and everything that you know whenever we have severity priority defect title and our status is this our defect gets populated right and let's say we have other functionalities as well but we are certain of the fact that this is just not working right in this case it will be more or less a scenario wherein we are doing a conditional sign off that we are clearly stating that that hello customer okay again this is just to make you connect well that this particular functionality is not working as of now it has an error within and the team is working on it. So at the end the thing which comes in is that we have to maintain utmost transparency so that no conflicts arise post our go live. This was it for today's session but before I log off I would just like to share a set of tips with you guys for especially those who are new to QA and will be starting right you know in some time from now or who have just started the fact that whenever you are testing make sure that you are sharing your updates one on the tickets two there must be some slack channels or whatever messaging application that you're using within your company make sure that you are sharing each and every update of your QA practice of that particular day when you call it for yourself. Two whenever let's say there's a functionality from a ticket which is not being tested due to some reason make sure you mention it clearly mentioning the developer it's not like you're pointing out that developer saying that buddy you didn't do it but it's more or less the fact you're just having the required transfer and see over there so that no more questions get around sports the fact that this wasn't tested even when it was in the QA's bucket as we discussed earlier make sure you always have the test results added to your comments and to your messages being a QA you should be inquisitive whenever you get the ticket you hold it out raise that question put that question on the ticket assign the concern representative or the point of contact also share the same and that's a let's say we are leveraging slack in your in your project slack channel clearly state what are your doubts what are the findings that you have sometimes you might find something which is exactly not there in the description right but that might hamper what is being developed in the near future you should share that as well either as a as a proposal right or the perspectives change which might be good for your business for the business that is basically the customer so these were the basic tips do follow these this will make your life easy as a Q so thank you yep great insight and i am sure like people are very much benefited with all the five sessions which you have delivered and i can see like right from day one like day one to day five whatever sessions you have delivered so you have explained everything in detail theoretically and you also tried to relate all those things practically as well i can see like that QA wisdom is like an application where everything custom like in form of custom object you created and all the fields those are related to QA thing so that is very great and guys one more thing in real-time projects you might get different different tools to manage the tickets right so even showed everything in sales force it the the application which he demoed is basically implemented in sales force but the functionality of this application will somehow match with the functionality of other tools so most popularly we use Zira for managing the tickets right but in some organization it it may be sales force platform itself so the overall process which Irwin demonstrated you will be same the platform will be different so you will be quickly ramping with all these five videos if you go through so if you're a fresher then also these videos are very much important for you if you have joined any organization as a fresher QA then also these sessions will be beneficial for you and if you have like one to two years of experience and you just want to refresh your QA skills and you have not walked on much projects so end to end everything is explained in these sessions right so if you like the sessions do provide some reviews and feedback on YouTube or LinkedIn so that I can share those with Irwin as well right so thank you Irwin for providing this much insight to the community I really appreciate whatever you have done and guys tomorrow we'll be having interactive session so there will be some questionnaires I will ask those questions and Irwin will be answering those and it will be kind of a motivation session for those who are coming from non-technical background to technical so if you have any questions so feel free to ask and I think Irwin will be happy to answer those questions for you okay one thing Sanjay I would like to share with everyone especially for those who are either going to start the QA practice or have recently started people have literally asked that how should they do a hands-on when you don't have time to become a QA guys make sure that when you're doing it especially when you're working on Salesforce like just for instance make sure that you have your own org created create an org create scenarios on it by creating scenarios of course primarily act as a developer create everything based on what's there in the description for you followed by that try creating test cases fetching the test scenarios having the test scenarios created sorry test scenarios fetch create test cases execute them get the test results make sure that if you're getting any kind of defects or bugs log them for yourself and then take an action on them as well this will help you understand the entire practice also if you're working on trailers there are many projects so when you're developing that try QA on that so those are more or less some real life scenarios that will help you get a good grip on it yep absolutely you are right so if you are also watching this stream live so you can read some feedbacks so people are liking whatever you have delivered and someone is asking QA refers to quality assurance so I said it is quality analyst so sometimes it is quality assurance as well right yes exactly yeah yeah so like field to heal is saying tomorrow is my interview for Salesforce QA position that more help to me I think surely you can just go through all five sessions and all the best I hope with all these knowledge if you go through like if you go for the interview surely you will crack it all the best buddy and make sure that whenever you're going for Salesforce QA position just touch with everything starting from Salesforce to QA practice don't leave anything there right so it should be combo of admin plus QA sessions okay even so thank you so much again for providing the these insightful sessions we'll having one more session tomorrow and thank you thank you thank you thank you everyone for joining this session live and those who are watching recording thanks to you as well see you tomorrow with some new stuff thank you bye everyone