Bug Advocacy

Post on 28-Nov-2014

157 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

GTech Technology Focus Group organised an event on "Trends and Transformations on Quality Assurance & Quality Control"

Transcript

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

                                            top related