Hello and welcome to Module Three. In this module I will discuss system defects. So what are defects? software defects are sometimes called bugs occurs when one of the following occurs when software doesn't do something the product Requirements Specification states that it should. It is also when software does something that the product Requirements Specification doesn't mention. It is also when software doesn't do something that the product Requirements Specification doesn't mention, but it should.

And then finally, a defect is also when a software is difficult to understand. It is hard to use or slow to perform Here I have an example of a software defect. What I like for you to do is just take a couple of minutes here and examine both pictures. The image on the left is what the client expected. The client provided the development company company with a picture on how their logo should appear. The image here on the right, was what was delivered to the client.

So take a few moments here and study both image and document just some of the differences at least maybe five. And I'll give you mine for example, the bandana or the scarf that's tied around each person's head. They're different colors. So again, take about five minutes and just document at least five things. You see that are wrong. That's wrong with the differences between both images.

A software failure terms. Depending on the organization that you work for, there are numerous terms. So here we'll just review a few. The most commonly used is defect. You might hear the term bug, fault incident, variants failure, or failures. Software defects can have a major impact on the performance of the software.

It can also result in death. It can call millions of dollars to repair if not found at the very early stages in the software development lifecycle. And it can also cause mechanical failures. Just a few weeks Examples of the results of a software defect in 19 April 1994, China airline flight 140 crash, and it killed 264 crew members and passengers. And this was due to a software bug or defect that wasn't found. An example of the results of a software defect.

Back in May 99 1996, a major US Bank credited 823 customers accounts with over 920 million dollars. And again, this is a result of a software defect. So why do defects occur when they occur for a number of reasons, but the number one reason as to why defects occurs is because of software requirements. Usually there's not enough information. Oftentimes they are incorrect, and they change often. The second reasons why defects occurs within an application is because of designs.

Books occur here for the same reasons they occur and requirements. The designs are rush, they change often in, they're not well communicated. The third reason why defects occurs is because of coding errors. Unfortunately, developers are humans and they make mistakes. When pressure is put upon them, unfortunately, again, it results in coding problems. When requirements changes, so when requirements aren't well communicated with the developer, it can result in coding errors.

And then there are other reasons why the fix occurs. Thing applications. Sometimes they're not really the fix. There are duplicate bugs, there multiple models etc. Let's review the costs the costs of software defects. The cost to fix a book during the early stages of the software development lifecycle is very inexpensive.

So take for example, during the requirement gathering phase, if a defect is found within the requirement, the cost to fix a defect, it's roughly around $10. However, if that same defect is found, during coding or doing test during the testing stage, the same defect can cost anywhere from $100 short thousand dollars or maybe four more to fix it. If they do is found by a customer, it can cost $10,000 or more to repair. So, the lesson here is again to find defects very early on in the software development lifecycle, the cheaper it is to repair it, defect goes through a life cycle. And the life cycles basically is the journey of a defect cycle, which a defect goes through during this lifetime. Now, this will varies from the organ from organizations to organizations.

There are a number of states that a defect goes through. And again it varies from organization organizations to organizations, it can also go from project to project. In here is just the example of a defect life cycle. diagram. Stage One is new in all defects, or in this stage, this is when a tester would find a defect and create it. And then from there that same defect goes into assigned from there it goes into open, fix, retest and close.

That same defect can go into a different status or rejected or duplicate or can be reopened. So, let's discuss just some of them in what they actually mean. So, what does it mean by a, an assign defect? Well assign defect is once the bug is posted by the tester. Generally the test lead will approve this book in itself. The bug or the defect tool to the development team.

The development team will then change the status from assigned to open. And this is basically the developers started to analyze and work on the defect to fix it. Well, once the developer has fixed the defect, they personally know that developer will change the status to fix. And from there, it will go to retest, the developer will change it to retest, and the software testing team or the tester will actually retest this defect. Now, if the fix after the test team has retested the fix, to make sure that it was fixed in the functionality is now working this design that tests lead will change the status to Close. We have some other phases here.

