Because you can't fix what you don’t know is broken

Mon, 2015-08-03 06:46

by Marcel Bruch, Codetrails

Marcel Bruch

It's a well-known fact that fixing bugs is 25x cheaper during the development of a software product than fixing them after the product was shipped to your customers [1].  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 silently disappear with bad feelings about your product...

Eclipse Error Reporting In Eclipse Mars we introduced an Automated Error Reporting tool to provide committers with the necessary information about where their code breaks. We combined this with various means to get in touch with reporters and to run semi-automated, client-side bug analyses - with great success: since its introduction, around 1000 bug reports have been created of which around 400 bugs have been FIXED to date.

Error LogIf you’d like to learn about how Eclipse projects embrace automated error reports to spot and fix issues, add this session to your schedule now. It will be an interesting, insightful but maybe disillusioning experience with some great pointers about what you can expect when introducing automated error reports to your products - all based on 9 months of experience with the Eclipse Mars users and the committer community.

No matter how small your app is. Make sure you know when it breaks.

 

 

 

 

[1] The Economic Impacts of Inadequate Infrastructure for Software Testing, National Institute of Standards & Technology,