Debugging application crashes is an expensive and time-taking process, relying on the developer’s expertise, and requiring knowledge about the system. Over the years, the research community has developed several automated approaches to ease debugging. Among those approaches, search-based crash reproduction, which tries to generate a test case capable of reproducing a given crash to make it observable to the developers, solely based on the stack trace included in the crash report. We believe that this makes crash reproduction the perfect candidate to achieve end-to-end crash fault localization. In this thesis, we explore and empirically evaluate the usage of search-based crash reproduction combined with spectrum-based fault localization on 50 real-world crashes. Starting from a crash report, we generate crash-reproducing test cases and use them in conjunction with the existing or an automatically generated unit test suite as input for spectrum-based fault localization. Our results show that, although, hand-written test cases remain the most efficient in the general scenario, automatically generated crash-reproducing test cases still reduce the number of statements to be investigated by developers. Additionally, when considering the best-case scenario where only crash-reproducing test cases covering the fault are evaluated, we observe no statistically significant difference between the accuracy of fault localization when using hand-written or automatically generated test cases. Our results confirm the feasibility of end-to-end automated crash fault localization. The results also identify new challenges for both automated test case generation and fault localization, as well as when they are combined.

Being a bank, bunq deals with transaction fraud on a regular basis. All transactions that are handled by bunq are monitored for these cases of fraud by a transaction monitoring system. When this system flags a transaction as being possibly fraudulent, a bunq employee has to manually check this transaction. The problem with the current system is that it proves to be time consuming and labor intensive. This is caused by the fact that there are a lot of transactions which are falsely flagged as possibly fraudulent, these transactions are called false positives. This resulted in a demand for a system which reduced the number of false positives and thereby the time needed to manually check the flagged transactions.

To fulfill this demand, bunq has been working on creating a machine learning model which classifies transactions as fraudulent or legitamte. This machine learning model has shown promising results during test runs on historical data. However, it was not yet production ready, because it was very slow and there existed no connection with the existing bunq back-end.

During the project, a new transaction monitoring system was designed and implemented. The new system uses a combination of a bunq-made machine learning model and a set of pre-defined rules to flag a transaction as possibly fraudulent or not. The final system implementation consists out of 5 different components: (1) an incoming transaction system, responsible for noticing new transactions and segregating those over different workers so that they can be classified in parallel, (2) an information gathering system, which efficiently gathers large sets of needed information for the classification, (3) a machine learning model server, which enables fast communication with altering machine learning models, (4) a set of pre-defined rules, which check transactions for indicators of fraud and (5) a Grafana dashboard which monitors the performance and statistics of the machine learning model, the pre-defined rules and our system.

The system is fully tested by unit and integration tests. Furthermore, new machine learning models and pre-defined rules can be easily adopted. All the above mentioned components are implemented and fully working. The final implementation is focused on integrating the system in the currently existing bunq back-end, because the system will actually be used in production.