And they are. Let's just take a look at a couple of them. If something is reopen, well a bug is reopened souls Take for example the the test lead has closed the defect. One new release comes out. And that same defect that was found in a previous release or a previous release now is resurface. So instead of opening up another defect, a testable just reopen that same defect.

And what does he mean by deferred? Well deferred, it is the present but that is not it's really not a priority. So if the tester finds a defect, and the development team for some reason, they've decided The project team has decided that that defect will not be fixed before it is released into our that version is released into production, it will be fixed in a later version, instead of closing it, it will be put in a deferred status. And that is for the defects to be fixed at or later in a later version. rejected. This happens sometimes the developer feels that the defect is not genuine, it's not an actual defect so they will reject it.

And the final one we will review is a duplicate. And this is basically self explanatory. This is just a duplicate defect. A tester a reported the same defect in as tester B. So a development team will mark it as duplicate. defects when they are created, they must be classified and there are two classifications one is a severe duty and the other one is priority.

So, let's review what a severity defect is. So, what exactly does it mean by severe it was a verity is extending the extent in which the defect can affect the software. And here are just a few and again this will change depending on the organization that you want is working for. So, these are just examples. So, some of the Verity severities are as follows critical the defect that results in the termination of the system. So when the system crashes, this would be marked as severe at major, the defect that terminates a major function of the system.

So take for example, you gone to a ecommerce website, and you're able to order an item. And but unfortunately, you're not able to pay for that item with a credit card. You can select it. But once you get to check out you're unable to put your credit card in or you receive in an error message when trying to submit your credit card. The system is functioning, you're able to log in things of that nature in select an item to purchase, but you're unable to check out this is a major problem. And so that would be an example of a major and you have moderate defect and then the moderate defects the defect that does not result in the termination but the cause is the system to produce something incorrectly.

Again, using the example with the credit card, you're able to process that credit card, but you receive an error message or, or something after that credit card has been submitted. And then you have minor and cosmetic defects, these type of defects doesn't, they generally don't impact the functionality of the system. It could be something cosmetic. And it's not major. These are minor things that might be deferred at a later time, but it impacts the way the application may be, look, there might be something grammatical. And we have a second classification, as I mentioned earlier, is a priority.

All defects must be ranked by their priority and the priority the priority In which we should resolve the defects. So this helps a developer determine which defects should be fixed first. So take for example, if you have two defects with the same classification with the same severity, but the priority is different. The sub priority the defect with the highest priority would be worked on first. So, here's just an examples of three and you have high medium and low high the defect must be resolved as soon as possible because the defect is affecting the application or the product severity. The system cannot be used until the repair has been done.

So you have a system that is crashing or you're unable to log into a particular application The severity would be critical in the priority would be high. So why are some defects are not fixed? Well, sometimes there's just not enough time. And in this case that defect would be put into a different status. Now generally, the project team the project managers in the business owners will have the final say so on which defects that will be deferred. It's not a one person's decision.

Generally, it's a group decision led by the business. The development team may also have some input on why the defect will not be fixed, those defects are not fixed. Another reason it's there, it's too risky risky to fix it. It's not worth doing. And sometimes it is really not a bug. It could be a training issue by the testing team where they've created a defect and it really isn't about it.

And in order to open a defect, you can depending on the organization, they might be using an Excel spreadsheet. But in today's time, most companies are now using various defect tracking tool to create an open a defect. So here's just a screenshot an example of a defect tracking tool. And here are just some of the major components. You have a summary so they test would put a brief summary of the defect. The type, again is the defect.

And here you can see on the right hand side in red, you have the severity. You also have the detected by so the tester would put their name. Here, you would also have a description. In the description column, the tester would put a detailed description on what happened, they would also put to the actual steps that they were executing at the time when the defect occurred. You also would have the ability to attach any screenshots. So say for example, an error message appear appeared.

You would take a screenshot of that and attach it to this diff Report. And if you see here in the lower right hand corner, there's the priority and the status right now the status is marked is net