Presentation unit -4.pptx jddj kdifjdjfjdif

Hi am study diploma in Computer engineering and technology and technology

1. 4.1 Defect Classification What is Defect Management: Defect management is the process to find the defect as quickly as possible & minimize the impact of the defect. It is the process of enhances quality by adding value to the most important attributes of software like reliability, maintainability, efficiency and portability. Software defects are expensive. Moreover, the cost of finding and correcting defects represents one of the most expensive software development activities. To do this development teams need to implement a defect management process that focuses on preventing defects, catching defects as early in the process as possible, and minimizing the impact of defects. A little investment this process can yield significant return.

2. Classification of Defect: There are various ways in which we can classify. Below are some of the classifications: Severity Wise: Major: A defect, which will cause an observable product failure or departure from requirements Minor: A defect that will not cause a failure in execution of the product Fatal: A defect that will cause the system to crash or close abruptly or effect other applications 2) Work Product Wise: SSD: A defect from System Study document FSD: A defect from Functional Specification document ADS: A defect from Architectural Design Document

3. DDS: A defect from Detailed Design document Source code: A defect from Source code Test Plan/ Test Cases: A defect from Test Plan/ Test Cases User Documentation: A defect from User manuals, Operating manuals 3) Type of Errors Wise: Comments, Computational Error, Data Error, Database Error, Missing Design In correct Design, Boundary Conditions Neglected, Interface Error, Logic Error, Message Error, Navigation Error, Performance Error Missing Requirements, Incorrect Requirements, Test Plan error, TC Error, Variable Declaration Error, etc.

4. 4) Status Wise: Open Closed Deferred Cancelled MSBTE Question: Give / Explain Defect Classification in detail. Define Defect Management. Which are the root causes of Defect Management. What is defect management ? Give defect classification in detail

5. 4.2 Defect Management Process The process of finding defects & reducing them at the lowest cost is called as Defect Management Process. Following Figure shows Defect Management Process:

6. Defect Prevention: Implementation of techniques, methodology and standard processes to reduce the risk of defects. 2. Deliverable Baseline: Deliverables are considered to be ready for further development. i.e. the deliverables meet exit criteria. When a deliverables is base lined, any further changes are controlled. Errors in a deliverables are not considered defects until after the deliverables is base lined. 3. Defect Discovery: To find the defect through the process of verification and validation. 4. Defect Resolution: Defect is corrected or corrective action is taken and notification is given to tester. Work by the development team to prioritize, schedule & fix a defect & document the resolution. 5. Process Improvement: To identify ways to improve the process to prevent further future occurrences of similar defects. l.e. Corrective and preventive action is taken for processes improvement. 6. Management Reporting: Reporting is about status of application and processes.

7. Defect Prevention Process: Prevention is better than cure applies to defects in the software development life cycle for software testing. Defect prevention is one of the important activities in any software project. It is QA process to identify the root causes of defects and improve the process to avoid introducing defects, which help to improve the quality of the software product.

8. In Defect prevention phase testers are involved in the studying and reviewing requirement specification document. Basically this is an art to review the requirement documents. The five general activities of defect prevention are: Software Requirement Analysis Review: Self & Peer Review Defect logging & Documentation Root Cause Analysis & Preventive Measures Determination Embedding Procedures in to Software Development Process Finally, Defect Prevention is not an individual exercise but a team effort MSBTE Question: Draw & explain Defect Management Process. Draw & explain Defect Prevention Process.

9. 4.3 Defect Life Cycle The different states of bug life cycle are as shown in the above diagram: New: When the bug is posted for the first time, its state will be "NEW". This means that the bug is not yet approved. 2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state "OPEN". 3. Assign: Once the lead changes the state as "OPEN", he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to "ASSIGN".

10. 4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to "TEST". It specifies that the bug has been fixed and is released to testing team. 5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to "REJECTED". 7. Verified: Once the bug is fixed and the status is changed to "TEST", the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to "VERIFIED ".

11. 8 . Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to "REOPENED". The bug traverses the life cycle once again. 9. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to "CLOSED". This state means that the bug is fixed, tested and approved. MSBTE Question: Draw & explain Defect Life Cycle. Draw Defect Life Cycle

