Defect Tracking CSC444F’06 Lecture 9 1

Defect Tracking CSC444F'06 Lecture 9 1

Defect Tracking Keeping track of all the defects that have been discovered Keeping track of all the steps required to validate, correct, and take preventative action for a defect Necessary because – to not lose any reported defects – to co-ordinate defect resolution – to ensure coders don’t work on non-defects Features masquerading as defects Wasting time fixing something that isn’t broken Wasting time chasing down a badly reported defect – to control defect correction activity ensure the right defects are being worked on In practice: – A database of defect records – A workflow driven by the state and owner fields. CSC444F'06 Lecture 9 2

Aside on “Bugs” Why not call defects “bugs”? First used because a moth flew into a vacuum-tube computer and ate away at the wires. “bugs” are things that happen to you, outside of your control A “defect” is something that is caused by a coder making a correctable mistake. – Gets you into the right mindset CSC444F'06 Lecture 9 3

Defect Information Where Found – product, release, version, hardware, os, drivers, general area Who Found It – customer, internal, when Description of the Defect – summary, description, how to reproduce, associated data – links to related defects or features Triage – severity, likelihood priority Audit Trail – all changes to the defect data, by whom, when State – state, owner CSC444F'06 Lecture 9 4

Priority Matrix Likelihood Priority Severity Low Medium High Crash, bad data 2 1 1 Work around 5 3 2 Cosmetic 5 4 3 Submitter of defect chooses severity and likelihood – May later correct if determined to be an exaggeration or in error System assigns a priority according to the priority matrix Humans may change the priority using their judgment – No need to stick to “the matrix”, which is after all too simple to account for every contingency CSC444F'06 Lecture 9 5

Defect Workflow WIP Valid Fixed Closed New Disputed issue customer QA CSC444F'06 Lecture 9 6

Coder Assignment Matrix Defect is auto-assigned to a coder based upon – The product in which it was found – The functional area of the defect Catch-all category (misc.) goes to a team lead charged with defect assignment and overview for assignment elsewhere. – Keeps track of the defect load by priority on all coders – Balanced the load – Chips in where needed Developers may move the defect to the appropriate coder without management permission. – May also move to team lead for re-assignment – Natural corollary to auto-assignment. CSC444F'06 Lecture 9 7

Management Controls One of main purposes is to provide defect visibility to enable management to ensure defects are appropriately prioritized. Management must: – – – – overview all active defect records ensure priorities are good if languishing too long in a given state, act ensure coders are working on defects of appropriate priority at any given time System Support – Most systems can be configured to send e-mail and/or re-assign to manager when certain conditional action thresholds are reached – E.g., prio 1 defect with state unchanged for 24 hrs. Post daily reports of overdue defects CSC444F'06 Lecture 9 8

Controls on the System Most defect tracking systems allow permissions to be set up. each user is given various group memberships: – coders, testers, managers, builders, Permissions can then be set up by – group, state, field Don’t do it! – Q. what are you trying to control? A. source code – Putting restrictions on defect control system will not help you to gain control of the source it will hurt coders will work around silly security restrictions defect system will not accurately reflect what is being worked on – Dirty data will go uncorrected CSC444F'06 Lecture 9 9

Metrics Another purpose for defect tracking is to enable gathering of good, clean defect arrival/departure data. Gives insight into productivity of – coders fixing defects – testers finding defects Clean data is essential – e.g., if no way to validate defects lots of arrivals may be due to bad code or to bad defect triage may expend a lot of effort on coding initiatives and numbers will go the wrong way! – Must quickly get defects out of New and Fixed. Arrivals: – defects per day entering into Valid Departures: – defects per day going from Fixed to Closed Total: – sum of defects in states Valid, WIP, and Fixed. CSC444F'06 Lecture 9 10

Metrics arrivals WIP departures Valid Fixed HURRY! HURRY! HURRY! Closed New Disputed CSC444F'06 Lecture 9 11

Metrics Example 100 80 60 defects total arrivals 40 departures net 20 0 1 3 5 7 9 11 13 15 17 19 21 23 25 -20 days CSC444F'06 Lecture 9 12

