hello everyone welcome to session 6 of module 5 incident management in this session we will learn about what are incidents what is incident management what are incident reports and how to write good incident reports and then finally we'll see incident or defect life cycle so let us understand what are incidents first so an incident is any situation where the system exhibits questionable behavior so whenever you are testing or analyzing a system or it is being used in the production environment by an end user if there is any questionable behavior seen in the system that is an incident if you find that the expected result that you are expecting um the expected outcome that you want from the system does not match with the actual result then that's a incident that's a questionable behavior and that that is known as incident and incident is any event occurring where actual results vary from expected results so if actual and expected results do not match that is that event is known as incident and any inconsistency between the actual and expected results caused by test environment issue issue with developer code issue with test data issue with the hardware or invalid expected results or tested mistakes so these are the inconsistency these are the scenarios in which inconsistency may occur between actual and expected results so if there is any inconsistency between due to testing one tissue or due to the issue of the developer code due to issue with the test data or any issues with the hardware or even if the expected results that you have mentioned in your test outcome are not valid so in all these kind of situation if expected an actual do not match then that inconsistency is known as incetent then an incentive incident is a defect or bug only when the root cause of that incident is some problem with the item being tested so an incident is any variation in the actual and expected result due to any conditions that we discussed like test environment or developer code an incident is a defect or a bug only when it is the root cause the root cause of incident is the problem with the item that you are testing is the problem with the code that you are testing then what are incident reports incident report contains a description of the questionable behavior so any report that explain the behavior that you have seen questionable behavior that you have seen while using the system or while testing the system is known as incident report incident report helps to have clear goals in mind when writing then it provides information about the incidence to team members so once you once you write down incense on in the report it has complete steps which can be viewed by other team members and can be understood by other team members so incident report provides information about the incidence to other team members as well then it helps in an analysis of the incident data so once you have incident report you can go through the steps to reproduce the questionable behavior that is being observed by somebody um you can then analyze that incident data and find the root cause of the issue the incident report analysis analyzes data eventually helps to improve the test process so once incident reports are being logged they are analyzed and after analysis whatever issues are there whatever discrepancies are seen in the actual and expected result can be rectified if it is a code issue or a defect that can be rectified by the code which in turn eventually improves the test process improves the quality of the software and the test process so how to write good incident reports um the first point to note is that you always need to be attentive while running the tests so that you do not miss any incident first and foremost thing is that you should be very attentive while you are testing any system so that you do not miss any uh questionable behavior of the software so attend being attentive is the key factor while while doing testing try to reproduce intermittent issues and add as much information as you can relate to intermediate issues so mostly in software testing it has been seen that most of the time you will find an intermittent issue which is not reproducible every time so you need to kind of narrow down that issue you need to re-execute that issue again or that test case again and again to narrow down the root cause to narrow down the exact steps and scenarios in which that failure occurs otherwise if the developer is not able to reproduce the incident or defect that you have raised that that defect is not taken into account because developer cannot reproduce and it's just closed and returned so in in case there are any intermittent issues which are not always occurring which are occurring only in certain specific conditions you need to perform it again and again and add as much information as you can to so that it's helpful for developers to reproduce those issues then try to isolate the issue by changing the steps used to reproduce so you need to isolate the issue by changing the steps used to reproduce so if you find some issue with with any test case or any scenario that you are testing and that is not being reproduced by certain uh steps in the test case uh so you should try to um follow a different path in order to isolate that issue in order to make sure which steps you need to perform exactly in order to reproduce that issue then you need to mention the impact of issues in the incident report it is very important to mention the impact what impact of the issues is there in the incident report so if it is it is impacting it is kind of critical for the software then you need to mention the impact of the incident in the report as well then you need to use clear and unambiguous neutral language so in incident report it has the language has already to be neutral it has to be very clear to the point report and unambiguous there should not be any confusion in the incident report the report should be concise so do not try to elaborate or do not try to explain um in pages the report so there should be these reports should be very concise and to the point and should be easy to understand to the other team members then it is recommended that all reports are reviewed by lead tester or experienced tester so whenever you are logging an incident report it is always advisable that these incident reports are being analyzed and reviewed by senior testers or lead tester before they are being actually assigned to the developers now let's understand what is defect detection percentage ddp defect detection percentage compares field defects with test effects so what are field defects field defects are the defects which arise after the software is in the production environment after it is in deployed in the field and test defects are the defects which are found while the software testing life cycle so during that life cycle whichever defects are found those are known as test effects and once the software is being deployed and in in maintenance phase those defects are known as field defects so defect detection percentage compares field defects with the test defects it is very helpful metric to find the effectiveness of test process so this metric is very helpful to find how effective the test process is now a ddp formula how to calculate defect detection person percentage it is ddp is equal to defect found during testing by the testers divided by uh defects found by the testers during the test process plus defect found during the uh production uh environment defect found in the field after the software is being deployed so so you can see if defect detection percentage is one then your your software test process is most effective so defect detection percentage will be one only if there are no defect found in the field so suppose testers found 100 defects divided by 100 plus 0 that is 1. so if ddp is 1 then your test process is very effective as soon as ddp starts reducing from once then you need to take care of the issues in the test process you need to improve the test process so suppose defect found by testers are 100 and then the effects found by in in the field once the software is deployed is another 100 more defects so ddp in that case will be 100 divided by 100 plus 100 so that will be 100 divided by 200 and that is 0.5 so ddp is 0.50 which is not which indicates that the test process is not able to find those 100 field defects that it should have found in the during the test phase itself so the lower the ddp is more you need to focus on the test process and improve the test process so that the defects that are found in the field are found well in advance during the test process and minimal defects are detected in the maintenance phase so you cannot remediate 100 defects in the software because 100 testing is not possible exhaustive testing is not possible but you can improve the test process so that minimal defects are in are being discovered in the field or in the maintenance phase then what goes in incident report so an incident report may include um summary of the incident so that's the first very important thing you need to include summary of the incident you need to include steps to reproduce different steps you need to narrow down the steps to reproduce the incident that you have seen then you need to mention expected and actual results what was the expected result and what was what is the actual outcome that you are getting after executing a test then you need to mention the software version in which incident was found phase the phase of the project where incident was found for example was it functional testing phase what is system testing phase or was it user acceptance testing phase or was it maintenance phase so the phase of the product project where incident was found then test case that produce the incident so you need to mention which test case you executed which produced the incident then if there is any reference to other document for example tracing back to the test case or tracing back to the requirement then you need to provide reference to other documents as well and finally the impact of the incident what is the actual impact of the incident on the software release or the software then ieee 829 standard test incident report template what what ieee standard report contains test incident report contains um test incident report identifier which is mostly um auto generated this identifier is kind of auto generated from the incident management tool that you use so they generate identifier automatically as soon as you fill all the details and submit the incident then the summary of the incident is very important um then incident description what were the inputs what were the what was what were expected results um the actual results any anomalies date and time uh when when it was found what were the steps procedure steps so this is same as steps to reproduce then the environment in which you detected the defect for example was it on windows and i 9 or was it on windows and firefox latest version or windows and chrome so these these environment in which you were testing the software and then attempts to repeat testers and observers so these are some of the description that you need to include and the impact of the incident so this is this is a standard template which is proposed by ieee and organizations modify this incident template based on the on their needs and requirements so they they use incident management tool and they can modify the template to as per their needs and requirements so the fields that you see for example date and time procedure step environment attempts to repeat so they can modify these fields if they require those fields they'll add them otherwise they'll just disable those fields for their from their incident management tool so let's understand what happens to an incident after it is being logged and submitted into the incident management tool so let's that's also uh known as a defect life cycle or incident life cycle so so as soon as you submit an incident it moves to a opened state so an incident is opened once it is open it is being analyzed by either the test lead or test manager to see whether it is kind of valid so there will be a responsible person who will be analyzing all the defects to see whether those are valid invalid defects or can be deferred so this person can be a development manager test manager depending um who is who is fulfilling that role so once it is open if it is a valid defect that gets assigned to the developer once it is assigned to a developer developer fixes the defect once he fixes the defect that defect is moved to he changes the state of the defect to fixed it once it is fixed it gets reassigned to the so developer changes the state to fixed and reassigns it back to the tester who raised that defect to verify it so it moves into fixed state and it gets assigned to the tester so we'll need to verify that defect tester will again verify the fixed defect in the in the new version of the software that that will be available and if that is verified it if the retest passes then tester closes that defect and defect moves into closed state in case tester retested the fix with in the new build and verification failed he will reopen the defect and after reopening it will sort of again um get assigned to the uh developer who has fixed the issue or it it it will move to the open queue again which and then the person who is managing the defect he'll again reassign the the defect to the developer in most of the cases once it is once verification fail and it is reopened it automatically gets reassigned to the developer who fixed that issue um so and in case the defect is open and it is not a valid defect then if it is not a problem here if it is not a problem then it moves to uh it is the state is changed from open to rejected if it is decided that it is not possible to fix the defect fix the incident in this release because it's it's not that critical then it is moved to deferred state and it is planned to be fixed later then it is moved to deferred state which which means that it will be fixed in the later releases so once it is moved to deferred state and if it is it is the next release of the software all the deferred state are then reopened after gathering new information and assigned to developers to get them fixed and then again verified if it is verified it gets closed if it is verification failed it's again reopen and reassigned to the developer so this is this is a brief of how um defect life cycle or incident life cycle is in the software development life cycle it is very simple um to understand this this defect life cycle there is nothing very uh critical and complex in it there are simple states in which you just keep on assigning the defects and changing the states of the defects as as per the work done on the defect so to conclude in this session we understood what are incidents and what are incident reports then how to write good incident reports what factors you need to consider in order to write good incentive reports then what goes in incident report what is the most important information that should go into incident report and finally we saw um incident or defect life cycle the complete life cycle of a incident after it is logged in in the incident management tool thank you