Incident Management
164K - views

Incident Management

Similar presentations


Download Presentation

Incident Management




Download Presentation - The PPT/PDF document "Incident Management" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.



Presentation on theme: "Incident Management"— Presentation transcript:

Slide1

Incident Management

Lora Borisova

QA Engineer

Web & Creative Assets Team

Dimo Mitev

Senior QA

Engineer, Team

Lead

System Integration Team

Telerik QA Academy

Slide2

Table of Contents

Incident Management – Main ConceptsIncident ReportingDefect LifecycleMetrics and Incident ManagementSome Golden Rules for Incident ReportingIncident Management Tools

2

Slide3

Incident Management

Main Concepts

Slide4

What Are Incidents?

Testing often leads to observing deviations from expected resultsDifferent names are used for that:IncidentsBugsDefectsProblemsIssues

4

Slide5

Incident vs. Bug – A Matter of Semantics

Sometimes a distinction between incidents and bugs (defects) is madeIncidentAny situation where the system exhibits questionable behaviorBugAn incident is referred to as a bug (defect) when the root cause is some problem in the item we're testing

5

Slide6

What Else Could Cause an Incident?

Other causes of incidents include:Misconfiguration or failure of the test environmentCorrupted test dataBad testsInvalid expected resultsTester mistakesAccording to the test policy – any type of incident can be logged for tracking

6

Slide7

The Earlier – The Cheaper

Incident logging or defect reporting are not necessarily happening during testingIncidents can be logged, reported, tracked, and managed during development and reviews

7

Slide8

What Do We Report Defects Against?

Defects can be reported against:The code or the system itselfRequirementsDesign specificationsUser and operator guides and tests

8

Slide9

Glossary

Defect (bug)A flaw in a component or system that can cause the component or system to failErrorA human action that produces an incorrect resultFailureDeviation of the component or system from its expected delivery, service, or result

9

Slide10

Glossary (2)

IncidentAny event occurring that requires investigationOccurs anytime the actual results of a test and the expected results of that test differIncident loggingRecording the details of any incident that occurred (e.g., during testing)Root cause analysisAn analysis technique aimed at identifying the root causes of defects

10

Slide11

Incident Reporting

Slide12

Managing Defects

Defects found can reach count that is hard to manageA process for handling defects from discovery to final resolution is neededShould include reporting, classifying, assigning and managing defects

12

Slide13

Central Database

A central database for each project should be establishedAll incidents and failures discovered during testing are registered and administeredDevelopers, QAs and stakeholders have access

13

Slide14

What Goes in an Incident Report?

An incident report usually includes:SummarySteps to reproduceIncluding inputs given and outputs observedIsolation steps triedImpact of the problemExpected and actual behavior

14

Slide15

What Goes in an Incident Report? (2)

An incident report usually includes:Date and time of the failurePhase of the project Test case that produced the incidentName of the testerTest environment

15

Slide16

What Goes in an Incident Report? (3)

References to external sourcesSpecification documentsVarious work itemsAttachmentsVideos and screenshotsAny additional information about the configuration

16

Slide17

What Goes in an Incident Report? (4)

Root cause of the defectUsually set by the programmer, when fixing the defectStatus and history informationCommentsFinal conclusions and recommendations

17

Slide18

What Goes in an Incident Report? (5)

Severity and priority of the defectSometimes classified by testersSometimes a bug triage committee is responsible for thatDetermines also the risks, costs, opportunities and benefits associated with fixing or not fixing the defect

18

Slide19

Defect Severity

What is a defect "severity"?The degree of impact on the operation of the systemPossible severity classification could be:1 – Blocking2 – Critical3 – High4 – Medium5 – Low

19

Slide20

Defect Severity Levels

BlockingStops the user from using the feature as it is meant to be usedNo reasonable workaroundCriticalData corruptionEasily and repeatably throws an exceptionNo reasonable workaroundFeature does not work as expected

20

Slide21

Defect Severity Levels (2)

HighThrows an exception when not following the happy path Confusing UIHas a reasonable workaroundMediumFeature works off the happy path with minor issuesSmall UI issuesOne or more reasonable workarounds

21

Slide22

Defect Severity Levels (3)

LowCosmetic issuesMany workaroundsLow visibility to users

22

Slide23

Defect Priority

What is a defect "priority"?Indicates how quickly the particular problem should be correctedPossible priority classification could be:1 – Immediate2 – Next Release3 – On Occasion4 – Open (not planned for now)

23

Slide24

Defect Priority(2)

Covey's QuadrantsDefects are categorized by four quadrants:QI - Important and UrgentQII - Important but Not UrgentQIII - Not Important but UrgentQIV - Not Important and Not Urgent

24

Slide25

Defect Priority(3)

The ABC MethodA = vital B = important C = nice Then these categories are subdivided into A1, A2, A3, ..., B1, B2, ... and so forthThe Payoff versus Time MethodWeight each defect by the payoff expected from it versus the time it takes to be done

25

Slide26

Defect Priority(4)

Paired ComparisonUses a simple scoring system for comparing activities1 = slightly prefer 2 = moderately prefer 3 = greatly prefer

26

