Because you can't fix what you don't know is broken - How automated error reporting minimizes bug fix cycles and boosts your product quality
Given these numbers it is obvious why detecting bugs as early as possible in the development process is key to every quality assurance team. Teams often rely on a 'ship early, ship often' strategy to learn where their software breaks 'in the field'. But while it is easy to spot problems in a web app, it is many times harder to spot issues if your app runs on a client's desktop or mobile device. The key problem here is that your users only rarely report back all problems they experience. They usually just uninstall the software and disappear with bad feelings about your product...
Quality is a governing concern for Eclipse Committers as well. Thus, Eclipse Mars introduced an Automated Error Reporting for the Eclipse IDE to provide committers with the necessary feedback where their code breaks, gives committers various means to get in touch with their users, semi-automatically gathers information like runtime configurations and the like – and thus helps committers to improve the IDE on their way to the next release.
This talk will introduce you to the benefits of automated error reporting based on 9 months of experiences with Eclipse Luna and Mars. It will provide insights into bug fixing rates, number of incoming error reports, user acceptance and critiques, and will shed some light on common coding problems and troubling areas in the Eclipse landscape. Finally, the talk will outline how to integrate automated error reporting into your own applications, may it be an Eclipse RCP based app or any arbitrary Java application.
No matter how small your app is. Make sure you know when it breaks.
 The Economic Impacts of Inadequate Infrastructure for Software Testing, National Institute of Standards & Technology, http://www.nist.gov/director/planning/upload/report02-3.pdf