ISTQB FOUNDATION 4.0 | Tutorial 4 | 1.3 Testing Principles | ISTQB Foundation Tutorials | TM SQUARE

Hello friends and greetings for the day welcome back to another tutorial on istqb Foundation level certification we are in chapter one talking about the fundamental soft testing and moving on to the next segment of this chapter that is 1.3 principal soft testing so let's quickly understand what are these principles and how does that get applied to our testing process Al together as a part of this tutorial all we are trying to understand that what are those governing principles of testing which one should follow at most at any point of time during the testing life cycle

so we have seven standard principles what we are talking about the principles what we are referring to is called as of course the very first one is the testing shows presence of defects exhaustive testing is impossible and uh then we have the third one which is early test testing saves time and money the defects can cluster together tests wear out which was earlier called as pesticide Paradox testing is context dependent and absence of defects is a fallacy so let's go deep dive into each one of these principles and try understanding that what these principles are

trying to convey and how does that even apply to testing the very first principle we are talking about is testing shows presence of defect but not their absence which simply means that testing is a process which does not assure you that you can find all possible defects in the system at any point of time no matter you have found any defects or not testing is not an assurance that you have a defect free product because testing can help you find defects the one of the objective of testing is to find defects but at any point

of time whether you found any defects or not it does not guarantee that you have found all possible defects which you had because testing is an endless Journey right and people people should not be overestimating from the OV expecting from the testing as a process by interacting with a application by you know conducting testing on an application while you're trying to find as many defects as possible but at any point of time given that your approaches could be different you may not have all the information what you may need sometime the data is missing sometime

the environment may have a constraint and not every single thing can be actually tested as a part of the testing process thus testing at any point of time can not assure you that you have found all possible defects in the system however at some point of time if you say that we have found 500 defects and tried all possible test cases which is something which is very hypothetical to talk about you may not come up with all combination of data you may not just test everything which you might think about and just because of that

I cannot make a statement that testing can assure you 100% defect free product so in that context the very first principle is dedic dedicated to the meaning of testing that testing is only helpful in finding defects it helps you to detect the presence of defect but does not prove the absence of it moving on to principle number two when we talk about exhaustive testing is impossible all we are talking about is testing a simple application with all possible combinations of inputs with their respective outputs of course in order to test a s simple application let's

take an example here if I'm talking about testing login then login has two fields that is username and password now if I just talk about the four combinations which I can test that is valid username valid password invalid username valid password valid username invalid password and invalid username invalid password quite often we think that the four test cases would be enough to test the system but if you deep dip you realize that invalid may have multiple possibilities thus you may have permutation and combination of these with the valid set of data like 1 is to

1 1 is to 2 1 is to 3 2 is to 1 2 is to2 2 is to 3 and there's no end to it so even 40 test cases may be not enough so in that context we say that hey coming up with all possible combination of these test data and trying out the basic you know set of all the inputs combination is something considered as exhaustive you may not just come up with everything what comes to your mind you rather have to reduce your test cases write only the efficient number of test cases

which are enough at that point of time to validate and gain the required confidence but the question is how would you do that answer is you do have test techniques to reduce the number of test cases but at the same time not compromising on the coverage so that is what the chapter 4 will be and we'll be talking more about that in detail moving on to the principle number three we are talking about static testing or in other words we are saying early testing saves time and money so early testing saves time and money is

all about preventing defects or at least talking about static test testing in this context all a tester is requested to understand is that a defect can be found even in the requirement can be found in the design can be found in the code and that should be done much earlier than the tester case executions so testing is certainly done in two parts like in previous tutorial we understood that it is static and dynamic static helps you to find defects related to work products and dynamic helps you to find defs related to the product so of

course a tester is someone who's responsible to get involved as early as possible in reviewing the documentation what is being written for the project and identify the anomalies written related to that for example if the requirements are published much earlier in the life cycle as a document then a tester is supposed to review the requirements and raise any sort of anomaly related to that by doing so you are identifying the mistakes done by the business analyst or missing information in the requirements at that phe itself which is preventing the bugs or defects to to be

propagated to design development and so on so that's where the objective of this principle is to identify defects as soon as possible and one way the reason why we are saying early testing saves time and money is because it helps you to reduce the cost of fixing it if I find a defect in requirement all I have to do is rectify the requirement but if this missing requirement goes to code and then I'm doing a dynamic level of testing that is integration then I would need more time to get to the root cause and and

then fixing the root cause will be again fixing the requirement itself but it will invite a lot of rework like redesign recode retest so as you see the number of activities increases as I found it later the cost of fixing a defect goes higher when the defect is identified at a later point of time so the earlier you find it it is cheaper to fix the later you find it it is expensive to fix so preventing bugs or defects is more valued today compared to that of finding defects so early testing saves time and money