Option

A:B:C:D:A:A,1C,2A,1B:C,2D,2C:C,2D:

A=1+1=2B=0C=2+2+2=6D=2

The option with highest result has the highest priority

Slide27

Defect Lifecycle

Slide28

Defect Lifecycle

Defect lifecycles are usually shown as state transition diagramsDifferent defect-tracking systems may use different defect lifecycles

28

Slide29

Defect Lifecycle Graph

Simple defect lifecycle graph

29

Slide30

Defect Lifecycle States

NewThe bug is posted for the first timeThe bug is not yet approvedOpenThe test lead approves that the bug is genuine Changes the state as “OPEN”.Assign The bug is assigned to corresponding developer or developer team

30

Slide31

Defect Lifecycle States (2)

TestThe bug has been fixed and is released to testing teamRejectedIf the developer feels that the bug is not genuine, he rejects the bugDuplicateThe bug is repeated twice or the two bugs mention the same concept of the bug

31

Slide32

Defect Lifecycle States (3)

DeferredThe bug is expected to be fixed in next releasesReasons for changing the bug to this status may have many factors:Bug may be lowLack of time for the releasethe bug may not have major effect on the software

32

Slide33

Defect Lifecycle States (4)

VerifiedOnce the bug is fixed and the status is changed to “TEST”, the tester tests the bugIf the bug is not present in the software, he approves that the bug is fixed

33

Slide34

Defect Lifecycle States (5)

ReopenedThe bug still exists even after the bug is fixed by the developerThe bug traverses the life cycle once againClosedThe bug is fixed, tested and approved

34

Slide35

Metrics and Incident Management

Slide36

Defect Management Metrics

Various metrics can be used for defect management during a project Helps managing defect trends Helps determining readiness for release

36

Slide37

Defect Management Metrics (2)

Total number of bugsNumber of open (active) bugs/tasksNumber of resolved bugs/tasks

37

Slide38

Defect Management Metrics (3)

Bugs per categoryBug cluster analysisDefect density analysisNumber of defects discovered on a time unitE.g., week, testing iteration, etc.

38

Slide39

Defect Management Metrics (4)

Mean-time to fix a defectThe time between reporting and fixing/closing the bugTime estimates versus actual time spent comparisonGives confidence in the estimates given by the team

39

Slide40

Bug Convergence

Bug ConvergenceAlso called open/closed chartsThe point at which the rate of fixed bugs exceeds the rate of found bugsA visible indication that the team is making progress against the active bug countA sign that the project end is within reach

40

Slide41

Defect Detection Percentage

Gives a measure of testing effectivenessSome defects are found prior to release while others - after deployment of the systemThe defect detection percentage (DDP) compares field defects with test defects, also called escaped defects

41

defects (testers)

defects (testers) + defects (field)

DDP

=

Slide42

Some Golden Rules for Incident Reporting

Slide43

Golden Rules for Bug Reporting

Watch your testsRun your tests with care and attentionYou never know when you're going to find a problemReporting intermittent or sporadic symptomsSome defects cannot be reproduced alwaysReport how many times you tried to reproduce it and how many times it did in fact occur

43

Slide44

Golden Rules for Bug Reporting (2)

Isolate the defectMake carefully chosen changes to the steps used to reproduce itMove from boundary values to more generalized conditionsProvide information on the defect's impactMakes setting priority and severity easier and more accurate

44

Slide45

Golden Rules for Bug Reporting (3)

Mind your languageChoose the right words in your reportBe clear and unambiguous, neutral, fact-focused and impartialBe concise – avoid useless detailesMake reviews of bug reportsMake an experienced tester take a look a your report

45

Slide46

Incident Management Tools

Slide47

Telerik TeamPulse

TeamPulse is an agile project management solutionRequirements ManagementBug ManagementPlanning and SchedulingTime TrackingIdeas and Feedback ManagementFilteringReporting

47

Slide48

TeamPulse Demo

LoginSetup a new ProjectEnter a new work item (Story/Task, Bug, Issue, Risk, Feedback)Manage work itemsResolve and CloseSearch, Reports, Email notifications, etc.

48

Slide49

Sitefinity Site

Demo

Slide50

JIRA

What is JIRA?A proprietary issue tracking product, Developed by AtlassianUsed for Bug trackingIssue trackingProject managementhttp://www.atlassian.com/software/jira/

50

Slide51

JIRA - Demo

LoginManage DashboardEnter a new ProjectEnter a new ComponentEnter a DefectManage DefectResolve and CloseSearch, Reports, Email, etc.

51

Slide52

Bugzilla

What is Bugzilla?Web-based bugtrackerOriginally developed and used by the Mozilla projecthttp://www.bugzilla.org/

52

Slide53

Bugzilla

Demo

Slide54

Team Foundation Server

What is TFS?Microsoft product offeringSource controlData collectionReportingProject tracking

Slide55

TFS

Demo

Slide56

Other Bug-tracking Tools

Some other bug-tracking tools:MantisBTTRACGNATS

56

Slide57

Incident Management

Questions?

?

?

?

?

?

?

?

?

?

?

?

Slide58

Slide59

Slide60