Seven Principles of Testing

hello everyone welcome to session three of module one seven principles of testing in this session i'll explain you one by one the seven principles of testing so let's get started so there are seven testing principles which offer general guidelines for um common for all testing so seven testing principles are testing shows the presence of defect exhaustive testing is impossible then third principle is early testing fourth principle says defect clustering fifth principle says pesticides paradox sixth principle is testing is context dependent and seventh and last principle is absence of error fallacy so we'll understand these principles one by one so principle one testing shows the presence of defects what does it mean so testing can show that defects are present but testing cannot prove that there are no defects in the software so this principle means that when you are testing something when you are testing a software you find defects and that way you can say that there are defects in the software but you can never claim you can never say you cannot prove that there are no defects in the software even if in the later cycles when you when you stop you know finding critical defects but still when the software goes into production there might be some environmental um changes or in one mental configuration or hardware configuration in the production environment that might cause the software to fail so you can never prove that there are no defects in the software a software can fail anytime so testing reduces the risk of failure but it can never prove that your software that you have tested is hundred percent defect free testing reduces the probability of undiscovered defects remaining in the software but even if no defects are found it does not prove it is not a proof of correctness okay so testing reduces the probability of undiscovered effects so once you are once you start testing you find more and more defects and in the later phases of the software development like you know in the testing cycle you start finding very less defects because you have almost discovered more of most of the obvious defects but still it is not proof of the correctness that um your software is completely correct and defect free so for example let's take an example um to understand this and in istqb book there is very good example about explaining this principle um so if you only see white swans you can say that all swans are white but as soon as you see one black swan so you cannot say all swans are white so similarly in software context if you are executing test cases and you have executed hundreds of test cases and you did not find any defect in those test cases till now that you have executed you still cannot say that there are no defects in the software because there there might be defects in in other areas of the software in other execution or other scenario that you would be you know testing in in future so it doesn't depend i mean as soon as you find one bug you can say that software is not defect free so just understand the context of the swans that as soon as you see the black swan you cannot say that all sounds are white so similarly as soon as you find one defect in a software you cannot say that software um is defect free so that's principle number one um the testing shows the presence of defects but it doesn't prove that there are no defects in the software principle 2 says exhaustive testing is impossible why is exhaustive testing impossible we will understand by taking certain examples and see why you cannot test the software exhaustively testing everything all combinations of inputs and preconditions is not feasible except for trivial cases or very small cases so if you have very small scenarios when you just want to cover all the combinations or input you can do that but for complex combinations it's not possible to cover all the preconditions or all the input conditions for testing instead of exhaustive testing we use risks and priorities to focus testing efforts so we do not do exhaustive testing we prioritize um our test cases our test efforts based on the risks so if a module has high risk so we prioritize um our testing based on that and instead of testing everything we used proper test design techniques um to test the boundary conditions like boundary value analysis equivalence partitioning rather than testing everything you just find the valid partition and invalid partition apply boundary value analysis um test conditions there and test it rather than testing all the input combinations and preconditions so based on the risk and priorities you need to focus the testing efforts so why exhaustive testing is impossible let's take an example for this so can you imagine how many tests would you need to do complete test for a one digit numeric field so suppose on a on a web page you just have a text field which just accepts one digit numeric field how many test cases can can you think of for that single scenario if you are doing an exhaustive testing so one digit numeric field will be having 10 inputs of the valid uh numbers that is 0 to 9 so valid values 10 numbers then invalid scenarios could be 26 lowercase characters 26 uppercase characters and then some of the special characters and punctuation and blank value so if you sum up these it comes somewhere around 68 to 70 tests for this example just just one digit on a text on a web page where you need to if you are going for exhaustive testing you will be having 68 to 70 tests to do that is that is still that you you can do that if you want but it is still 70 test cases and not advisable to do those test cases at all there are better techniques to design your test cases and achieve the coverage that you you want with those test cases if you do better test design for for these scenarios then example two so if we take an example where one screen has 15 input field and each having five possible values then to test all of the valid input combinations you would need 5 to the power 15 test which comes to the the huge number you can see on the screen so each input there are 15 input field each input field accepts five possible values so you can see the number of combinations that you need to execute to test to do exhaustive testing of that one web page and you can imagine um in banking and e-commerce you know websites there are in every page there are you know 10 to 15 input fields which accept more than five you know values so it is very unlikely that the project time scales would allow for this number of tests to execute okay so that is why principle two says exhaustive testing is impossible you cannot test all the input conditions input combinations and preconditions for the software in order to get similar kind of coverage you need to adopt better test design techniques like equivalence partitioning boundary value analysis to design your test cases so that you get best coverage for for the software principle 3 says early testing testing activity should start as early as possible in the software development lifecycle and should be focused on defined objectives so early testing is the key for better quality software if you do not start testing early the quality of software is definitely going to be affected you are not you cannot expect expect a better quality software if you do not start testing early okay so this is pretty self-explanatory these that testing activity should start as early as possible in his dlc so early testing like early test design and review activities should start because it's cheap to find and fix defects in initial phases of sdlc so once sdlc starts once the requirements gathering starts once the design phase starts once the coding starts so testing should be involved from those initial phases of sdlc from the requirements itself so that if there is any gap in the requirement the requirements are not clear the requirements are not testable testers can provide their input in into the [Music] into the requirement or into the design and that can be rectified in the initial phases itself rather than finding defects in the testing phase and then again going back and changing requirement changing design which which costs you a lot of money and a lot of time already wasted so early testing is the third principle like so your testing should start as early as possible in sdlc after development objective should be to find as many integration system defects as you can so um since this the testing should start as early as possible so most of the requirements should be requirement defect or design defect should be able to tester should be able to found fine in the early phases itself and the objective of each phase after after development is done should be to find as many integration or system defects as as the testers can the user acceptance testing or uat testing object uat objective should be to find out if the software meets end user requirements so these are the defined objectives of [Music] different phases different testing phases so in the early testing in the early phases of stlc testing should focus on um finding any design or requirement issues in in the in the functional testing and system testing phases um testing should focus on finding as many integration or system uh defects as test team can in user acceptance testing phase the focus should be to find out if the software meets end-user requirements or not then in maintenance testing objective should be to ensure that there are no new defects introduced in the system by changing software or fixing the defects so that is known as regression testing so in maintenance testing if there are there there is any change in done um change done in the software or fixtures done in the software so the focus should be to ensure that there are no new defects introduced into the software and if we continue testing production use main objective should be to assess system availability and reliability so the main objective of testing a production environment is to ensure that the system is always available and reliable for the end user so principle 3 says start testing as early as possible do not delay the testing process to later phases otherwise it will be again a huge amount of effort in rectifying those design or requirement issues and then again testing it principle 4 says defect clustering so what does defect clustering means it means that a small number of modules contain most of the defects discovered during pre-release testing or show most operational failures so defect clustering means that there is in any software there are a small chunks or small modules in in that software which have most number of defects are in those modules so most of the testers have noticed that defects tend to cluster why is why it happens is because defect clustering happens because an area of code is complex and tricky so if an area of code is complex or tricky it it will be implemented that there will be complexity involved in implementing that that area or code and because of that complexity involved there will be more number of defects around that complex area then changing software and other products tend to cause knock-on defects so this is also seen in um in the software that whenever you change software or whenever you fix some defects in the software it causes knock-on defect causes more defects around the area so that's the that's the another cause of defect clustering then tester should use this information when making their risk assessment for planning the test and focus on known hotspots so defect clustering information like if you most of the testers would know what the complex areas complex modules of the software and they should take this information and they should use this information in doing risk assessment for planning their future test cases because they know the hot spots that these are the main areas these are the main modules where most of the defects were in previous release and there there are changes coming around in these modules and so there is high risk around these modules and so we should the tester should focus proper test cases around those hotspots or those modules to test this test that thoroughly in the principle five says pesticides pesticide paradox what does this mean if the same tests are repeated over and over again eventually the same set of test cases will no longer find any new bugs so suppose you have a test suite which has 100 test cases and in every every build cycle every build that you get from um from the developers you execute same set of test cases without any modification for another say five to six cycles you are not going to find any new defect in those those test cases because whatever defects were associated with those test cases have already been found fixed and rectified so same set of test cases will no longer find any new bugs for you so that is uh what pesticide paradox means it's it's taken from um from the actual so suppose you are using same sort of pesticide for um for agriculture to kill the to kill the insects of the crops so eventually after you know like two three years um those insects um are are no longer uh being affected with the same kind of pesticide so you need to change that you need to change the pesticide to um to be to [Music] be more effective on those kind of insects for the crop so similarly for the test cases you need to modify the test cases again and again in order to find new bugs in software so same set if same set of test cases repeated over and over again you won't be able to find any new bugs in later cycles so to overcome this pesticide paradox the test cases need to be regularly reviewed and revised and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects so in order to overcome this pesticide paradox you need to update your test cases uh you revise your test cases and new test cases need to be added in that test suite so that you can you should be able to you know like find new defects around the software so as the hotspots for bugs get cleaned up we need to move our focus elsewhere because some same set of tests would not find any more defect so if there are hotspots like the modules which had which are complex and which have most number of failures once those hotspots are being cleaned up and the test cases that you have are all passed around those hot spots then those same test cases if you execute again in the next next cycle it's very difficult to find any new defects around those hot spots because those defects have already been fixed and passed the test cases so same set of test cases will not find any more defects for those hotspots so over time focus should be changed from finding quoting bugs to looking at like requirement bugs or design design issues of the software then principle 6 says testing is context dependent testing is done differently in different contexts for example safety critical software is tested differently from an e-commerce site so testing is context dependent means that it testing is done differently in different contexts safety critical software will be tested differently from an e-commerce website so not all software systems carry the same level of risk so different approach is taken to test softwares in different context so because safety critical applications have more risk associated with them e-commerce site has lesser risk because it doesn't harm um it doesn't risk any uh life human life of so because of that safety critical software is tested the context or the the way the safety critical software will be tested is different from the e-commerce side so for example if you have a family website where you just keep the information of your family members and details of your family members ad hoc testing is enough no tool is used just manual testing is enough for that but if you're testing an e-commerce application so see how context changes um so family website is also a website e-commerce applications um is is also a website your shopping website so most more testing needs to be done for this website's functional non-functional attributes and different tools are also used and general company procedures and guidelines are followed so since the context of family website and e-commerce application are different that's why the testing done for e-commerce applications is different from the family website so similarly if you take traffic control system testing is done completely in different way and different set of tools and technologies are used to test traffic control system and much more strict testing guidelines need to be followed strict entry and exit criteria needs to be followed for traffic control system because it's it's very critical system and human lives are dependent on this traffic control system it can cause severe if there are there are failures in the traffic control system it can cause severe um damage to property and life of the people so principle 6 says testing is context dependent because software are different so based on the context in which for which you are developing the software or testing the software you're testing the way of testing that software the tools that you use the software for to test that software will be different now seventh and last principle absence of error for lazy what does this mean is fixing and finding defects does not help if the system built is unusable and does not fulfill the user needs and expectations so if you are finding if you're testing a software you are finding defects all the defects are thing fixed and your software is working perfectly fine all the performance is good um you're getting good response from the software that you are testing and it doesn't fail at all it's very good quality but it's not usable for the end user it it's not what an end user wanted then it then it's of no use for the end user so even if there are no errors in the software it it does not fulfill the user needs and it's unusable so the customer who buys the software does not bother about number of defects until software directly affects them and is unstable to use so they are more interested in software fulfilling their requirements and does what they want it to do okay so absence of error policy means um that you can feel that software is doesn't have doesn't fail it doesn't have any major issues major defects it has good response time but if it is not usable it is of no use for the end user okay so that's what um principle 7 says so the software that you're delivering should be should meet end user needs and expectations it should be defect free it should be um should have good performance and it should be should fulfill the end user needs and expectations so to conclude in this session we learned seven principles of testing and understood in detail what all these seven test seven principle of testing means so testing shows the presence of defect it does not show that there are no defects in the software exhaustive testing is impossible you cannot test all the input combinations of the software early testing means you start your software testing activities as early as possible in software development life cycle defect clustering means there are some modules in the software which are complex or not implemented in a right way which contain the maximum number of defects in software in pesticide paradox if you are using same number of test cases same test cases again and again in your future test cycles you are not going to find any new defects in future unless until you modify and update your test cases with new test cases and new input data then testing is context dependent so testing is done differently in different context and e-commerce website will be tested differently from a safety critical or air traffic control system then absence of error policy is the last principle which says that the software that you're delivering should be usable even if it has no defects and it it does not fail if it is not user friendly and if it is not um what an end user wants then it makes no sense to deliver that software so the software should be easy to use defect free and should do what an end user wants to do so these are all seven principles of testing thank you

