Bug Advocacy

Download Bug Advocacy

Post on 28-Nov-2014




0 download

Embed Size (px)


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


<ul><li><p>SE-MENTOR TRAINING</p></li><li><p>CONTENTSBasic concepts- Software Quality what it meansBasic concepts- Bug WorkflowTypical life cycle of a bugBug Advocacy or how to get your bugs fixed. !!!What is a bug, Error, Failure, DefectEffective Bug AdvocacyIts not only about reporting the bugBug advocacy = selling bugsOvercoming Objections and Motivating bug fixer.Writing Effective Bug ReportsReporting ErrorsImportant Parts of the Report: Problem Summary</p></li><li><p>BASIC CONCEPTS SOFTWARE QUALITY </p><p>What is software quality.</p><p> Quality is Conformance with requirements.-Actual requirements, which may or may not be whats written down.</p></li><li><p>*QUALITY ACCORDING TO-WHOProject ManagerDeveloperTestersUser Interface DesignWritingCustomer ServiceMarketing</p></li><li><p>*Basic concepts - Bug WORKFLOWBug workflows differ a lot from company to company.A tester finds a bug , investigates it, and reports itSomeone finds a bug (tester/developer/client)Tester verifies it and puts it in a database.Programmer defends it or fixes it after consulting with higher management.Tester verifies the fix if it is decided to be fixed.Someone finds a bug (tester/developer/client)Tester verifies it and puts it into a database of bugs.PM or Test Manager decides on the bug assigns priorities to bugs and assigns to developers.Tester verifies the fix and releases it.</p></li><li><p>*Typical life Cycle</p></li><li><p>*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.The best tester isnt 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 fixed.</p></li><li><p>*BUG </p><p>Anything that causes an unnecessary or unreasonable reduction of the quality of a software product</p></li><li><p>*</p><p>Effective Bug Advocacy</p></li><li><p>*Its not only about reporting the bugClient complains of a wave of serious problems after product delivery (eg: defective firmware) Why were these serious bugs not found in testing? They WERE found in testing AND reported Why didnt the programmers fix them? They didnt understand what they were reading What was wrong with the bug reports? The problem is that the testers focused on creating reproducible failures rather than on the quality of their communication.</p></li><li><p>*Bug advocacy = selling bugsTime 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? Its the programmers bug. Well, yes, but you found it so now its yours too.) 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.)</p></li><li><p>*Overcoming Objections - Most common objectionsThese make programmers resist spending time on a bug:Cant 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 (e.g. corner case)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.)Thats not a bug, its a feature.Management doesnt care about bugs like this.The programmer doesnt like / trust you (or the customer who is complaining about the bug).</p></li><li><p>*Motivating Bug fixerSome things that will often make programmers want to fix the bug:It looks really bad.It looks like an interesting puzzle and interests the programmers 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 cousins embarrassed the company or a competitor.Management (that is, someone with influence) has said that they really want it fixed.</p></li><li><p>*Motivating the Bug FixWhen you run a test and find a failure, youre 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. Therefore you should do some follow-up work to try to prove that a defect: </p><p>is more serious than it first appears.is more general than it first appears.</p></li><li><p>*Motivating the Bug Fix: Make it More SeriousLook up for Follow-Up errors</p><p>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.</p></li><li><p>*Motivating the Bug Fix: Show it more generalLook for configuration dependencies</p><p> Bugs that dont fail on the programmers machine are much less credible (to that programmer).Question: How many programmers does it take to change a light bulb?Answer: Whats the problem? The bulb at my desk works fine!</p><p>Un-corner your corner casesWe test at extreme values because these are the most likely places to show a defect. But once we find the defect, we dont have to stick with extreme value tests.</p></li><li><p>*</p><p>Writing Bug Report</p></li><li><p>*REPORTING ERRORSAs soon as you run into a problem in the software, fill out a Problem Report form. In the well written report, you:</p><p>Explain how to reproduce the problem.Analyze the error so you can describe it in a minimum number of steps.Include all the steps.Make the report easy to understand.Keep your tone neutral and non-antagonistic.Keep it simple: one bug per report.If a sample test file is essential for reproducing a problem, reference it and attach the test file.</p></li><li><p>*Important Parts of the Report: Problem SummaryProblem report number: must be uniqueProblem summary (problem title): One-line summary of the problemDate reported: date of initial reportReport type: e.g. coding error, design issue, documentation mismatch, suggestion, queryCan you reproduce the bug: yes / no / sometimes / unknownSeverity: assigned by tester. Some variation on small / medium / largePriority: assigned by programmer/project managerReported by: original reporters name. Some forms add an editors name.Program (or component) name: the visible item under testRelease number: like Release 2.0Version (build) identifier like version C or version 20000802aProblem and how to reproduce it.Configuration(s): h/w and s/w configurations under which the bug was found and replicated.</p></li><li><p>*SummaryQuality is subjectiveBugs are threats to the value of the product to a stakeholderIn general, bug reporting is a persuasive activityWe 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. The entire bug-handling process involves a series of decisions that are heavily influenced by the decision-makers preconceived notionstheir heuristics and biasesabout whose reports are worthwhile and what problems are likely to be important. The credibility of the tester has a big impact on these decisions</p></li><li><p>THANK YOU*</p></li></ul>