1. Defect Management

2. Definitions ● Error – A human action that produces an incorrect result Some confusion in understanding the functionality of the software Some miscalculation of the values, wrong formula used   ● Fault – A manifestation of Error ● Failure – Actual deviation of the Component or System from its expected delivery, service or result ● Incident – Any event that occurs during Test execution which requires further investigation Yet to conclude that the actual result is different from the expected result due to problem in component or system we are testing Wrong configuration, test environment problem, corrupted test data   2

3. New title What is a Defect? ●Any variance between Expected result and Actual result is called a Defect ●It's a flaw in the Application causes the component or system to fail to perform its required function ●It's failure to conform to specifications ●Defect is also called as a Bug or an Incident 3

4. New title Defect Continued ● A Defect occurs due to one or more of the following is true ; The software doesn't do something that the specification says it should do The software does something that specification says it shouldn't do The software does something that the specification doesn't mention The software doesn't do something that the specification doesn't mention but should The software is difficult to understand, hard to use, slow, or – in the software tester's eyes – will be viewed by the end user as just pain not right      4

5. What IS a Defect? Why do bugs occur? ● There are various reasons of occurrence of bugs; it may be due to : Poor documentation Ambiguous or unclear Requirements Changing Requirements Poor Design Architecture not catering to Business Growth Slow response to User actions Lack of programming skills / coding errors Features not working correctly Lack of good programming skills Due to increase in work pressure and assigned deadlines no time for Unit Testing Defect fixes are introducing new bugs Increased complexity in the software             5

6. Why do bugs occur? ● Lack of planning Test Activities Inadequate Testing  ● Communication Gap / Lack of communication plan Whom all to communicate Stakeholders, project manager, designer, development team, test team etc What to communicate Reports, status, created documents When to communicate Frequency / how often How to communicate E-mail, meetings, demo, brainstorming         6

7. Defect Reporting ● Purpose is to record all the defects and maintain them at one location to be used for various reasons...Defect Repository ● Helps in Tracking Defects till they get closed All concerned, get updated on number of defects and their status Developers use information to provide Defect fixes Project managers use information to know on defects and their root cause (Coding, environment, unclear Requirements) Used for measuring Software Quality Used for deciding on readiness of the Application for Deployment in production Used for future similar Projects        7

8. Defect Report Template ● Defect Report consists of following information / sections Defect Id – A unique number allocated to each defect for identification Project – Project name Application version – Build version Phase – Level of testing where defect is found i.e. Unit, Integration, Systm, UAT Summary – Summary of the defect. Keep this clear and concise Description – Detailed description of the defect. Describe as much as possible but without repeating anything or using complex words. Keep it simple but comprehensive Steps of replicate – Step by step description of the way to reproduce the defect. Number the steps        8

9. Defect Report Template Continued ● Actual result – Application response received on User action ● Expected Result – Expected result as per Requirements ● Attachments – Attach any additional information like screenshots and logs ● Remarks – Any additional comments on the defect ● Defect Severity – Severity is decided on the basis of impact of the defect on the Application ● Defect Priority – Priority of the defect is decided on the basis of how urgently the defect should be fixed It depends on how frequently the impacted functionality is going to be used.  9

10. Defect Report Template Continued ●Reported By – The name of the person who reported the defect ●Assigned To – The name of the person who is assigned to analyze / fix the defect ●Status – The status of the defect ●Fixed build version – Build version of the product where the defect was fixed (e.g.1.2.3.9) 10

11. Defect Severity Levels ●Very High Application not starting Application getting hanged frequently so unable to use No work-around available / showstopper    ●High Application feature is not working correctly but work- around is available Feature is not working as per specification Performance issues    11

12. Defect Severity Levels ●Medium Incorrect error message Error message not displayed Incorrect Navigation    ●Low Spellings mistakes Grammatical errors Alignment issues, UI Level control placements .... cosmetic issues Suggestions / Enhancements     12

13. Defect Priority Levels ●Very high Needs immediate fix, blocking Bug which has halted testing  ●High Needs fix and Retesting before Application moves for UAT  ●Medium Fix to be provided if time permits  ●Low Fix can be considered in the next release  13

14. Defect Severity and Priority ● It is possible that High Severity Defect has medium or low priority Application functionality where Bug is observed is very less frequently used e.g. “ Loan Application “ Feature through ATM is not working   ● It is possible that Low Severity Defect has Very High Priority Application is missing the Logo of the company Spelling mistake in the title of Welcome / Home Page No functionality is getting affected but important from Customer point of view    14

15. Defect Life Cycle To be resolved in the next release New Review by Test Lead Opened Review Assign / Reassign Duplicate Deferred Reject Fix Not a Defect Fixed Retesting Closed Regression 15

16. Defect Life Cycle Continued ●Defects raised by the Tester need to be tracked till they get closed ●Status of the defect changes as phases / activities such as Review, Retesting get completed ●New : When a defect is logged and posted for the first time it's status is “New” ●Opened: After tester has reported the bug, the test lead reviews the defect If Defect is genuine its status is changed to “Open” else it is marked as “Closed”  16

17. Defect Life Cycle Continued ● Retesting is a phase / activity carried out by Tester to check whether code fix provided is working correctly If code fix is working then status of such defect is changed to “Closed” If code fix is NOT working then status of such defect is channged to “Reject Fix”. Such defects gets reviewed and re-assigned again   ● In Regression Testing already passed test cases are executed and may result in Finding some defects which were already closed Such defects are re-opened and tracked till they get closed Finding new defects    17

18. Defect Life Cycle Continued ● After Defect is in Open status development Lead reviews the Defects If similar defect is already logged by another Tester then such defect is marked as “Duplicate” and it gets “Closed” immediately If defect is agreed to be resolved in the next release by all stakeholders then such defect is marked as “Deferred” and considered when defect fixes for next release start   ● Assign : Valid defects get assigned to the developer to provide fix ● Fixed: When developer makes necessary code changes and verifies the changes are working then such defect status is marked as 'Fixed' 18

19. What is Defect Tracking? ●Defect Tracking is the process of monitoring the defects right from the time of recording defects (Defect status New) until satisfactory resolution has been determined (Defect status Closed) ●Defect tracking is important in software engineering as complex software systems typically huge number of defects : managing, evaluating and prioritizing these defects is important within test schedule ●Use of a defect tracking system can make the management task much easier 19

20. Defect Tracking Tools ● Features of any Defect Tracking tool are Creating a project, Build version, Module / Component, Access to project Users Adding a Defect Update status of the Defect Auto sending of an E-mail to concerned members when Defect status is changed Various Reports      ● Defect tracking tool e.g. Bugzilla ,Quality Centre ● Defect status names and life cycle implementation may slightly differ company to company ● All defect tracking tools provide facility to define Defect Statuses and Status change process. 20

21. Defect Prevention ● Defect Prevention (DP) is a strategy applied to the software be implemented by preparing development life cycle that identifies root causes of defects and prevents them from recurring ● It can be implemented by preparing an action plan to minimize or eliminate defects, by defining corrective action and producing an analysis of the root causes of the defects ● Training should include software quality assurance, configuration management and document support and focus on DP and statiscal methods (e.g. cause / effect diagrams and Pareto analysis) 21

22. Testing Principles ●Absence – of – errors – fallacy  Finding and fixing defects does not help if system does not fulfil the user's needs and expectations. ●Defect Clustering  A module(s) contain most of operational issues / Defects 22