Hello friends and greetings for the day welcome back to another tutorial on istqb Foundation level certification we are in Chapter 2 talking about testing throughout the sdlc and continuing with our 2.2 that is test levels and test types and as a part of this tutorial we are stepping into the next segment of this part that is 2.2.3 confirmation testing and regression testing and as a part of this we will understand what are those two things which we can conduct when it comes to change related testing [Music] when it comes to confirmation and regression testing these
two are generally considered as a separate category altoe and called as change related testing why change related testing because these two testing are only conducted when it comes to the changes performed in an application so let's understand step by step that what these two levels are or these two test types are all about and why do we call them as change related testing the number one is confirmation testing which is very much commonly known as retesting as well and this is generally conducted when we report a defect so the story goes something like this when
it comes to a tester testing a particular module or a functionality and one of the test case fails resulting into reporting a defect to the developer in order to get that fixed of course the developer will work on it fix it and return back the tester with those fixes now of course a very first Common intention says that you will rerun the same activity what resulted into a defect but this time to confirm if the defect has been fixed and that's what the name is all about confirmation testing now what is the twist between confirmation
and retesting most of the organization prefer calling this as retesting while when it comes to istqb they have a standard naming convention called as confirmation testing why because istqb has to deal with the entire world but not limited to one particular organization where some of the organization did claim that hey retesting is a generic English word which means repeating a test with reason without a reason I just repeat a test I call it as retesting but confirmation testing is not without a reason it's particularly with an objective to confirm that the report of defect has
been resolved and it is working fine now so as it comes with an objective we just it as confirmation testing but again a lot of industry in fact many Industries in the world prefer calling this as retesting so no conflicts it's just that istqb prefers to call it as confirmation testing but not retesting so keep that in mind and that would help you so as we all understood that it is very simple to say when you report a problem and somebody says we have resolved the issue the very first thing which you will do when
you get the gadget back is to confirm the fix and that's what you do so simple like for example my cell phone was not playing a song and I go to a particular support center and of course the support center says that hey I think there's a hardare issue you can you know we can fix it back and give it to you and when you get the phone back the very first thing you will do is play the song because the audio was not working fine right and that's what is confirmation testing so let's quickly
check up that what exactly the syllabus wants to convey us so that we are even addressing and adhering to the cabus content so when it comes to confirmation testing confirmation testing confirms that an original defect has been successfully fixed depending on the risk one can test the fixed version of the software uh in several ways including executing all test cases that previously have failed due to the defect or also by adding new test to cover any changes that were needed to fix the defect so I think this particular part is very very clearly also trying
to remind you that we have a principle called as pesticide Paradox if you think just as a result of fix ing a defect you need to add some more new test cases to make the value of quality a little more better and have a better coverage then you can certainly do so so it's not restricted only to one particular test you can certainly add more test if required but most important intention and objective is to confirm the fix they also want to add here that however when time or money is short when fixing defects confirmation
testing might be restricted to Simply exercising the steps that should reproduce the failure caused by the defect and checking that the failure does not occur so which is pretty much the straightforward definition to confirmation so we may not do any additional thing that is adding a new test case or repeating other defect related test cases but we just do it so again I think we just trying to add more value to it but keeping it very short and simple confirmation testing or retesting is just limited to repeating that test case which revealed the problem once
again to confirm the fix okay so let's not get confused here because in realtime industry we do beyond the single test similarly when it comes to the next one that is regression testing regression testing is basically to make sure that everything what was working fine earlier is still working fine taking the quick example what we just took say for example you reported the phone that my phone is playing an audio but I'm not able to hear anything uh that is like speakers are not working so when you go to the sports and they fixed it
the very first thing what you will do is confirmation testing or retesting to confirm whether the reported effect has been fixed but at the same time you realize that this gentleman or person attending you has fixed something in your phone that is Hardware replacing the speaker so it might be possible that he might have Disturbed something else or this new speaker may not be compatible with other parts of the phone and thus we do cross check by making a call trying to take a cellone Fe that is like checking your cameras front camera rear camera
signal strength and lot many other things right or whether the file and force file and folders are exactly the same or something got deleted so what what do we call this after confirmation testing and that what we refer it to as regression so regression mainly means that as a step what we take in order to fix something or add something or even just modify something for any other reason a change may not be just complying with everything what is already existing and this change May create adverse side effects is as simple as that like you
give go to a doctor and doctor gives you some medicine and ask you to visit again that's mainly for regression testing just to make sure that the medicines are working fine with you you do not have any side effects of these medicines and this works absolutely okay and same way regression testing is mainly conducted that okay the defect got fixed but post that the other things which we working fine has been any kind of side effects or not right because there are possibilities not mandatory but there are possibilities a change in the code may have
Ripple effects or side effects to the existing part of the system which was working fine Al now regression testing is something which is not conducted every time just the defect is fixed they are even applicable when you add a line of code or you remove a line of code or even if you migrate a product from one environment to another per environment so regression is applicable when the defects are fixed when the updates happen when the upgrades happen migrations takes place so all these examples we'll be discussing in more detail in our next topic 2.4
maintenance testing but on a high level regressions are just not limited that whenever a defect is fixed I do conduct regression it can be done in many other cases also and that's where we say that change related testing that means whenever a change takes place and change can be anything it can be an addition of line can be removal of a line or it can be editing of an existing line of code and that change invites you to conduct regression regressions are always seen as good candidate of automation because quite often we keep doing regressions
to make sure that things are working absolutely fine whenever you check in a new piece of code so let's quickly see what exactly the syllabus is trying to convey you when it comes to regression testing it is basically to confirm that no adverse consequences have been caused by a change including a fix that has already been confirmed confirmation tested these adverse consequences could cause affect the same component where the change was made other components in the same system or even other connected systems that means the white the ripple effect can be seen at multiple levels
not just limited to the place where the changes were made regression testing may not be restricted to the test object itself but can also be related to enir it is advisable first to perform the impact analysis to optimize the extent of regression testing impact analysis shows which part of the software could be affected so highly important to remind you again that impact analysis is a part of Maintenance testing and we'll be covering that there in more detail but for now impact analysis is a study which helps you understand what areas will be impacted by the
change it is actually helpful in reducing your effort on regression testing let's add further we talk about regression test Suites are run many times and generally the number of regression test cases will increase with each iteration on release so regression testing is a strong candidate of automation also automation of these tests should start early in the project where CI which is continuous integration is used such as in devops it is good practice to also includ automated test into the pipeline depending on the situations this may include regression test on different levels that means confirmation testing
and regression testing are not something which is limited to a particular level that means it can be conducted in static testing Dynamic testing all the levels like unit integration system performance usability wherever we have a change involved we need to make sure that this change doesn't have a side effect on the other existing part of the system which were working fine earlier further adding up U confirmation testing and regression testing for the test object are needed on all test level if defects are fixed and or changes are made on these test levels so I think
that was all just I made so I think that makes it very clear and understandable to anyone that what's a confirmation or retesting all about and regression testing is so that's all from this particular tutorial team should you have anything else feel free to comment below I'm always there to address your queries and answer them well till then keep learning keep exploring keep understanding the context thanks for watching the video team and happy learning [Music]
