We have reached our final module, module five. In this module, we will be discussing defects and what they are. And what is the defect. A defect is an error or above in the application, which is created a program a programmer while designing and building software can make a mistake or errors. These mistakes or errors means that there's a flaw in the software and they are called defects. If we look here at the example here, looking at this try, so, what is wrong with this tricycle?

Well, as you can see here, the wheel is not what a tester would do, that tester would execute their test case, and they will log the defect and report it back to the programmer or the To developer so that they could fix that problem before this try sickle is put on you're put into a tar department at a store or something. Here let's discuss the economics of software testing. In 2003 study commissioned by the Department of Commerce, National Institute of Standards and Technology found that software bugs cause the US economy over $59 billion annually. So the earlier you the earlier a defect is found in the software development lifecycle, the cheaper it is to repair. Let's take a look right here. If a defect is found in the requirement gathering phase is only $100 To fix a defect.

So if we can go back to your first exercise in there, you were required to document requirements for that product and service. If an error is found, during that phase when requirements are being gathered and documented, it's only $100 to fix it. If that same defect if is not found during that phase, and a tester finds it, it's 1500 dollars to fix that defect. So that means more manpower is needed. A developer has to go back and do reverse testers have to test and go back and do rework. So that one defect that was caused $100 to fix it is now 1500 dollars.

If it's found doing QA testing if they Same defect is found during production. That means, if a user finds it is released to users, and a user finds that single defect that wants to cost $100 to fix, it is now $10,000 to fix if it's found into production, just some important components of a defect report. As we mentioned earlier, when a tester is executing those test cases, they are checking to make sure each step pass. If a step fails, they are to report it. And if it's a manual department, you have defect reports that are generally created on the spreadsheet There are defect tracking tools that can be used. So here, let's look at the first requirement a defect ID.

And that's generally if you're using a tool, the system will generate a number if a using a spreadsheet, and if it's more than one tester on a team, that person is maybe responsible or the Excel spreadsheet will generate a number. Then you want to put a summary of the defect. Exactly something brief about what happened. You also want to put a detailed description of the problem that was found. You want to put it severe at the defect. So for example, severe these are critical theory of mind order it in minor.

A critical defect could be if the system crash. As soon as the user would they log in with the login requirements that we saw earlier. So take for example, the user enters in their username and their password and then they click login and the system crashes. That would be a critical defect. An example of a serious defect user puts in their username and their password. They click Login.

They were able to successfully log in, however, an error message appears that would be considered a serious defect. An example of a minor defect. It's something cosmetic. So the login button The label is misspell instead of L o GIN, there's an M in the Replace in the place of the n that is cosmetic and that will be considered minor. Next you want to list the priority. So the priorities are high, medium, moderate, in low or minor.

And this helps a developer if you have two defects with the same severity. But their priority is different. This is help them determine which defects should be worked on first, then you want to put steps to reproduce. This helps the developer with troubleshooting in getting to the root of the problem to fix it, in order for it to be retested or tested for the defect to be fixed. retest it. So the more information that you provide to the programmer or the developer, it makes it a lot easier for them to troubleshoot the root of the problem until also fix it.

Then you want to put reported by you want to put your name, if you're the tests of the person that's executed that test case, that person should put their names, their due date, and also a screen print on some evidence. So if an error message appeared, you should take a screenshot of it. And there are different tools out on the market that one would use to maybe capture screenshot, and all of this information should be attached to the defect report. Here's an example of a defect tracking tool. And some of the components are quite similar to what will go on a defect tracking report that's created by on a Excel create about Excel. Here a summary.

This is just something brief you would put, but the problem is the severe at the different options can be found in the drop down. You the date, the system would generally generate the date. Who was the defect was found by the person's name. A lot of times the, the QA lead will set this defect tracking tool up, put all of the testers name so you could just select your name of the tester can select their name from from here, and here's just some priority. The type of problem here it is a defect. And here in the description column you want to write additional information About the defect.

Also the steps there are to reproduce that problem. And to save time, what one could do is just copy the steps from actual test case and paste them here in the body of this defect tracking tool. If you have any evidence, or screenshot of the error message or the problem itself, you can attach it here. Well, that concludes the fifth and final module to Introduction to software testing. Let's recap. Here in module five, we discussed defects and what they are.

We also discussed the economics of defects. We discussed the costs of software defects at the various phases of the software development lifecycle so for Example again, to repair a defect that is found during the requirement gathering phase is only $100. If the same defect is found during the QA phase, the cost goes up to 1500 dollars to fix that defect. If a defect is found in production, that same defect is estimated that it costs $10,000 to fix that same defect that once was $100, if found during the requirement gathering phase, we also learned in this module about how to report a defect manually. We discussed is some of the components of a manual defect report that is created on an Excel spreadsheet. That report should have the testers name, a summary of the defect, as well as a detailed description of the defect.

You should also include screenshots, proof of evidence of the problem. That report should also have steps to reproduce the fun to reproduce the problem. This assists the developer in troubleshooting the issue and fixing it. And the report should also have the severe 80 of the defect as well as the priority and again the severe it would be critical, serious moderate in minor. It critical issue would be a system crashing after an action is performed. Properly priority be ranked high, medium and low.

And the helps the developer prioritize their work if they have two defects with the same severity. And then finally, we had an opportunity to actually see a defect, an automated defect report, and like a manual defect report, the fields are quite similar. Thank you once again, goodbye. Thank you again for taking this course. If you have any questions or concern about the course, or just about software testing in general, please feel free to contact me here. Here you can find my contact information.

Again, my name is Alison Reed. My phone numbers 40442426151 website in social media information is listed here. Along with my office hours. Thank you once again, goodbye.