Hello friends and greetings for the day welcome back to another tutorial on istqb Foundation certification we are in chapter one talking about fundamentals of testing and today we shall be continuing with our next segment that is 1.2 why testing is important or why testing is necessary so let's quickly have a look what this segment of this chapter has to talk about so as a part of this segment all we are trying to add is the value what testing adds to the overall contribution of success of a product now testing contribution to the overall success certainly
talks about the various activities being conducted at any point of time many people as we discussed in 1.1 think that testing is limited to writing test cases and execution of these test cases which happens pretty later and in the life cycle but if I consider the sdlc model and talks about the testing contribution it starts right from the beginning of the sdlc model that means right from the requirement Gathering phase a tester is someone who is responsible to go ahead and review the requirements and contribute by finding ambiguities contradictions inconsistencies omissions related to that indeed
in simple words all we are trying to do is analyze the information and Report any kind of confusions unclear requirement incomplete information to the author in this case the author would be the product owner or the business analyst but the point is testing gets started right from there so of course there are two types of testing which we all know we have static testing and dynamic testing static testing is without executions when you review the work products or documentation and F anomaly in that is what I call it as static testing whereas if I talk
about running the product and testing it dynamically I call it as Dynamic testing so we will talk about static and dynamic testing in in more detail in our chapter 2 and chapter 4 for now static testing is something which kicks off right at the beginning of the sdlc and testers are just not limited to that of the dynamic testing another important Point here is to talk about that one I can talk about static and dynamic and second important thing is the part of the larger project management activity that is contributing to decisions to move to
the next stage of the sdlc model that means we are consistently providing the those critical information to the management that how exactly our testing is progressing in the context of reaching the required coverage or identifying the defects at the same time any other you know identifications regarding the risk or any kind of defects to be close prior to moving to the next St and that all puts together in terms of management to make a decision on how exactly can we move ahead or should we continue to do something more there talking about testing provides users
with indirect represent ation of the development project where testers ensure that their understanding of the users need are considered throughout the software development life cycle that means tester not only performs the activities but at the same time looks forward to gain the required confidence on the product's quality if I as a tester is not confident about the quality of the product I will not be able to give a go ahead to any of the production team or the management including the release management team so there's no point releasing a product which is not like a
tester is not confident about the same so in that context the testing certainly contributes to the overall understanding acceptance confidence coverage and then push it across to the next module also testing may also be required to meet contractual or legal requirements or to comply with regulatory standards now it's not necessary that every single product will have this into consideration but contractual things like timelines the required level of coverage and Etc comes as a part of contractual agreement when it comes to the legal requirements could be related to the things which are like uh medicines or
talking about banking or you know any other things like automotive and all so they do have related legal requirements and there are of course many products around you like including the appliances the phones or any other products which are embedded systems they have to go through the regulatories which are like AOW amount of things so for example if I'm talking about the radiation being emitted by a cell phone has a limitation that means what amount of radiation can be you know emitted from the phone and if your phone is a meeting more than that required
regulatory then of course your phone will not be released to the market and that's where a lot of phones are banned by default before releasing them also the second important topic we are talking about is differentiating between QA and QC uh indeed QA and QC are two very important term attesting team or a test engineer should be aware of many people think we are the quality assurance as QA but let me tell you as a tester you are not a QA you are actually a QC of course surprising right so we are actually trying to
tell you those things which we may have never understood in our past experience so far so what is QA and how QA is different from QC QA is basically defined as a process or it's a set of person or people put together who Define how you you can achieve quality in a product now that how can be answered by the techniques the approaches the methods the test cases the amount of testing the number of test cases and the timeline of executing them right so the entire approach definition is done by someone or set of people
called as QA so in simple words test manager is someone who is called as a QA whereas QC is a person or a team of member who performs all the defined you know activi acties by the QA that means writing the test cases preparing the environment preparing the test data executing the test cases logging the defect tracking the defect performing retesting regression testing that means QC is all about the activity driven approach that means performing those activities implementing those approaches is what you call it as quality control so in simple words my test engineer is
a quality control now is that like you might be thinking that is this something we are going wrong with that the whole world is calling engineer test engineer as QA answer is no not absolutely correct why because only the software industry does that not the other Hardware Industries for example if you go to a hardware industry where even a simple screwdriver is made that is being tested but that is tested by a QC not by QA right but why do software Industries making a mistake instead of calling you QC why are they calling you as
a QA because only in software industry you have the Privileges to contribute to the Improvement of the process in Hardware industry I do not ask testers to contribute to the process all I give them is set of test cases or ask them to write the test cases and execute them but when it comes to the process Improvement only QA that is managers take the decision about it but in software industry a tester is allowed to contribute back to the process and add more value in that context the software industry prefers to call you as a
QA engineer rather than a QC so just to differentiate now in software industry we call you as QA engineer and the Qs will be called as QA manager so that's a slight difference what we need to remember and understand so QA defines the process QC implements the process additionally we are all talking about some of the common keywords like error mistake and uh we have failures root causes Etc so let's see exactly the difference between the mistake uh error defect and failure is so first of all I have two words which I'm talking about is
error and mistake now as per istqb mistake and error are exactly the same they're just the synonyms where mistake is a generic word and error is something which is relevant to the programming but what is the definition of mistake now that definition is defined by me so you won't find that as a part of the leus so when humans do anything wrong unintentionally that is what is called as a mistake but that mistake when it is performed in a programming environment I do not call it as a mistake rather prefer to call it as error
so mistake and error are exactly the same when a human does anything wrong unintentionally but just the differen is between the environment what we have so in general world you use mistake as a word whereas in programming world you use as error on the same way if I further continue I do have few words like you know defects which are also called synonymy as false and bugs where the basic definition to defect is it it is a deviation between expected and actual result so it's not that like U it has anything else to do like
fault has a different definition or bug has a different definition in fact bug is a very informal name as per istqb for a defect it's informal name not a formal name and uh the fault is the synonym of defect in the hardware industry so when you're making products like appliances electrical products and all if something goes wrong or something is not working as expected I call it as fault for example if a electrical switch is not working you call it as faulty switch rather than calling it as a defect right but when it comes to
software industry I prefer to call it as defect because that's a more you know relative keyword related to the softwares but the definition Remains the Same when things are not working as expected you call it as a defect whereas the third word here is called as failure the failure is the word which basically is an approach to identify the defect approach to identify the def effect that means when you run a test case and if that test case fails is what I call it as a failure many people go in the discussion towards the release
failure the product failure let me tell you the whole syllabus is talking everything before the release they are not talking about anything after release so we have to limit all our understanding before the release what we do failure is an approach that helps you to find defects that means when you run a test case and if the expected is not equal to actual you call it as a fail and that's put together is the failure as an approach so in other words if I have to use all these keywords together I can make a statement
that a tester is someone who is responsible to conduct as many failures as possible on the system so that defects can be identified and corrected where defects are due to errors or mistakes mistakes can be related to requirements also another important thing what we are covering in the same is that the difference or relationship between uh the error defect failure and root cause now error and defects are not only the cause of failures failures can also be caused by environmental conditions such as when radiations or electromagnetic field uh causes defects in firware a root cause
is basically the real reason behind it so it is the fundamental reason for the occurrence of the problem and it's not necessary that uh root cause is what you see as a defect sometime root cause can be anything for example I was not able to log into Facebook and U I had no internet connection so I was thinking that my login credentials are not working but when I realized the root cause was that I was not connected to Internet so you can very well correlate that the defect and root cost can be totally different from
each other and that could be far far away so a tester has to understand the difference between the error and the root cause or the defect and the root cause because a root cause can be different and can be contributing to multiple other elements of the application so whenever a developer fixes a defect basically that person is fixing the root cause and if the root cause is contributing to further other elements or modules then they may have side effects of these fix and that's where it is very important for a tester to measure the regressions
introduced by these fixes so that's where when the root causes are fixed we look forward to uh conduct a regression testing also just to make sure that the fix of a defect has not introduced anything as a side effect so it is believed that further similar failures or defects can be prevented or their frequency reduced by addressing the root cause such as by removing it so I think put together all we wanted to explain you is that how error defects fault uh failure and root causes are related to each other and how exactly they do
contribute to the overall conduction of testing 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 [Music] learning
