Demo Data from EDBT 2026 / reviewers in the wild / expert
Benedikt Hauptmann
dblp:77/8388
· DBLP profile ↗
9ranked-venue papers
4as first author
0since 2021 · last 2020
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 9 · 4 first-authorArtificial intelligence and machine learning · 1Applied, interdisciplinary, general and emerging computing · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
2 papers |
Software testing · 48% Empirical software engineering · 25% Program analysis · 23% |
Topics — the 9 heaviest of 10, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Empirical software engineering
mining software repositories |
0.2 | 1 | 2013 | Hunting for smells in natural language tests · ICSE 2013 |
Software testing
test quality |
0.2 | 1 | 2013 | Hunting for smells in natural language tests · ICSE 2013 |
Software testing › test quality › test code quality
test smells |
0.2 | 1 | 2013 | Hunting for smells in natural language tests · ICSE 2013 |
Software testing
test suite evaluation |
0.2 | 1 | 2013 | Hunting for smells in natural language tests · ICSE 2013 |
Program analysis › code quality analysis
dead code detection |
0.1 | 1 | 2012 | How much does unused code matter for maintenance? · ICSE 2012 |
Empirical software engineering › software analytics
deployed software analysis |
0.1 | 1 | 2012 | How much does unused code matter for maintenance? · ICSE 2012 |
Program analysis
dynamic analysis |
0.1 | 1 | 2012 | How much does unused code matter for maintenance? · ICSE 2012 |
Software testing › dynamic testing
manual testing |
0.0 | 1 | 2013 | Hunting for smells in natural language tests · ICSE 2013 |
Software testing
system testing |
0.0 | 1 | 2013 | Hunting for smells in natural language tests · ICSE 2013 |
Methods — techniques the papers use, named apart from their topics
empirical study · 0.2static analysis · 0.1dynamic analysis · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2020 | Towards Causality Extraction from RequirementsabstractSystem behavior is often based on causal relations between certain events (e.g. If event1, then event2). Consequently, those causal relations are also textually embedded in requirements. We want to extract this causal knowledge and utilize it to derive test cases automatically and to reason about dependencies between requirements. Existing NLP approaches fail to extract causality from natural language (NL) with reasonable performance. In this paper, we describe first steps towards building a new approach for causality extraction and contribute: (1) an NLP architecture based on Tree Recursive Neural Networks (TRNN) that we will train to identify causal relations in NL requirements and (2) an annotation scheme and a dataset that is suitable for training TRNNs. Our dataset contains 212,186 sentences from 463 publicly available requirement documents and is a first step towards a gold standard corpus for causality extraction. We encourage fellow researchers to contribute to our dataset and help us in finalizing the causality annotation process. Additionally, the dataset can also be annotated further to serve as a benchmark for other RE-relevant NLP tasks such as requirements classification. Jannik Fischbach, Benedikt Hauptmann, Lukas Konwitschny, Dominik Spies, Andreas Vogelsang |
RE | 2 |
| 2016 | Quality Assurance of Requirements Artifacts in Practice: A Case Study and a Process Proposal
Henning Femmer, Benedikt Hauptmann, Sebastian Eder, Dagmar Moser |
PROFES | 2 |
| 2015 | Generating refactoring proposals to remove clones from automated system testsabstractAutomated system tests often have many clones, which make them complex to understand and costly to maintain. Unfortunately, removing clones is challenging as there are numerous possibilities of how to refactor them to reuse components such as subroutines. Additionally, clones often overlap partly which makes it particularly difficult to decide which parts to extract. If done wrongly, reuse potential is not leveraged optimally and structures between tests and reuse components will become unnecessarily complex. We present a method to support test engineers in extracting overlapping clones. Using grammar inference algorithms, we generate a refactoring proposal that demonstrates test engineers how overlapping clones can be extracted. Furthermore, we visualize the generated refactoring proposal to make it easily understandable for test engineers. An industrial case study demonstrates that our approach helps test engineers to gain information of the reuse potential of test suites and guides them to perform refactorings. Benedikt Hauptmann, Elmar Jürgens, Volkmar Woinke |
ICPC | 1 |
| 2014 | Which Features Do My Users (Not) Use?abstractMaintenance of unused features leads to unnecessary costs. Therefore, identifying unused features can help product owners to prioritize maintenance efforts. We present a tool that employs dynamic analyses and text mining techniques to identify use case documents describing unused features to approximate unnecessary features. We report on a preliminary study of an industrial business information system over the course of one year quantifying unused features and measuring the performance of the approach. It indicates the relevance of the problem and the capability of the presented approach to detect unused features. Sebastian Eder, Henning Femmer, Benedikt Hauptmann, Maximilian Junker |
ICSME | 3 |
| 2014 | An expert-based cost estimation model for system test executionabstractTo execute system tests, two fundamentally different execution techniques exist: manual and automated execution. For each system test suite, one must decide how to employ those techniques (this strategy is called execution mode). Despite general conditions such as fixed testing strategies or development philosophies, almost all projects permit a wide range of possible execution modes to choose from. In industry, execution techniques are often chosen by experts based on rules of thumb, experience and best practices. Although the results are mostly tolerable, they may be not cost-effective. In retrospect, it is often unclear on what basis those decisions were made, making it difficult to assess whether they are still valid. Finally, it is hard to predict the costs for test execution beforehand. We introduce a cost model to estimate the economic impact of execution modes. Our cost model is based on expert estimations and gives additional input for testing experts in balancing pros and cons of execution modes at hand. Furthermore, it helps documenting and persists decisions during the life time of a test suite. Additionally, we report on a first case study, applying our cost model in industry. Benedikt Hauptmann, Maximilian Junker, Sebastian Eder, Christian Amann, Rudolf Vaas |
ICSSP | 1 |
| 2013 | Hunting for smells in natural language testsabstractTests are central artifacts of software systems and play a crucial role for software quality. In system testing, a lot of test execution is performed manually using tests in natural language. However, those test cases are often poorly written without best practices in mind. This leads to tests which are not maintainable, hard to understand and inefficient to execute. For source code and unit tests, so called code smells and test smells have been established as indicators to identify poorly written code. We apply the idea of smells to natural language tests by defining a set of common Natural Language Test Smells (NLTS). Furthermore, we report on an empirical study analyzing the extent in more than 2800 tests of seven industrial test suites. Benedikt Hauptmann, Maximilian Junker, Sebastian Eder, Lars Heinemann, Rudolf Vaas |
ICSE | 1 |
| 2012 | How much does unused code matter for maintenance?abstractSoftware systems contain unnecessary code. Its maintenance causes unnecessary costs. We present tool-support that employs dynamic analysis of deployed software to detect unused code as an approximation of unnecessary code, and static analysis to reveal its changes during maintenance. We present a case study on maintenance of unused code in an industrial software system over the course of two years. It quantifies the amount of code that is unused, the amount of maintenance activity that went into it and makes the potential benefit of tool support explicit, which informs maintainers that are about to modify unused code. Sebastian Eder, Maximilian Junker, Elmar Jürgens, Benedikt Hauptmann, Rudolf Vaas, Karl-Heinz Prommer |
ICSE | 4 |
| 2012 | Can clone detection support test comprehension?abstractTests are central artifacts of software systems. Therefore, understanding tests is essential for activities such as maintenance, test automation, and efficient execution. Redundancies in tests may significantly decrease their understandability. Clone detection is a technique to find similar parts in software artifacts. We suggest using this technique to gain a better understanding of tests and to provide guidance for testing activities. We show the capabilities as well as the limits of this approach by conducting a case study analyzing more than 4000 tests of seven industrial software systems. Benedikt Hauptmann, Maximilian Junker, Sebastian Eder, Elmar Jürgens, Rudolf Vaas |
ICPC | 1 |
| 2012 | A case study on variability in user interfacesabstractSoftware Product Lines (SPL) enable efficient derivation of products. SPL concepts have been applied successfully in many domains including interactive applications. However, the user interface (UI) part of applications has barely been addressed yet. While standard SPL concepts allow derivation of functionally correct UIs, there are additional non-functional requirements, like usability, which have to be considered. This paper presents a case study investigating UI variability found in variants of the commercial web-based information system HIS-GX/QIS. We analyze which aspects of a UI vary and to which degree. The results show that just tweaking the final UI (e.g., using stylesheets) is not sufficient but there is a need for more customization which must be supported by, e.g., UI-specific models. Andreas Pleuß, Benedikt Hauptmann, Markus Keunecke, Goetz Botterweck |
SPLC (1) | 2 |