SE-MENTOR TRAINING

CONTENTS

bull Basic concepts- Software Quality what it meansbull Basic concepts- Bug Workflow

bull Typical life cycle of a bug

bull Bug Advocacy or how to get your bugs fixed bull What is a bug Error Failure Defect

bull Effective Bug Advocacybull Itrsquos not only about reporting the bugbull Bug advocacy = selling bugsbull Overcoming Objections and Motivating bug fixer

bull Writing Effective Bug Reportsbull Reporting Errorsbull Important Parts of the Report Problem Summary

BASIC CONCEPTS ndash SOFTWARE QUALITY

bull What is software quality

bull Quality is Conformance with requirements

-Actual requirements which may or may

not be whatrsquos written down

4

QUALITY ACCORDING TO-WHO

Project Manager

Developer

Testers

User Interface Design

Writing

Customer Service

Marketing

5

Basic concepts - Bug WORKFLOW

bull Bug workflows differ a lot from company to companybull A tester finds a bug investigates it and reports itbull Someone finds a bug (testerdeveloperclient)

bull Tester verifies it and puts it in a databasebull Programmer defends it or fixes it after consulting with higher

managementbull Tester verifies the fix if it is decided to be fixed

bull Someone finds a bug (testerdeveloperclient)bull Tester verifies it and puts it into a database of bugsbull PM or Test Manager decides on the bug assigns priorities to

bugs and assigns to developersbull Tester verifies the fix and releases it

6

Typical life Cycle

7

Bug Advocacy or how to get your bugs fixed

As a tester bug reports are your primary work product

The quality of your communication drives the success of your bug reports

ldquoThe best tester isnrsquot the one who finds the maximum number of bugs or the most critical bugs The best tester is the one who gets the most bugs fixedrdquo

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

CONTENTS

bull Basic concepts- Software Quality what it meansbull Basic concepts- Bug Workflow

bull Typical life cycle of a bug

bull Bug Advocacy or how to get your bugs fixed bull What is a bug Error Failure Defect

bull Effective Bug Advocacybull Itrsquos not only about reporting the bugbull Bug advocacy = selling bugsbull Overcoming Objections and Motivating bug fixer

bull Writing Effective Bug Reportsbull Reporting Errorsbull Important Parts of the Report Problem Summary

BASIC CONCEPTS ndash SOFTWARE QUALITY

bull What is software quality

bull Quality is Conformance with requirements

-Actual requirements which may or may

not be whatrsquos written down

4

QUALITY ACCORDING TO-WHO

Project Manager

Developer

Testers

User Interface Design

Writing

Customer Service

Marketing

5

Basic concepts - Bug WORKFLOW

bull Bug workflows differ a lot from company to companybull A tester finds a bug investigates it and reports itbull Someone finds a bug (testerdeveloperclient)

bull Tester verifies it and puts it in a databasebull Programmer defends it or fixes it after consulting with higher

managementbull Tester verifies the fix if it is decided to be fixed

bull Someone finds a bug (testerdeveloperclient)bull Tester verifies it and puts it into a database of bugsbull PM or Test Manager decides on the bug assigns priorities to

bugs and assigns to developersbull Tester verifies the fix and releases it

6

Typical life Cycle

7

Bug Advocacy or how to get your bugs fixed

As a tester bug reports are your primary work product

The quality of your communication drives the success of your bug reports

ldquoThe best tester isnrsquot the one who finds the maximum number of bugs or the most critical bugs The best tester is the one who gets the most bugs fixedrdquo

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

BASIC CONCEPTS ndash SOFTWARE QUALITY

bull What is software quality

bull Quality is Conformance with requirements

-Actual requirements which may or may

not be whatrsquos written down

4

QUALITY ACCORDING TO-WHO

Project Manager

Developer

Testers

User Interface Design

Writing

Customer Service

Marketing

5

Basic concepts - Bug WORKFLOW

bull Bug workflows differ a lot from company to companybull A tester finds a bug investigates it and reports itbull Someone finds a bug (testerdeveloperclient)