hello everyone welcome to session three of module one seven principles of testing in this session i&#39;ll explain you one by one the seven principles of testing so let&#39;s get started so there are seven testing principles which offer general guidelines for um common for all testing so seven testing principles are testing shows the presence of defect exhaustive testing is impossible then third principle is early testing fourth principle says defect clustering fifth principle says pesticides paradox sixth principle is testing is context dependent and seventh and last principle is absence of error fallacy so we&#39;ll understand these principles one by one so principle one testing shows the presence of defects what does it mean so testing can show that defects are present but testing cannot prove that there are no defects in the software so this principle means that when you are testing something when you are testing a software you find defects and that way you can say that there are defects in the software but you can never claim you can never say you cannot prove that there are no defects in the software even if in the later cycles when you when you stop you know finding critical defects but still when the software goes into production there might be some environmental um changes or in one mental configuration or hardware configuration in the production environment that might cause the software to fail so you can never prove that there are no defects in the software a software can fail anytime so testing reduces the risk of failure but it can never prove that your software that you have tested is hundred percent defect free testing reduces the probability of undiscovered defects remaining in the software but even if no defects are found it does not prove it is not a proof of correctness okay so testing reduces the probability of undiscovered effects so once you are once you start testing you find more and more defects and in the later phases of the software development like you know in the testing cycle you start finding very less defects because you have almost discovered more of most of the obvious defects but still it is not proof of the correctness that um your software is completely correct and defect free so for example let&#39;s take an example um to understand this and in istqb book there is very good example about explaining this principle um so if you only see white swans you can say that all swans are white but as soon as you see one black swan so you cannot say all swans are white so similarly in software context if you are executing test cases and you have executed hundreds of test cases and you did not find any defect in those test cases till now that you have executed you still cannot say that there are no defects in the software because there there might be defects in in other areas of the software in other execution or other scenario that you would be you know testing in in future so it doesn&#39;t depend i mean as soon as you find one bug you can say that software is not defect free so just understand the context of the swans that as soon as you see the black swan you cannot say that all sounds are white so similarly as soon as you find one defect in a software you cannot say that software um is defect free so that&#39;s principle number one um the testing shows the presence of defects but it doesn&#39;t prove that there are no defects in the software principle 2 says exhaustive testing is impossible why is exhaustive testing impossible we will understand by taking certain examples and see why you cannot test the software exhaustively testing everything all combinations of inputs and preconditions is not feasible except for trivial cases or very small cases so if you have very small scenarios when you just want to cover all the combinations or input you can do that but for complex combinations it&#39;s not possible to cover all the preconditions or all the input conditions for testing instead of exhaustive testing we use risks and priorities to focus testing efforts so we do not do exhaustive testing we prioritize um our test cases our test efforts based on the risks so if a module has high risk so we prioritize um our testing based on that and instead of testing everything we used proper test design techniques um to test the boundary conditions like boundary value analysis equivalence partitioning rather than testing everything you just find the valid partition and invalid partition apply boundary value analysis um test conditions there and test it rather than testing all the input combinations and preconditions so based on the risk and priorities you need to focus the testing efforts so why exhaustive testing is impossible let&#39;s take an example for this so can you imagine how many tests would you need to do complete test for a one digit numeric field so suppose on a on a web page you just have a text field which just accepts one digit numeric field how many test cases can can you think of for that single scenario if you are doing an exhaustive testing so one digit numeric field will be having 10 inputs of the valid uh numbers that is 0 to 9 so valid values 10 numbers then invalid scenarios could be 26 lowercase characters 26 uppercase characters and then some of the special characters and punctuation and blank value so if you sum up these it comes somewhere around 68 to 70 tests for this example just just one digit on a text on a web page where you need to if you are going for exhaustive testing you will be having 68 to 70 tests to do that is that is still that you you can do that if you want but it is still 70 test cases and not advisable to do those test cases at all there are better techniques to design your test cases and achieve the coverage that you you want with those test cases if you do better test design for for these scenarios then example two so if we take an example where one screen has 15 input field and each having five possible values then to test all of the valid input combinations you would need 5 to the power 15 test which comes to the the huge number you can see on the screen so each input there are 15 input field each input field accepts five possible values so you can see the number of combinations that you need to execute to test to do exhaustive testing of that one web page and you can imagine um in banking and e-commerce you know websites there are in every page there are you know 10 to 15 input fields which accept more than five you know values so it is very unlikely that the project time scales would allow for this number of tests to execute okay so that is why principle two says exhaustive testing is impossible you cannot test all the input conditions input combinations and preconditions for the software in order to get similar kind of coverage you need to adopt better test design techniques like equivalence partitioning boundary value analysis to design your test cases so that you get best coverage for for the software principle 3 says early testing testing activity should start as early as possible in the software development lifecycle and should be focused on defined objectives so early testing is the key for better quality software if you do not start testing early the quality of software is definitely going to be affected you are not you cannot expect expect a better quality software if you do not start testing early okay so this is pretty self-explanatory these that testing activity should start as early as possible in his dlc so early testing like early test design and review activities should start because it&#39;s cheap to find and fix defects in initial phases of sdlc so once sdlc starts once the requirements gathering starts once the design phase starts once the coding starts so testing should be involved from those initial phases of sdlc from the requirements itself so that if there is any gap in the requirement the requirements are not clear the requirements are not testable testers can provide their input in into the [Music] into the requirement or into the design and that can be rectified in the initial phases itself rather than finding defects in the testing phase and then again going back and changing requirement changing design which which costs you a lot of money and a lot of time already wasted so early testing is the third principle like so your testing should start as early as possible in sdlc after development objective should be to find as many integration system defects as you can so um since this the testing should start as early as possible so most of the requirements should be requirement defect or design defect should be able to tester should be able to found fine in the early phases itself and the objective of each phase after after development is done should be to find as many integration or system defects as as the testers can the user acceptance testing or uat testing object uat objective should be to find out if the software meets end user requirements so these are the defined objectives of [Music] different phases different testing phases so in the early testing in the early phases of stlc testing should focus on um finding any design or requirement issues in in the in the functional testing and system testing phases um testing should focus on finding as many integration or system uh defects as test team can in user acceptance testing phase the focus should be to find out if the software meets end-user requirements or not then in maintenance testing objective should be to ensure that there are no new defects introduced in the system by changing software or fixing the defects so that is known as regression testing so in maintenance testing if there are there there is any change in done um change done in the software or fixtures done in the software so the focus should be to ensure that there are no new defects introduced into the software and if we continue testing production use main objective should be to assess system availability and reliability so the main objective of testing a production environment is to ensure that the system is always available and reliable for the end user so principle 3 says start testing as early as possible do not delay the testing process to later phases otherwise it will be again a huge amount of effort in rectifying those design or requirement issues and then again testing it principle 4 says defect clustering so what does defect clustering means it means that a small number of modules contain most of the defects discovered during pre-release testing or show most operational failures so defect clustering means that there is in any software there are a small chunks or small modules in in that software which have most number of defects are in those modules so most of the testers have noticed that defects tend to cluster why is why it happens is because defect clustering happens because an area of code is complex and tricky so if an area of code is complex or tricky it it will be implemented that there will be complexity involved in implementing that that area or code and because of that complexity involved there will be more number of defects around that complex area then changing software and other products tend to cause knock-on defects so this is also seen in um in the software that whenever you change software or whenever you fix some defects in the software it causes knock-on defect causes more defects around the area so that&#39;s the that&#39;s the another cause of defect clustering then tester should use this information when making their risk assessment for planning the test and focus on known hotspots so defect clustering information like if you most of the testers would know what the complex areas complex modules of the software and they should take this information and they should use this information in doing risk assessment for planning their future test cases because they know the hot spots that these are the main areas these are the main modules where most of the defects were in previous release and there there are changes coming around in these modules and so there is high risk around these modules and so we should the tester should focus proper test cases around those hotspots or those modules to test this test that thoroughly in the principle five says pesticides pesticide paradox what does this mean if the same tests are repeated over and over again eventually the same set of test cases will no longer find any new bugs so suppose you have a test suite which has 100 test cases and in every every build cycle every build that you get from um from the developers you execute same set of test cases without any modification for another say five to six cycles you are not going to find any new defect in those those test cases because whatever defects were associated with those test cases have already been found fixed and rectified so same set of test cases will no longer find any new bugs for you so that is uh what pesticide paradox means it&#39;s it&#39;s taken from um from the actual so suppose you are using same sort of pesticide for um for agriculture to kill the to kill the insects of the crops so eventually after you know like two three years um those insects um are are no longer uh being affected with the same kind of pesticide so you need to change that you need to change the pesticide to um to be to [Music] be more effective on those kind of insects for the crop so similarly for the test cases you need to modify the test cases again and again in order to find new bugs in software so same set if same set of test cases repeated over and over again you won&#39;t be able to find any new bugs in later cycles so to overcome this pesticide paradox the test cases need to be regularly reviewed and revised and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects so in order to overcome this pesticide paradox you need to update your test cases uh you revise your test cases and new test cases need to be added in that test suite so that you can you should be able to you know like find new defects around the software so as the hotspots for bugs get cleaned up we need to move our focus elsewhere because some same set of tests would not find any more defect so if there are hotspots like the modules which had which are complex and which have most number of failures once those hotspots are being cleaned up and the test cases that you have are all passed around those hot spots then those same test cases if you execute again in the next next cycle it&#39;s very difficult to find any new defects around those hot spots because those defects have already been fixed and passed the test cases so same set of test cases will not find any more defects for those hotspots so over time focus should be changed from finding quoting bugs to looking at like requirement bugs or design design issues of the software then principle 6 says testing is context dependent testing is done differently in different contexts for example safety critical software is tested differently from an e-commerce site so testing is context dependent means that it testing is done differently in different contexts safety critical software will be tested differently from an e-commerce website so not all software systems carry the same level of risk so different approach is taken to test softwares in different context so because safety critical applications have more risk associated with them e-commerce site has lesser risk because it doesn&#39;t harm um it doesn&#39;t risk any uh life human life of so because of that safety critical software is tested the context or the the way the safety critical software will be tested is different from the e-commerce side so for example if you have a family website where you just keep the information of your family members and details of your family members ad hoc testing is enough no tool is used just manual testing is enough for that but if you&#39;re testing an e-commerce application so see how context changes um so family website is also a website e-commerce applications um is is also a website your shopping website so most more testing needs to be done for this website&#39;s functional non-functional attributes and different tools are also used and general company procedures and guidelines are followed so since the context of family website and e-commerce application are different that&#39;s why the testing done for e-commerce applications is different from the family website so similarly if you take traffic control system testing is done completely in different way and different set of tools and technologies are used to test traffic control system and much more strict testing guidelines need to be followed strict entry and exit criteria needs to be followed for traffic control system because it&#39;s it&#39;s very critical system and human lives are dependent on this traffic control system it can cause severe if there are there are failures in the traffic control system it can cause severe um damage to property and life of the people so principle 6 says testing is context dependent because software are different so based on the context in which for which you are developing the software or testing the software you&#39;re testing the way of testing that software the tools that you use the software for to test that software will be different now seventh and last principle absence of error for lazy what does this mean is fixing and finding defects does not help if the system built is unusable and does not fulfill the user needs and expectations so if you are finding if you&#39;re testing a software you are finding defects all the defects are thing fixed and your software is working perfectly fine all the performance is good um you&#39;re getting good response from the software that you are testing and it doesn&#39;t fail at all it&#39;s very good quality but it&#39;s not usable for the end user it it&#39;s not what an end user wanted then it then it&#39;s of no use for the end user so even if there are no errors in the software it it does not fulfill the user needs and it&#39;s unusable so the customer who buys the software does not bother about number of defects until software directly affects them and is unstable to use so they are more interested in software fulfilling their requirements and does what they want it to do okay so absence of error policy means um that you can feel that software is doesn&#39;t have doesn&#39;t fail it doesn&#39;t have any major issues major defects it has good response time but if it is not usable it is of no use for the end user okay so that&#39;s what um principle 7 says so the software that you&#39;re delivering should be should meet end user needs and expectations it should be defect free it should be um should have good performance and it should be should fulfill the end user needs and expectations so to conclude in this session we learned seven principles of testing and understood in detail what all these seven test seven principle of testing means so testing shows the presence of defect it does not show that there are no defects in the software exhaustive testing is impossible you cannot test all the input combinations of the software early testing means you start your software testing activities as early as possible in software development life cycle defect clustering means there are some modules in the software which are complex or not implemented in a right way which contain the maximum number of defects in software in pesticide paradox if you are using same number of test cases same test cases again and again in your future test cycles you are not going to find any new defects in future unless until you modify and update your test cases with new test cases and new input data then testing is context dependent so testing is done differently in different context and e-commerce website will be tested differently from a safety critical or air traffic control system then absence of error policy is the last principle which says that the software that you&#39;re delivering should be usable even if it has no defects and it it does not fail if it is not user friendly and if it is not um what an end user wants then it makes no sense to deliver that software so the software should be easy to use defect free and should do what an end user wants to do so these are all seven principles of testing thank you

Transcript for:Seven Principles of Testing

Transcript for:
Seven Principles of Testing