Computer science (Informatik), Doktor-Ingenieur Dr.-Ing.
Saarland University: 01/2006 – 06/2011
Dissertation: Replaying and Isolating Failure-Inducing Program Interactions (magna cum laude, Software Engineering Chair, Prof. Dr. Andreas Zeller)
Fields of study: software engineering, automated debugging, dynamic program analysis, capture and replay of program executions
Nominated for Best Paper Award at ISSTA – At the International Symposium on Software Testing and Analysis (ISSTA) 2011 in Toronto, Canada, my paper “Minimizing Reproduction of Software Failures” was nominated for the Best Paper Award. Other researchers referred to this new approach as “the end of manual debugging”.
For my PhD thesis, I used capture/replay techniques to isolate failure-inducing interactions within programs; e.g., component or object interactions. Other researchers referred to this new approach as “the end of manual debugging”:
When a program fails, developers need to solve two issues: (a) reproducing the failure, and (b) fixing the defect such that the failure no longer occurs. Reproducing is crucial because one can examine the problem and eventually decide whether it has been fixed. Fixing is difficult because the developer needs to search the defect that causes the failure—a search in space and time which becomes the more difficult the larger the program state, and the distance between defect and failure.
Capture and replay techniques can be used to reproduce a failure. So, developers can analyze the problem. In addition, these techniques can be used to capture and replay selected parts of the program. Especially, parts that are involved in the failure. However, even if developers can focus on relevant parts of the program, the behavior (or, interactions as method calls, field accesses, etc.) within these parts to be analyzed can be very complex. By combining replay with minimization algorithms (e.g., with delta debugging) the captured interactions can be simplified until only the failure-inducing interactions remain. If the number of remaining interactions is sufficiently small, it is fairly easy to fix the defect.
Indeed, at the end, these methods can pinpoint the actual defect: “Out of the 187,532 interactions in the
addressbook component, two incoming method calls suffice to faithfully reproduce the failure at will.”
The result is a minimal unit test that faithfully reproduces the failure at will: “Out of these 14,628 interactions, only 2 are required”. In a study of 17 real-life bugs, I reduced the search space to 0.22 % of the source code, with only 1–12 interactions left to examine.
Replaying and Isolating Failure-Inducing Program Interactions
PhD thesis 2011 (Saarland University, Germany)
Doctorate “magna cum laude” – PhD with great honor.
Minimizing Reproduction of Software Failures
ISSTA 2011 (Toronto, Ontario, Canada)
Nominated for Best Paper Award – Other researchers referred to this new approach as “the end of manual debugging”.
Computer science (Informatik), Diplom-Informatiker Dipl.-Inform.
Saarland University: 10/1999 – 12/2005
Diploma thesis: Locating Failure-Inducing Code Changes in an Industrial Environment (very good / outstanding performance, Software Engineering Chair, Prof. Dr. Andreas Zeller)
Fields of study: computer science, software engineering, business informatics, information systems, information science
Eclipse Innovation Grant – My diploma thesis was in the context of the “IBM Eclipse Innovation Grant on automated debugging”, which was awarded to Prof. Dr. Andreas Zeller.
Internship: My diploma project was a close collaboration of the Software Engineering Chair (Prof. Dr. Andreas Zeller) with 1&1 Internet AG where I worked as intern.
In the context of my diploma thesis, I applied delta debugging on program changes to debug regressions automatically. The corresponding framework DDchange was developed in cooperation with 1&1 Internet AG, where I worked as intern.
A regression is a common type of failure that occurs while changing source code of a working program: “Yesterday, your program worked. Today, it does not. Why?” Manual debugging of regressions is costly in terms of labor and time, it annoys developers, and costs organizations a lot of money.
DDchange provides a platform that seamlessly integrates automated determination of failure-inducing code changes with common development processes. Automated determination may increase efficiency, improve productivity, while saving time and money. Because established processes need not to be adapted, start-up costs and risks are low.
The platform supplies two tools in the form of plug-ins. (1) The Eclipse plug-in integrates automated determination of failure-inducing changes with a prominent IDE. As soon as a unit test fails, it can be debugged automatically. (2) The Maven plug-in enriches continuous building and testing with automated debugging. Instead of a simple failure report, we obtain valuable information about failure-inducing changes-without lifting a finger: “The failure cause is the change in line 37 of file StringUtils.java.”
The plug-ins are instances of the DDchange framework that contains all the basic functionality that allows to build tools that enable automatic determination of failure-inducing changes. Using that framework, implementing new tools that debug other types of failure is quite easy and simple—again saving time and money.
Locating Failure-Inducing Code Changes in an Industrial Environment
Diploma Thesis 2005 (Saarland University, Germany)
Eclipse Innovation Grant – My diploma thesis was in the context of the “IBM Eclipse Innovation Grant on automated debugging”.
Automated debugging in Eclipse
OOPSLA 2005 (San Diego, CA, USA)