Towards GA These metrics should be tracked: – by product – by priority Company should establish shipping thresholds – e.g., no known priority 1 or 2 defects arrival rate for priority 1-3 1 defect per day Watch trends, compare to last release. If bad: – – – – “bug Olympics” “bug blitz weekends” slip date clean up the architecture CSC444F'06 Lecture 9 13

Relationship to SCCS Two reasons for changes to source: – fix a defect – add a feature Can tie SCCS and defect/feature tracking systems to control this Whenever a coder checks in a change – Prompted for: defect or feature # – check to ensure assigned to them – persistently stored This allows management to see – – – – what was changed why it was changed by whom how much of a change Is this really control? – yes: audit trail CSC444F'06 Lecture 9 14

Depot Change Report Date Range: Last 24 hours David Kathleen Douglas D100203 23 F100350 108 D155401 34 56 D100343 D100453 10 1 F100782 Totals: CSC444F'06 Brian 508 24 108 Lecture 9 598 10 15

Defect Attribution Beginning to understand what are the systemic root causes of defects. Include as data in the defect tracking system that must be there before defect is closed Should record time taken to deal with it, or at least a “difficulty” field (high, medium, low) Attribute to: – where in the source code can identify modules whose re-design will add most bang-for-the-buck – which developer introduced it organizationally tricky but very useful – during what phase spec, design, code CSC444F'06 Lecture 9 16

Customer Issue Tracking Distinct from defect tracking Customers have many issues: – – – – – – – how to use software installation issues perceived problems problems that have already been resolved in a previous patch known issues ship me a manual, please Some of these issues will result in new defects Requirements of issue tracking systems will include: – – – – customer relationship management tie-in searchable knowledge bases customer tracking of issue progress CSC444F'06 Lecture 9 17

Shipping Known Defects 0-defects is not a sustainable software business – how many defects are acceptable? – how many are you shipping? Defect seeding – inject defects, see how many are found, use the ratio – hard to work this in practice Must measure customer satisfaction with perceived level of defects and correlate to known defects at ship. e.g., – If we ship with 350 known defects and customers are down on the release then it’s too high – If we ship with 50 and customers say “best release ever” super stable, then it’s good. Might want to use 50 as the shipping threshold, and then gradually lower that over time CSC444F'06 Lecture 9 18

Testing/Coding Effort Changes Can only compare across releases if have a consistent testing effort – same number of testers, same productivity, same time, same general size of the release If increase size of testing team relative to coding team, – ratio of known to unknown defects decreases Assume ratio is 50% – ship with 50 known, actually shipping 100 defects Add testers, raising ratio to 75% – ship with 75 known, actually shipping 100 defects good to know. If increasing testing effort without increasing coding efforts, will be hard-pressed to meet the old thresholds Add coders, lowering ratio to 25% – ship with 25 known, actually shipping 100 defects Add coders and testers – ratios stay the same – but will reach the thresholds faster for the same sized effort CSC444F'06 Lecture 9 19

Release Notes When shipping point releases, good to say which defects are fixed – hard to get this info! Start with sccs and defect tracking to see which defect corrections have been checked in since the last point release Must describe the defect in terms the users will understand – e.g., load this data file it crashes good enough to find and fix the defect not good enough for release notes – must track down the root cause, and extrapolate into what kind of situations will trigger the defect. – If doing this, must make it a part of the defect correction process CSC444F'06 Lecture 9 20

Automated Patching Facilities Ability for the software to query a server to see if it is up-to-date. – If not, then download an appropriate, ideally small, patch and apply it Distinguish “critical” from “optional” Run immediately after install Facility must be able to chain patches Determine smallest download combo to get you from where you are to current version Need excellent build/release disciplines to ensure release numbers completely identify the file set – will want to provide binary diff files as patches – need to be sure will dbl-check a checksum on all files before applying anything! CSC444F'06 Lecture 9 21

Automated Patching Technology A patch always starts with a complete image of the software installed into the file system. – A normal, regular release – Test it as such Use a patching utility to generate a binary diff patch – Point at release A and release Z Will generate a small patch self-installer that will move you from A to Z – Point at releases A,B,C and Z Will generate a somewhat larger patch self-installer that is capable of moving the software form any of the releases A,B, or C to Z – Larger, but saves due to common files between A,B,C – If no common files, is a waste. – End user may have to download: Patch 1: from A to W Patch 2: from W to Z CSC444F'06 Lecture 9 22