12. 4.4 Defect Template Defect report is probably primary work product for most of the software testers. Good bug report is informative & understandable. Weak reports generate extra work for everyone. Defect reports are used to alert software programmers about the defect & give them sufficient information to find root cause & fix the problem. A good defect report might have following sections: Severity: It indicates how bad the bug is, the likelihood and the degree of impact when the user encounters the bug. 1. System crash, data loss, data corruption. 2. Operational error, wrong result, loss of functionality. 3. Minor problem, misspelling, Ul layout, rare occurrence

13. 2)Priority : It indicates how much emphasis should be placed on fixing the bug and the urgency of making the fix. Levels are: Immediate fix, blocks further testing, very visible. Must fix before the product is released. Should fix when time permits. Would like to fix but the product can be released as it is. 3 ) Headline: One line description of the defect. Remember a good headline will always be clear, related to the defect & give some hints on how critical defect could be. 4) Product: In most cases defect tracking system is used for more than one product. So specifying appropriate product & version is very important

14. 5) Component: Products are normally very complex & can be divided into components. A defect report containing proper information about component can help managers in assigning it to appropriate person. 6) Defect Type: Defect type could be functionality, specification, regression, UI, etc. This classification can be used to analyze how defects are distributed in the system. 7) Environment: Proper information about your test execution environment should be present. eg. Database, platform, etc. 8) Steps : All the steps should be specified clearly. You should not assumed that programmer will understand this. 9) Attachments: Whatever additional information is needed for the defect, should also be attached. 10) Comments: If you have any additional comments on the defect, you should specify early

15. Example: Name of Reporter Email Id of Reporter Version or Build: <Version or Build of the product> Module or component: <mention here the name of tested module or component> Platform / Operating System: Type of error: <coding error/design error/suggestion / UI/documentation / text error/hardware error > Priority: Severity: Status: Assigned to: Summary: Description: <mention here the steps to reproduce, expected result and actual result> SBTE Question: Which parameters are considered while writing good defect report? Also write contents of Defect Template. Explain Defect Report Template with its attributes.

16. 4.5 Estimate Expected Impact of Defect Defect Impact means degree of impact on the development or operation of a component or system is called defect impact. Once the critical risk are identified, the financial impact of each risk should be estimated. This can be done by assessing the impact, in dollars, if the risk does become a problem combined with the probability that the risk will become problem. The product of these two numbers is the expected impact of the risk. The expected impact of a risk (E) is calculated as; E = P * I, where: P= probability of the risk becoming a problem and I= Impact in dollars if the risk becomes a problem .

17. Techniques For Finding Defect: Defects are found either by pre planned activities specifically intended to uncover defects ( eg. Quality control activities such as inspection, testing, etc.) or by accident (e.g. user in production). Following are the different techniques used in finding defects: Static Techniques: Testing that is done without physically executing a program or system. A code review is an example of static testing techniques. Dynamic Techniques: Testing in which system components are physically executed to identify defects. Execution of test case is an example of dynamic testing techniques Operational Techniques: When the software system product is completed it produces deliverables of the user, customer or control personnel. While using the final software product the defect is found & software is not working or fails. MSBTE Question: What are the points considered while estimating impact of Defect? Explain Techniques to Find Defect. State how to minimize risk impact while estimating defect.

18. 4.6 Reporting A DefectIt is essential that you report defects effectively so that time & effort is not unnecessarily wasted in trying to understand & reproduce the defect. Following are some guidelines for making bug reports: Be Specific: Specify the exact action: Do not say somethingwhich adds confusion. In case of multiple paths, mention the exact path you followed. Be Detailed : Provide more information. i.e. do not be lazy. Be Objective: Do not make subjective statements like "This is lousy applications" or "You fixed it real bad“ Reproduce the defect: Do not be impatient & file a defect report as soon as you uncover a defect. Replicate it at least once more to be sure. Review the report: Do not submit as soon as you write the report. Review it at least once.

19. MSBTE Question: What is the Process of Bug Reporting prepare a sample bug reporting format?