hello everyone welcome to session 2 of istqb foundation level and software testing training why is testing necessary software testing is necessary because a defect in software can cause harm to person environment or a company so suppose let's take an example of road traffic control system that's a software being developed by some company and if there is a defect before after deploying that air traffic control if it is not tested properly and there is a defect in the in the software it might cause road accidents to occur it might cause even death of the person so that's that's harm for the person person's life is at risk and that's harm for the company the other reason why testing is necessary is a defect can cause loss of money time or business so suppose there are big e-commerce website nowadays like ebay amazon have you ever thought if those sites are down for even for a few few hours what is the revenue loss these companies face so in case the there is a defect for these e-commerce sites and these are down for a few hours the the business loss the loss of money involved for amazon and ebay is huge it's in millions so a defect for these e-commerce website can cause lots of money time and business third point why we do testing is because testing improves software quality so once you start finding defects or once you find that all the requirements design is proper and there are few issues or defects in the release software you are more confident that the software that is being released is of good quality and the fourth thing is testing reduces the risk so there is always a risk involved in a software that is being released so that risk is reduced when you test something properly when you test the modules of the software properly when you test the software integrated software properly the the risk involved for the software as a whole is reduced because you find defects beforehand and those defects are fixed by developers and re-tested before the software is actually released into the market why do we test something so we test something to ensure that it is okay be it software be any electronic device or your mechanical device your auto mobile we test anything any any kind of device or software to ensure that it functions properly it functions at it is expected to function testing is necessary because we all are human beings and human beings make mistakes during development so if you are already working in i.t companies you you know that while development there are a lot of a lot of errors or mistakes being made during the development process or or even during the requirements gathering or during the design phases so testing is necessary because all human we all are human beings and there are errors introduced or mistakes introduced into the process so we test something to ensure that those mistakes are being caught well in advance then some human errors do not impact much on our day-to-day life and can be ignored however some errors are so severe that they can break the whole system or software so suppose you are just testing your family website or or your personal blog and there are some errors in the web server or on the front end that doesn't matter much it only affects you and some of your family members but if you are if the error is made in air traffic control software or road traffic control software it might impact human lives so that's why it the human errors can impact some of the human errors depending on the kind of software or system that is being developed can break the whole system or software so in such situations you need to take care that such errors are caught well in advance before deploying the software into the production environment so these hospital applications the application the software that is used in the intensive care units air traffic controllers road traffic softwares these are all critical applications so these should be tested well in advance to find out all the errors which could have been introduced during the during the development process before actually deploying the software into the production environment now let's take software systems context so like i told um an error in your personal blog does not impact anyone else it's it's just about you your family some of your friends maybe so it doesn't doesn't affect anybody else it doesn't risk anybody else's life or it's it's not a critical application an error in a business website may put off the company as it looks unprofessional so if you are accessing some company website and it's down or there are you know very basic uh grammatical errors spelling errors on the on the business website so it looks very unprofessional and it may put off the company then third thing is net banking websites or atm should be thoroughly tested to maintain bank credibility so suppose you are net banking customer of now bnz and you're trying to do some transactions and you're not able to perform the transaction so it it's very i mean for the bank credibility it's not good you are trying to use atm you try it on one atm it's not working you went to another atm it's again not working due to some software errors so these kind of errors in the software are affect the bank credibility a lot so in order to maintain bank credibility these net banking applications atms your mobile applications mobile banking applications needs to be always up and running to maintain a bank credibility otherwise the customer you will the bank will lose the customers if your website is down every week for four five hours you lose bank credibility and the customers will start moving to some other banks then air traffic control system is very critical system which needs to be thoroughly tested before doing a live deployment because all the air traffic is dependent on it and if there is one minor error in that system it might cause a plane to crash and hundreds of lives are at risk because of that then what are the causes of software defects what exactly causes uh the software defects so the first thing is people may make mistake during requirement gatherings okay so we all are human beings and we can make mistake during any phase of the development of anything of beat electronic device or audio software so we may make a mistake during requirements gathering phase we we missed some of the important requirement points that should have been there in the requirement specification then people may make mistake during the design then there there may be mistakes during the coding phase as well okay so due to these mistakes there can be flaws in software and these flaws are known as defects or bugs so the main cause of software defects is the mistakes that are made in any phase of the software development life cycle be the requirements gathering phase be the design phase a defect can get introduced in the high level design phase a defect can get introduced in the lower level design phase a defect may get introduced during the coding if if a person is not very much experienced in coding or development he might make you know basic errors during the coding or if the design is not proper then even whatever right coding you do for for that specific design doesn't doesn't makes it that there will be definitely defects because design itself is not fine all right so due to these mistakes there can be flaws in software and these flaws are known as defects or bugs then when do defects arise so here i have made a figure which which will explain how the defects arise so i have four requirements here requirement one two three and 4. and as we saw in the previous slide that defects can arise in any phase and defects arise due to the mistakes made by person into the requirements gathering phase into the design phase or into the development phase all right so if we talk about requirement one a person who is gathering requirement a business analyst who is gathering the requirements gathered the correct requirement then as per the correct requirement the person who is designing who is doing the high level design of the solution or the software he made the correct design then the person or the team which is building the software to meet the correct design if they build it correctly then the software will work as expected after testing the software software works as expected so in require in the in the first case in the requirement one correct software will be delivered but if you take an example of requirement two business analyst gathered proper correct requirement then in the second phase that is the design phase correct design has been made for those requirements but during the development phase that is the third phase of sdlc if there are mistakes in coding mistakes in development so mistakes in build then software will be having defects in it because the development that has been done in step three in development phase does not meet the correct design so there will be defects but those defects are the correctable defects they can be caught by a software testing team during testing and those defects will be raised and assigned to developer and he'll fix it and you will retest and those defects can be corrected so you'll in requirement too you can correct those defects in the requirement three you have the correct requirement from business analyst then in the second phase in the design phase there are mistakes in the design itself the design that has been made by the technical architect is not right there are mistakes in the design itself in the third phase in the development phase the software is built as per design okay because there are mistakes in design but the developer is developing as per design developer will develop the code as per the design it doesn't he he won't go and change the design so he develops as per the design but since there are mistakes in design there will be software defects so software has design defects because design is not right and built a software has been built as per design so software will be having design defects in my recent experience i have seen an extreme issue with the design i was testing an e-commerce portal there was a checkout being implemented checkout was designed improperly and because of that the developers who built the checkout functionality of an e-commerce website they built it as per design and now in the checkout functionality there are so many errors if the fixed one there are two other new defects that arise in the checkout functionality so what they have to do is they have to rebuild the design so now in in the same software that i was testing recently they have to go back redesign that checkout functionality build it again as per the design and then software design defects only then software design defects can be resolved then in requirement four if there are mistakes in the requirement itself requirements are not being gathered properly by the business analyst there are mistakes there then if a software is designed to meet the requirement so that's where i mean if there are mistakes from the early phases it's more severe so if there are mistakes in requirement and you design to meet those requirement then the build or the development is done as per the design then the wrong software completely wrong software will be delivered and even and these defects won't be even caught by the i.t team or the test team because you are a test a tester is finding defects as as per the requirements whatever requirements you see whatever design that you that you have you are not you're not sure whether the requirement that are being um given to you or there are the mistakes in the requirement um are are not valid so if it is built if the software is built as per the requirement as per the design then software test test team cannot find those hidden defects find those defects these defects can be found only during the user acceptance test phase when end user or the stakeholders when they test and they figure out that no this is this is not what we required this is not what our requirement was so in the requirement for defects are found in user acceptance test phase so defects in in these all these four requirements you can see defects can arise in any phase of software development they can arise in requirements in the design phase in development phase in any phases of the software development life cycle what is the cost of defects so in the previous slide we have seen that a software defect can arise in any phase of the software development life cycle and the later you find the defect in the software development life cycle the more the cost is to fix that defect so if you see the graph here on the y-axis use is is the cost and on the x-axis is your software development lifecycle with the requirements phase is the first phase then design coding testing production okay so if a defect is found during the requirements phase it's it costs very less to fix it because you just need to modify the requirements accordingly and because you have not designed for it you have not put time and effort in coding it and testing it but if the defect passes on from the requirements to design and it's found at the design phase that the requirements are not right it will cost you more similarly as as it moves to coding testing and production the cost of finding defects and fixing defects increases over time so suppose there is a defect in requirement and you build and you designed as per the requirement coding done as per the design and the defect is found during the testing that will require your requirement change completely or your design change completely so you you have wasted your coding time effort your design your your test architect will uh technical architect will have to you know redesign requirements have to be you know gathered again redesign coding again and then testing again so the cost of finding defects will increase exponentially as as soon as you know you move further in your software development life cycle if a defect is found in a production environment then it will cost even more and if if a production environment defect is is a design defect or it's a it's uh it's a requirement issue then you just need to modify the requirement design code and again test again and then again deploy so cost of defect is much much more as you move later into the software development lifecycle so it's very easy to fix to find and fix defects in the early phases of software development life cycle so that's why it is said that it is always advised start test early so as soon as you start testing as early as you start a testing in your software development life cycle the more quality product you build then what is the role of software testing in software development maintenance and operations testing is important in development and maintenance to identify defects and bugs testing identifies any defects or bugs in a software and once those defects or bugs are identified they can be fixed and a software without those basic defects or bugs can be released a good quality software can be released testing reduces risk of software failures in operation operational environments so what test team does is test team deploys the software exactly as per the optional operational environment before actually migrating it to the production environment and then they populate the software with the test data and see how how the software behaves in the in the test environment so it reduces the risk of software failures in the operational environment and testing improves quality of the software so once you once test team starts testing they start identifying defects those defects are fixed retested and then it gives it gives a good confidence and after those defects are fixed found and fixed so it gives a good confidence and improves quality of the software and testing is also required as part of a contractual agreement or legal agreement okay so suppose some company is developing air traffic control root road traffic control software then testing is the basic it's a part of contractual it's it's part of the release it's an agreement it's a legal requirement to to go through all those um predefined testing criterias and the software should pass those predefined testing criterias before it is being deployed into the operational or production environment so any so any high risk associated area if you're developing any high risk associated software that has contractual agreement or legal requirements to do testing so testing is involved in those kind of high risk associated applications very much and testing and quality so testing helps to measure software quality when you are testing an application you find defects those defects are fixed retested and eventually after some testing cycles you you start finding less defects and once all those severe or high or critical defects have been fixed it helps to measure the quality of the software you can you can confidently say that the quality of software has improved from day one uh from phase one okay so testing helps to measure software quality testing provides confidence in software based on number of defects found so in initial phases if you are finding lot many defects in software they are being fixed and later phases you are those once those defects are fixed in later phases of software development life cycle you find less number of defects so you can say you you you are more confident on the software because you are not able to find any major or critical errors now so it it provides confidence in the software well designed tests uncover most of the defects in software and if the test pass it gives more confidence in software quality so if you have test cases which are well designed you have used good test design techniques so those defects uncover most of the defects in software those tests uncover most of the defects in software and if if your well-designed test cases pass it gives you more confidence in the quality of the software testing also helps to find defects and software quality improves when those defects are fixed so testing finds those defects software quality improves when those defects are assigned to developers and fixed and re-tested so testing is an important part for improving the quality of the software and what is software quality as per ist qb quality is the degree to which a component system or process meets specified requirements and our user customers needs and expectations which means a software so in a software test in a software context so quality can be quality is something if your system meets the requirements your end user requirement and it meets customer needs and expectation when will i say that this product is is of good quality when it it meets the specifies requirement and it is fit for use for me if i'm using some software if that software is meeting my needs it is good quality for me it doesn't crash it meets my requirement it works perfectly fine even even during even for long hours that is a good quality product for me all right so software quality for developers and testers is that it meets specification is technically good and has few defects but software quality for other stakeholders may be different because they also need value for money so for for developers and testers if it meets specification it's of technically very good quality and it has very few defects then it is of good quality for software developers and testers but if for for other stakeholders for the business stakeholders it doesn't matter i mean if they just want an application or just want application with very basic functionality to achieve something they don't want extremely high quality or extremely costly application for fulfilling just few things that they need it's not good for them it's not a value for money for them okay so there are different viewpoints for software quality one is attribute of product how fit for use is it fit for use how good is the development process and is it value for money okay so what attributes i need as an end user from a product the product should meet that it should be fit for use for me the development process or the process by which that product has been developed should follow the standards and it should be reasonably priced so these are some of the viewpoints which define the quality of any software okay so if i i'm looking for four things in any software and there are ten software that are providing all those four things four software which which are very easy or fit for use so i'll i'll my list will come down to four four uh softwares from those ten and then i'll i'll see which company it is from and which which will ensure that what kind of development process um these companies is is it a mature or a well-known company then i'll from from those four i'll come down to say three and then i'll compare the price of those three softwares the one that is reasonably priced and provides all the attributes is fit for use from good company i'll buy that okay then what is the root cause analysis root cause analysis is finding the real reason for the failure if a software you are testing fails then you do root cause analysis to find the actual cause of that failure okay so suppose you are testing a client server application all right and you you are passing you are passing some parameters from the client and your server is not responding you you are expecting some response from the server when you pass something from the client but you are not getting those those response you were getting those responses yesterday so in order to find in order to find what has happened from what what happened wrong since yesterday you need to do root cause analysis to figure out what exactly is the cause why you are not getting the response from the server so there can be many reasons there can be network issues that your your request is not at all being transferred to the server that's one cause web server can be done so wherever your your server application sits that web server can be done there can be issues with the firewall at the server server side or at the data center there can be issues with the port so these are some of the points you do the brainstorming so when once you start getting some some issues or failures you do br brainstorming with the team and figure out all the possible causes of of the failure all the root causes of the failure and then you start figuring out so then you start checking out if network is fine yes so see so that's how you brainstorm and then grouping group them into categories and then start checking what exactly caused the issue so root cause analysis is finding the real reason for any failure or defect in software and how much testing is enough so the testing principle there is one testing principle which says exhaustive testing is impossible why exhaustive testing is impossible because suppose you have one text field one input field on your ui that only accepts one input one one digit all right so if you're testing that input field there will be ten scenarios if you are doing exhaustive testing for it so zero to nine so it will accept one day so you have to test for all those ten digits not only that you need to test it for characters um lowercase alphabets uppercase alphabets some of the special characters blank inputs so total in all it comes to minimum 68 to 70 inputs and it can be even more so this is with just one input field on your ui suppose you have two a text field which accepts two input fields which which has which accepts two digit numbers then you have huge number of inputs to test with so that's why it said that exhaustive testing is impossible because you cannot test all the valid or invalid scenarios for um for any application because there are huge huge number of input fields that's where you use your test design techniques boundary value analysis equivalence partition techniques to figure out the scenarios to figure out the the boundary values and the scenarios that you will be testing which will cover most of that um partition the valid partition invalid partition i'll cover all those details in later sessions okay so in order to figure out how much testing is enough there's always risk assessment done to decide how much testing to do if it is just your family blog very minimal testing or family website very minimal testing if it is a safety critical application risk assessment is done based on different modules and then integrated system as a whole and then decided where to focus more and what how much testing should be done what all scenarios what what all scenarios needs to be covered what are the standards that need to be followed so it's based on risk assessment so how much testing is enough it's based on the risk assessment you do risk assessment for the software and then decide the testing effort based on the so based on the risks associated with different modules of software so to conclude in this session we learned why is testing necessary what causes the software defects then when do defects arise defects can arise in any phase of software development life cycle requirements design or coding phase and what is the cost of defects what is the role of testing in software development maintenance and operations testing and quality we we saw why is how testing improves the quality then what is root cause analysis and how much testing is enough all right thank you