 Hello everyone. I am Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So today we are going to have day number 88 of the Salesforce Learning Bootcamp. And as you all know, like this week we are learning about how to become Salesforce QA and what all things we need to learn if we are going to work as a Salesforce QA. So this is part two of the session and I have Irwin with me. So welcome Irwin on the platform and I appreciate your efforts. Like you are sharing your knowledge with the community. So thank you for that. So moving to next slide. Okay, so now I just want like Irwin if you can introduce yourself with the community. So like I know you introduced yourself in last session as well but maybe we will be having some new folks joining today. So please introduce yourself so that they know who you are and what you are doing. So thank you. So hello everyone. Irwin Desai and as you know that I'll be your host for the day with regards to the QA practices. And I am someone who belongs to a non-technical background and who got introduced to Salesforce back in 2020. Got a little fascinated about it and gradually started learning it. And now I am working as a QA engineer. So with regards to Salesforce QA I have an experience of one plus years. The journey the professional journey for me started nine plus years back as an interest and a person fitness freedom which is yet going on. But on parallel I'm also practicing the QA practice. And recently I also launched my military podcast that goes by the name present docs. With that I am also certified administrator. Great. So thank you Irwin for this. So moving on to the next slide. So this is our telegram group. If you if you want to discuss any kind of doubt related to Salesforce. So you can join this telegram group. Lots of folks are connected here. And in the next slide I'm going to show you the timeline for upcoming weeks. So this week we'll be having two sessions on QA next week again two sessions and next to next week we'll be having two more sessions. And then we'll be having some mock interview sessions. Right in which I will let you know like how if you are a fresher how you can introduce yourself or how you can answer questions those are being asked. And if you are in like professional working already with an organization and want to switch. So sometimes it is a little bit tricky like how to showcase whatever projects you have done. So that kind of things I will be doing for you so that you can learn. And if you want to follow those videos so in next slide you can see like this Sanjay Gupta Tech School is available on YouTube, LinkedIn, Instagram, Telegram. So you can join and follow and all the important links are available in the video description. So you can follow. And next slide says like you can share your reviews or feedback about the boot camp in the comment section on the LinkedIn so that more folks can get benefited with the boot camp. Whatever I'm doing for the community and different speakers like Irwin is here. So people are sharing their knowledge for you so that you can learn and grow in Salesforce ecosystem. Right. So with this I just want to hand over Mike to Irwin so that he can continue where we left yesterday so that you can learn a few more things. And if you have any questions just ask that in the chat so that at the end of the session like yesterday Irwin answered all the questions. So today also after completion of the session he will be answering all your questions. Okay, over to you Irwin please proceed. Thanks Sanjay. So guys today's topic is static testing. Static testing is a type of testing where we are not exactly executing the functionality but we are definitely trying to identify the errors in the software without executing the code. So it's generally performed in the initial stage of the software development to avoid defects as it is easier to figure out the sources of failures in the initial phase of the development process. And in the latter phase it's quite easy for us to get them fixed. Moving to the next slide. Over here we'll be talking about static testing types. So the very first option is about informal testing. So when we talk about informal testing we are actually talking about a document over here which has a list of contents jotted down and we share it with a set of audience so that they can review and give their opinion on that. The reason behind having such an approach is in order to make sure that there might be some points which we must have missed. So in that case they can cover those points. So as we just for a quick example when we look at the clouds we might say that look that cloud is very much resembling to a horse but a person coming there and might say that on the horses muzzle there's a horn that's actually a unicorn not a horse. So in terms of functionality if we are developing something let's say we are talking about the functionality that we are creating a contact record from an account. We have the required fields on the layout of the flow but we are missing some major fields which if we get missed in the future can cause a big problem for the business. So in that case our peers can help us in order to point that out and help us to also get that back on track without being missed. Next one is walkthrough. Walkthrough is basically done by some experienced professionals so that they can identify the defects without even executing the functionality but definitely by going through the code. The experience that experience comes with time because there are many scenarios which happens during the course of time which are some are non-recording but are very much expected. So having that eye of the analytical view and having that inquisitivity at that moment of finding out the defects and thinking of those vulnerable points of the functionality helps us in getting the defects detected earlier in the earlier phase. Next one is peer review. Peer review is basically let's say we have jotted down a test case and we have a set of test cases as well. We ask our fellow QA to just go through the scenarios we have covered in order to make sure that if some important or even some less important aspects have been missed those can be covered too. So this will only help us in order to increase our test coverage. Increasing of the test coverage also means that we have tested almost everything in the functionality. No stone has been left unturned in skipping anything that has not been tested. Last one is inspection. There are documents which are created with regards to what has been tested. We talk about sign of documents. We talk about we have a test suite. We have a test plan. So when there's a test plan we are definitely talking about a number of scenarios which have to be covered for a particular story or an epic or task. So it helps us in order to make sure that nothing is missed over there as well. In a way if I say in all these four points we had one major point in common that everywhere we are getting the things reviewed in order to make sure that nothing gets missed. That might in the near future cause a problem for the customer leveraging the functionality. Move to the next slide. Now comes the part where the functionality comes in action in a layman term. But if I talk technically this is the time where we actually execute it. We execute the functionality we look for the desired output with different kind of approaches. We also analyze the dynamic behavior of the code and which basically moves on with the help of the input values that we are providing the fields with the system with and the output values that we are getting. Are they expected or they are something which are completely unprecedented. Coming to the next part. It's basically that dynamic testing has its own types. So it's boundary value analysis. It's equivalence partitioning. It's that decision table. Error guessing is there and state transition is there. In each of these we are approaching the functionality in a different manner. It also means that on one functionality we cannot apply all these testing types. There might be scenarios where in just one can be applied. There might be scenarios more than one or the third scenario can be all of them can be applied. So moving ahead let's start with boundary value analysis. So in boundary value analysis we basically check the valid value or invalid value partitions. I'll be in the next slide I'll be sharing an example which will give you more clarity around it. We also make sure in this that the minimum or the maximum values are considered. The inside or outside values are considered in many scenarios. There are some typical values with regards to some special characters being leveraged. So those are also checked and at the end we check for the error values. The main aim of having boundary value analysis is to check the fact that the kind of values which are expected for a particular field are being expected. And the ones which are not are our functionality is actually throwing us an error stating that this is not our valid value. Also the fact that it helps us you know being a QA to prepare a selection or a selected test cases with regards to exercising on some bounding values. Because we know what is the criterion at that moment is for that functionality and what are the valid values and what are the invalid values. Moving to the next part that it's also part of the black box testing as we discussed yesterday. Black box testing is more or less where we are more or less concerned about the output and not how the code is being executed. What are the steps that are being performed in it. So just a quick review of you know what should be the guidelines of the boundary value analysis. So let's say there's their values between X and Y so the condition is restricted between them. So instead of X and Y if I say it's just one in 10 the values which are restricted to a limit is just between 1 to 10. We cannot have 0.99 which is smaller than one. We cannot have 10.01 which is greater than one. But it should be one 10 or either of the values that fall between that range. If there is an input condition you know where is a large number of values. Also with the fact that our number is greater than what was a normal number or the required number. In other in the technical terms we call it a valid number. We get notified with an error message for that. Here comes the example when I said about having a range between 1 to 10. The basic test cases created for such a scenario is 0, 1, 2, 9, 10 and 11. 0 being the immediate previous number of the first value of our range. And 2 being the immediate next number or the latter number of our starting value of the range. And same goes for 9, 10 and 11. The other scenarios which come up over here is that considering that 0.99 or 0.50. Though we are moving in decimals but they are also values which are smaller than one and in a way should be tested that the actual result of them should be that they are not accepted and the error says that it's an invalid value for the input. Same goes for the scenario when we are talking about 9, 10 and 11. If we say it's 10.5 or if we say it's 10.75 even 10.1 should be considered as an invalid input. This is what we have stated for our values. Just a quick example for this. Let's take an example of reviewing someone. We said that we should only review between 1 to 5 and the person reviews someone as 6. So in that case a validation error hits the user stating that 6 is an invalid value which is lying outside the range. So in conclusion I would say for this is that the aim is to only check the acceptability upon the acceptable range which is considered or stated in the requirement by the customer. Next one is equivalence partitioning. In equivalence partitioning we basically have a set of values between which there are acceptable values but if we go on to the set of values which aren't stated as the valid ones we get an error. Though we still create test cases around those in order to have a good test coverage and make sure that the values inputted there are considered as invalid based on the expected result. Example for this would be we have two set of values which is 1 to 10 and 20 to 30. So we can have scenarios where we have values lesser than 0 which can be in negative form which will be an invalid set. We'll be having values which will be from 1 to 10 which will be valid basis our requirement. 11 to 19 again would be an invalid set of values and 20 to 30 would be a valid set of values. So over here our main aim is to make sure that the set of values mentioned there or the input which is being given to the fields should lie between these ranges either of these ranges else we hit with an error message. Decision table based testing. So decision table based testing is basically getting the output from a functionality with a combination of inputs that we feed in. It's again a black box testing technique we are not at all concerned about how the code is functioning what are the steps that are being followed but more or less the fact that there should be a desired output out of it which is received. As you can see in the third point it says it's a cause or effect table. The reason behind it being a cause or effect table is we have a combination in such scenarios if the correct combination is put in the fields we do get the desired output else we get a failure. So the very first task in such scenarios or such kind of testing is to identify the functionalities where the output is basically dependent upon the condition of inputs or the combination of inputs. So there can be large number of inputs as well input combinations which can be further divided into smaller subsets bases the category. So when we are creating test cases we are testing we categorize them. So here's an example for decision based decision table based testing for you people. So let's say we are logging into some application and we are on the login screen and we take the very first condition where both our username and password are not correct. By the way just giving you the quick overview F stands for wrong username or password H stands for home screen is displayed, E stands for error message is displayed and T stands for correct username or password. Let's say in the first scenario we have entered incorrect username and password and the output would be that we would be prompted with an error message stating that there is an incorrect password as well as a username. The correct scenario would have been we would have entered both the correct values in both the fields basically in that case we would have actually landed on to the home page of our application. The second scenario is we are inputting a correct value and the other value is incorrect. So correct username and the combination of the second half of it is with an incorrect password. In that case again we hit with an error message. The third one is we have just reversed it a bit. Now we are inputting a wrong username and a correct password. Again the outcome remains something which is not acceptable that is we are getting an error message. The fourth scenario is the most like a desired one. That is both are correct that is the username and the password and we are finally landing on to the home page. In this case we are basically analyzing what combination fits the best for getting the desired output. So the output is completely dependent upon the combination of the inputs. Next one is error guessing. Error guessing testing is basically where the analytical thinking comes into the picture. So having that analytical thinking develop takes time. It comes on with experience because being a software QA or a tester the techniques one has to follow comes into practice in a good grip with time and the ability to understand and predict the kind of defects that come out can come out from a particular kind of functionality takes time to get addressed as well as and likes. So it is basically done by some experienced professionals so that in the initial stage the defects can be identified and in the latter stage we encounter lesser defects and even if we get any kind of similar defect it can be resolved very easily. So the purpose of error guessing in software testing is only to make sure that the person is able to analyze the possible bugs in the areas where the formal testing would not work. So it's all in the user set of testing and there might be some skipped areas and there must be some redundant tests as well which we are not creating but we are actually analyzing them and getting them sorted in the initial phase when the product is in the development phase itself and has not landed in our plate which is for the QA. Now talking of the fact that purpose of error guessing in software testing so the purpose is clear to make sure that analysed effects have them sorted in the earlier phase but the examiner while using the experience make sure these following points while performing this kind of testing which is the tester's intuition that comes into the picture the form was as we discussed earlier it comes with experience they get to know what kind of a defect might come up even if not they are very much capable of fetching out the defect from the functionality that is being developed there is some kind of historical learning again experience comes into the picture there is a review checklist when we talk about the review checklist, review checklist is more or less about the fact that we are making sure of some major points that we have jotted down and we are analysing those first or primarily in order to make sure that the functionality is at least accepting or sorry is actually acceptable basis those criteria next one is risk reports of the software every software has its own kind of a risk when I say risk I mean some kind of failure or a defect or an error where the functionality breaks analysing that in the earlier phase is very much helpful because that prevents from a bigger failure in the future when the functionality is almost ready tested and is being handed over to the customer post-UAT so it is immensely essential to make sure that such risks are analysed in the initial phase application in UI is again of utmost importance because it helps us in order to make sure that the UI is user friendly if the UI is not presentable one, two it is not easily accessible the user might not be comfortable using it so it is very much important to make sure that the UI is a little presentable of course by presentable I am not at all intending to say that it is having some kind of pictures or something or logos but definitely that it is so well organised that the person can navigate from one object to another easily the next point which is general testing rules and the next point which is previous testing results have the utmost importance again in the list because of the fact that the general testing rules also help us fetch those so-called provisal defects or bugs previous test results can help us to compare the functionalities and help us to fetch out those results basis what went wrong back then and what we can do better now or what was right back then and what is going wrong now so it is more or less in UI testing we call it as A and B testing comparing the two screens basically before and after so that is how we are basically comparing our previous test results with the current test results of functionality again talking about defects occurred in the past it is more or less we can call it as a sub testing part a sub testing step of comparing the previous test results with the current testing results and the last one is variety of data which is used for testing when I say variety of data as we discussed yesterday sample data plays a big a major role in testing a functionality because when we are doing negative testing and positive testing we are actually making sure that we have we are covering a good testing zone and good testing aspect of the functionality so that we are not missing on the vulnerabilities of the functionality example is what I would say to be let's say there is one bank account and we have deposited money and the range the acceptable rate over there is only 5000 to 7000 in order to check the right range we would be inputting various values for that we for starters we would be inputting 5000 the second one most probably would be 7000 and then we might go either greater than 7000 or less than 7000 also the fact that we might input some values which are between this range of 5 to 7000 at the end the goal is to make sure that only the values that lie between 5000 to 7000 are accepted else we should be prompted with an error that's an invalid set of values being populated in the fields so as you can see over here in this example 6000 got accepted, 55555 got accepted and rest all these which were 4000, 8000, there was a blank value as well there was 1000 and dollar sign was there, 4999 was there which was not accepted now the question must be if in the initial stage when I said 5000 to 7000 why was 5000.01 not accepted? it is because it is a scenario when we are checking that whether the decimal values are being accepted or not in some cases there might be an acceptance for the decimal value but now that we are talking about money we are not actually talking about sense if it's dollars right we are just talking about dollars which is 5000 dollars if we are talking about rupees then in this case it's only 5000 rupees it's not 5000 rupees and 1 paisa therefore we received an error message for this particular value whenever you are actually testing between ranges you are moving between ranges make sure that you are inputting a set of values and a variety of values that can help you in order to have a good test coverage now coming to the point that there is another kind of a testing technique which goes by the name state transition so it's again a black box testing technique and over here our main intent is to check the behavior of the system or the application that has been built with different kind of input conditions so it can be some random input conditions both positive and negative in order to break the functionality just to make sure that the desired output is derived out of the functionality in both the cases negative and positive so example I would say supposedly we are logging into a functionality and we entered correct password and username for first three attempts we were successfully able to log in the expected outcome in the case where for the very first time we have entered a wrong username and a correct password we get prompted for the wrong username for the second attempt we get prompted again but for the third attempt we get blocked and the fourth if we want for the fourth attempt it should prompt us to reset the password so having different inputs on a regular basis and then making sure that the fact we are getting the acceptable or the desired output that's where static testing comes sorry the state transition testing comes that was it for the day okay so I think we covered all the testing techniques right? yeah okay guys so we have couple of questions that I think you can answer so first one is someone is asking dynamic testing it's like functional testing or what? it is very much similar to functional testing because over here we are more or less concerned about the fact that we want the desired output of the functionality that is being tested so we are not at all concerned at the moment that how the code would go but as we say as we know as well that in functional testing what we do is we provide the field with an input or the functionality with an input we make sure that we are getting the desired output therefore it's very much similar to it okay so next is Sudhir is asking B, V, A, E, C, P and D, T, T are types of input domain coverage? yes as I stated earlier it is very much considered as the types of input domain coverage because we are checking the functionality or testing the functionality in different forms with different kind of values at the end our main aim is to break the functionality if possible just with regards to the fact hitting it's vulnerable points and checking that the functionalities, dweller points must be working as it should okay so I hope Sudhir this answers your question and I don't see more questions so guys if you have any more questions you can ask or maybe if you are watching the recording and if you have any doubt so in that case like you can reach out to that telegram group and you can ask questions there there is one question can please explain state transition testing so state transition testing is more or less like we are testing a functionality and we are making sure that we are putting some random values for that functionality and all our intent is to make sure that when we put in the right value we should get the desired output but before that if there is a validation where in inputting the wrong values would actually restrict us we should be prompted with that expected result as well so as I stated earlier if I talk about logging into a functionality if you log in with wrong password for the first three times on the fourth attempt of yours you will be logged out of logging in and you will be prompted with the error message to reset your password or in many instances it's like they ask you to give a gap of at least 24 hours before logging back in where in the positive scenarios we would expect that when we are inputting the correct input username and password we are able to log in and we are able to land on the home page directly right after hitting the login action also just for your kind reference and example sake I would also like to mention let's say we are talking about the forget password option we have clear forget password the correct behavior is that we should receive a mail with a link where we can navigate to and we can reset our password and whenever we log in the next time the new password is accepted and not the previous one in that case also we can have a simultaneous input of values that will help us in order to check that whether the functionality is working as expected or not I hope it answered your question yeah so I think I'm not sure what is your full name so it is asked by AG so I hope this answers your question so there is one more question so there is asking in account object there is four star rating so what are positive and negative test cases for it this is an interview question there is a four star rating on account upset and we need to identify positive and negative test cases okay so the first question you know which comes up for this is that when you are saying four stars in Salesforce there is a functionality where we can actually use some kind of emoticons on it right if it's actually about stars when it's four so is there a range specified for it if there is a range like one to four then we have to make sure that boundary value analysis just for example we are taking that one, two is acceptable half star is not acceptable or you know in many cases people get three fourth stars as well stating that 4.75 so it's 7.5 that should not be acceptable having stars more than four if acceptable like if you can input that but based on the expected result it should not be acceptable so that's where the negative parts of it come out and for the positive testing points all we'll do is we'll make sure that one is acceptable four is acceptable and any middle value is acceptable over there okay so I think Sudhir this answers your question Irvin I don't see any more questions so I think we can wrap the session here thank you so much for sharing the insights today and guys we'll be having two more sessions but next week so next week Monday Tuesday again we'll be having two more sessions and Irvin will share more insights about QA skill set in those sessions okay so stay tuned for those and details I will be updating in the session tracker so you can just follow that so again I just want to thank Irvin so thank you Irvin for sharing your knowledge with the community and I can see there is huge response on yesterday's session like more than 800 folks viewed that stream and I'm sure this will also cross that number so it is very good and I know like very less platforms are having information about how you can do proper QA in Salesforce ecosystem so QA related sessions are available videos recordings are available but specific to Salesforce there are very less so we are just targeting how you can become export QA in Salesforce right so okay so with this note like I take your leave and we'll be connecting next week for this session and keep watching the videos if you are not able to join live do watch recording so that you can understand the concepts because in QA practice concepts are very much important because if you know the concepts then only you can walk practically in the in this practice right so thank you Irvin and thank you everyone see you Monday thank you so much