principle number four is talking about defects clustered together that means defects can be clustered together now can be in the sense like we are not doing it purposefully it may be possible so what do what is that we are talking about here in simple words defects are not evenly distributed it's not necessary that your defects will be evenly distributed between or among modules so it is even possible that defects can get accumulated to one of the module rather than being distributed in all the modules so assume that you have 10 modules to be tested first

few modules like 1 2 3 4 are critical and complex modules indeed everyone including the business analyst the designer the developer will put their 100% effort to make sure that these critical and complex modules do not go wrong so they did all the effort and when it came to testing of course when you tested you did not find any defects which simply means that you may create an illusion that the other modules which are simpler may not have any defect but through this principle all we want to tell you that that maybe a developer or

designer would be overconfident on the simpler modules and make 50 mistakes there what about that so tester does not you know get influenced by the outcome of previous test executions or previous modules execution outcomes a tester is always supposed to be as independent as biased as possible so that they test every dependent thing separately okay and that's where it is very important for a tester to not to be influenced by the execution because defects can cluster together so it's not necessary that defects will be distributed evenly between the modules sometime first nine modules may not

have any defects and the 10th module may have 50 defects so principle number five we are talking about tests wear out which was earlier very popularly known as pesticide Paradox this principle really wanted to convey one of the most important part of testing that it's not necessary that what you have written is going to work forever especially targeting the regression area so say for example I got a module to test and I've written test 10 test cases right when I executed that I did not find any defect being a very confident tester and experienced tester

I felt that this is not possible so I thought of repeating the same execution once again and when I repeated indeed the module was same the test case was same so I will just get the same result that is everything passed if I just go and keep running it several times it does not help me heeld the defect what I'm looking for because I have a strong intuition that generally there are defects here so it may be possible that your test cases are not strong enough or good enough to the to find that defect what

you're looking for in simple words there is no point reiterating a plan which you created in semester 1 to get 90% if after following the plan very strictly you got only 60% it's not necessary that your hard work is not enough sometime your plan the way you created it was only for 60% not for 90% so there is no point following the same plan once again in semester 2 to Target 90% rather tweak the plan make some changes in your plan reduce the number of hours you have Leisure reduce the number of hours when you

play and increase the number of hours to study or change the timings of studies and see that whether the that works and exactly the same thing what you're talking about here if you think that test cases are just passing it does not mean that it's a proof of correctness so in that context you may look forward to revise your test cases especially the regression because regression test suets are just blindly iterated every time we make any changes thus the regression test Suite Remains the Same which we created long back so over a period of time

when the product evolves the regression test Suite should also evolve moving to the the next principle that is testing is context dependent all we are trying to say here is that like a testing does not have a universally accepted approach or strategy that means there's no single approach to test all types of applications as the products are different from each other the strategy or approach to test that should also be different for example a safety critical system is not tested the way an e-commerce website is tested e-commerce website is just for shopping products does have

their own set of criticality and uh risk involved but when I talk about safety critical devices things like Automotive elevators escalators right where human lives are involved I totally understand that my Approach of testing that would be completely different so two different products are not tested with the same approach now what are the approaches how I can Define my set of approach for a project answer is we will discuss this in more detail in chapter 5 so right now this is just enough to understand that two different products are not tested with the same approach

and they have different approaches to test them finally talking about the last principle absence of defects fallacy U looks like very critical terminology to understand absence of defect is also a failure that is what the principle says now how is that even a failure absence of defect is a failure that means you just removed all the defects from the system does that mean it could be a failure yes absolutely it is possible why because we are test engineers and we just don't find and fix effects we are equally responsible to meet the requirements does that

mean the developer and designer may not be following it yeah if they are following it then why are we here as a tester I do understand that designers and developers are also taking care of the requirements but they're not testing it as for the requirement they're testing it more from a technical driven point of view so it'll be not so good to say that they're not following the requirements they are indeed following the requirements to implement it but they are not testing it or they are not even worried about that whether this works as per

the user needs and expectation or not but we as a tester are held responsible to understand the needs of the user and customer expectations and to validate that that means we are not here only to find and fix def at the end the product which is built is useless to the customer that does not help us so as a tester we have full responsibility on meeting the requirements or testing the product according to the given requirements okay so we just don't uh test find defs and fix them which may not make any sense at some

point of time if the product built is useless to the customer so one principle dedicated to let you know that the requirements are equally important for tester we are not driven by code we are not driven by Design we are all we are driven by is the set of requirements provided to us so testers should always be worried about that however we are finding defects and fixing them but does that meet the given requirement or does that help a user to use the system 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]