bull Tester verifies it and puts it in a databasebull Programmer defends it or fixes it after consulting with higher

managementbull Tester verifies the fix if it is decided to be fixed

bull Someone finds a bug (testerdeveloperclient)bull Tester verifies it and puts it into a database of bugsbull PM or Test Manager decides on the bug assigns priorities to

bugs and assigns to developersbull Tester verifies the fix and releases it

6

Typical life Cycle

7

Bug Advocacy or how to get your bugs fixed

As a tester bug reports are your primary work product

The quality of your communication drives the success of your bug reports

ldquoThe best tester isnrsquot the one who finds the maximum number of bugs or the most critical bugs The best tester is the one who gets the most bugs fixedrdquo

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

4

QUALITY ACCORDING TO-WHO

Project Manager

Developer

Testers

User Interface Design

Writing

Customer Service

Marketing

5

Basic concepts - Bug WORKFLOW

bull Bug workflows differ a lot from company to companybull A tester finds a bug investigates it and reports itbull Someone finds a bug (testerdeveloperclient)

bull Tester verifies it and puts it in a databasebull Programmer defends it or fixes it after consulting with higher

managementbull Tester verifies the fix if it is decided to be fixed

bull Someone finds a bug (testerdeveloperclient)bull Tester verifies it and puts it into a database of bugsbull PM or Test Manager decides on the bug assigns priorities to

bugs and assigns to developersbull Tester verifies the fix and releases it

6

Typical life Cycle

7

Bug Advocacy or how to get your bugs fixed

As a tester bug reports are your primary work product

The quality of your communication drives the success of your bug reports

ldquoThe best tester isnrsquot the one who finds the maximum number of bugs or the most critical bugs The best tester is the one who gets the most bugs fixedrdquo

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

5

Basic concepts - Bug WORKFLOW

bull Bug workflows differ a lot from company to companybull A tester finds a bug investigates it and reports itbull Someone finds a bug (testerdeveloperclient)

bull Tester verifies it and puts it in a databasebull Programmer defends it or fixes it after consulting with higher

managementbull Tester verifies the fix if it is decided to be fixed

bull Someone finds a bug (testerdeveloperclient)bull Tester verifies it and puts it into a database of bugsbull PM or Test Manager decides on the bug assigns priorities to

bugs and assigns to developersbull Tester verifies the fix and releases it

6

Typical life Cycle

7

Bug Advocacy or how to get your bugs fixed

As a tester bug reports are your primary work product

The quality of your communication drives the success of your bug reports

ldquoThe best tester isnrsquot the one who finds the maximum number of bugs or the most critical bugs The best tester is the one who gets the most bugs fixedrdquo

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

6

Typical life Cycle

7

Bug Advocacy or how to get your bugs fixed

As a tester bug reports are your primary work product

The quality of your communication drives the success of your bug reports

ldquoThe best tester isnrsquot the one who finds the maximum number of bugs or the most critical bugs The best tester is the one who gets the most bugs fixedrdquo

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

7

Bug Advocacy or how to get your bugs fixed

As a tester bug reports are your primary work product

The quality of your communication drives the success of your bug reports

ldquoThe best tester isnrsquot the one who finds the maximum number of bugs or the most critical bugs The best tester is the one who gets the most bugs fixedrdquo

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

8

BUG

ldquoAnything that causes an unnecessary or unreasonable reduction of the quality of a software productrdquo

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

9

Effective Bug Advocacy

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

10

Itrsquos not only about reporting the bug

bull Client complains of a wave of serious problems after product delivery (eg defective firmware)

ndash Why were these serious bugs not found in testing

1048707 They WERE found in testing AND reported

ndash Why didnrsquot the programmers fix them

1048707 They didnrsquot understand what they were reading

ndash What was wrong with the bug reports

1048707 The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

11

Bug advocacy = selling bugs

bull Time is in short supply If you want to convince the programmer to spend his time fixing your bug you may have to sell him on it

