Automating Software Failure Reporting

Authors:
Brendan Murphy
Affiliations:
Microsoft Research
Venue:
Queue - System Failures
Year:
2004

Citing 0
Cited 12

Dingo: taming device drivers

Proceedings of the 4th ACM European conference on Computer systems
Debugging in the (very) large: ten years of implementation and experience

Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles
Scoring and thresholding for availability

IBM Systems Journal
A realistic evaluation of memory hardware errors and software system susceptibility

USENIXATC'10 Proceedings of the 2010 USENIX conference on USENIX annual technical conference
Testing closed-source binary device drivers with DDT

USENIXATC'10 Proceedings of the 2010 USENIX conference on USENIX annual technical conference
Me hates this: exploring different levels of user feedback for (usability) bug reporting

CHI '11 Extended Abstracts on Human Factors in Computing Systems
aComment: mining annotations from comments and code to detect interrupt related concurrency bugs

Proceedings of the 33rd International Conference on Software Engineering
Characterizing the differences between pre- and post- release versions of software

Proceedings of the 33rd International Conference on Software Engineering
Cosmic rays don't strike twice: understanding the nature of DRAM errors and the implications for system design

ASPLOS XVII Proceedings of the seventeenth international conference on Architectural Support for Programming Languages and Operating Systems
Operating system reliability from the quality of experience viewpoint: an exploratory study

Proceedings of the 28th Annual ACM Symposium on Applied Computing
Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles

ACM SIGOPS 24th Symposium on Operating Systems Principles
VirtuOS: an operating system with kernel virtualization

Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles

Quantified Score

Hi-index	0.00

Visualization

Abstract

There are many ways to measure quality before and after software is released. For commercial and internal-use-only products, the most important measurement is the user's perception of product quality. Unfortunately, perception is difficult to measure, so companies attempt to quantify it through customer satisfaction surveys and failure/behavioral data collected from its customer base. This article focuses on the problems of capturing failure data from customer sites. To explore the pertinent issues I rely on experience gained from collecting failure data from Windows XP systems, but the problems you are likely to face when developing internal (noncommercial) software should not be dissimilar.