(Your bug How can it be your bug The programmer made it not you right Itrsquos the programmerrsquos bug Well yes but you found it so now itrsquos yours too)

bull Sales revolves around two fundamental objectives Motivate the buyer (Make him WANT to fix the bug) Overcome objections (Get past his excuses and reasons for not

fixing the bug)

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

12

Overcoming Objections - Most common objections

bull These make programmers resist spending time on a bug Canrsquot replicate the defect or not reproducible in my machine Strange and complex set of steps required to induce the failure Not enough information to know what steps are required and it will take

a lot of work to figure them out Unrealistic (eg ldquocorner caserdquo) It will take a lot of work to fix the defect A fix will introduce too much risk into the code No perceived customer impact Unimportant (no one will care if this is wrong minor error or unused

feature) Thatrsquos not a bug itrsquos a feature Management doesnrsquot care about bugs like this The programmer doesnrsquot like trust you (or the customer who is

complaining about the bug)

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

13

Motivating Bug fixer

bull Some things that will often make programmers want to fix the bug It looks really bad It looks like an interesting puzzle and interests the programmerrsquos

curiosity It will affect lots of people Getting to it is trivially easy It has embarrassed the company or a bug like it embarrassed a

competitor One of its ldquocousinsrdquo embarrassed the company or a competitor Management (that is someone with influence) has said that they

really want it fixed

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

14

Motivating the Bug Fix

bull When you run a test and find a failure yoursquore looking at a symptom not at the underlying fault You may or may not have found the best example of a failure that can be caused by the underlying fault

bull Therefore you should do some follow-up work to try to prove that a

defect

is more serious than it first appears is more general than it first appears

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

15

Motivating the Bug Fix Make it More Serious

bull Look up for Follow-Up errors

Three types of follow-up testing Vary my behavior (change the conditions by changing what I do) Vary the options and settings of the program (change the

conditions by changing something about the program under test) Vary the software and hardware environment

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

16

Motivating the Bug Fix Show it more general

bull Look for configuration dependencies

Bugs that donrsquot fail on the programmerrsquos machine are much less credible (to that programmer)

Question How many programmers does it take to change a light bulbAnswer Whatrsquos the problem The bulb at my desk works fine

bull Un-corner your corner cases

We test at extreme values because these are the most likely places to show a defect But once we find the defect we donrsquot have to stick with extreme value tests

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

17

Writing Bug Report

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

18

REPORTING ERRORS

bull As soon as you run into a problem in the software fill out a Problem Report form In the well written report you

Explain how to reproduce the problemAnalyze the error so you can describe it in a minimum number of

steps Include all the stepsMake the report easy to understandKeep your tone neutral and non-antagonisticKeep it simple one bug per report If a sample test file is essential for reproducing a problem reference

it and attach the test file

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

19

Important Parts of the Report Problem Summary

bull Problem report number must be uniquebull Problem summary (problem title) One-line summary of the problembull Date reported date of initial reportbull Report type eg coding error design issue documentation mismatch

suggestion querybull Can you reproduce the bug yes no sometimes unknownbull Severity assigned by tester Some variation on small medium largebull Priority assigned by programmerproject managerbull Reported by original reporterrsquos name Some forms add an editorrsquos namebull Program (or component) name the visible item under testbull Release number like Release 20bull Version (build) bull identifier like version C or version 20000802abull Problem and how to reproduce itbull Configuration(s) hw and sw configurations under which the bug was found

and replicated

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

20

Summary

bull Quality is subjectivebull Bugs are threats to the value of the product to a stakeholderbull In general bug reporting is a persuasive activitybull We can simplify the persuasive task by saying that we are trying to motivate people to fix our bugs and overcome their objections to fixing those bugs bull The entire bug-handling process involves a series of decisions that

are heavily influenced by the decision-makersrsquo preconceived notionsmdashtheir heuristics and biasesmdashabout whose reports are worthwhile and what problems are likely to be important The credibility of the tester has a big impact on these decisions

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU

THANK YOU

21

• PowerPoint Presentation
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Effective Bug Advocacy
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• THANK YOU