Authentication is a critical security feature for confirming the identity of a system's users, typically implemented with help from frameworks like Spring Security. It is a complex feature which should be robustly tested at all stages of development. Unit testing is an effective technique for fine-grained verification of feature behaviors that is not widely-used to test authentication. Part of the problem is that resources to help developers unit test security features are limited. Most security testing guides recommend test cases in a "black box" or penetration testing perspective. These resources are not easily applicable to developers writing new unit tests, or who want a security-focused perspective on coverage.

Traceability, a classic requirements engineering topic, is increasingly used in the context of model-based engineering. However, researchers and practitioners lack a concise terminology to discuss aspects of requirements traceability in situations in which engineers heavily rely on models and model-based engineering. While others have previously surveyed the domain, no one has so far provided a clear, unambiguous set of terms that can be used to discuss traceability in such a context. We therefore set out to cut a path through the jungle of terminology for model-based traceability, ground it in established terminology from requirements engineering, and derive an unambiguous set of relevant terms. We also map the terminology used in existing primary and secondary studies to our taxonomy to show differences and commonalities. The contribution of this paper is thus a terminology for model-based traceability that allows requirements engineers and engineers working with models to unambiguously discuss their joint traceability efforts.

Traceability has been acknowledged as an important part of the software development process and is considered relevant when performing tasks such as change impact and coverage analysis. With the growing popularity of issue tracking systems and version control systems developers began including the unique identifiers of issues to commit messages. The goal of this message tagging is to trace related artifacts and eventually establish project-wide traceability. However, the trace creation process is still performed manually and not free of errors, i. e. developers may forget to tag their commit with an issue id. The prototype spojitR is designed to assist developers in tagging commit messages and thus (semi-) automatically creating trace links between commits and an issue they are working on. When no tag is present in a commit message, spojitR offers the developer a short recommendation list of potential issue ids to tag the commit message. We evaluated our tool using an open-source project hosted by the Apache Software Foundation. The source code, a demonstration, and a video about spojitR is available online: https://github.com/SECSY-Group/spojitr.

Over the years, researcher proposed multiple information retrieval (IR) based bug localization techniques. The foundation of the approaches relies on textual similarity of the bug report description and the source code files. The basic assumption is that these descriptions are well suited to query the code base. However, often bug reports contain structured information such as stack traces and source code next to natural language, which might interfere with the initial belief. In this paper, we systematically analyze the influence of structured information on IR-based techniques. Therefore a study on 7,334 bug reports, out of which more than 30% contain structured information, was conducted. Our results show, that stack traces tend to negatively affect IR-based bug localization performance and require special handling.

Software and systems traceability is widely accepted as an essential element for supporting many software development tasks. Today's version control systems provide inbuilt features that allow developers to tag each commit with one or more issue ID, thereby providing the building blocks from which project-wide traceability can be established between feature requests, bug fixes, commits, source code, and specific developers. However, our analysis of six open source projects showed that on average only 60% of the commits were linked to specific issues. Without these fundamental links the entire set of project-wide links will be incomplete, and therefore not trustworthy. In this paper we address the fundamental problem of missing links between commits and issues. Our approach leverages a combination of process and text-related features characterizing issues and code changes to train a classifier to identify missing issue tags in commit messages, thereby generating the missing links. We conducted a series of experiments to evaluate our approach against six open source projects and showed that it was able to effectively recommend links for tagging issues at an average of 96% recall and 33% precision. In a related task for augmenting a set of existing trace links, the classifier returned precision at levels greater than 89% in all projects and recall of 50%.

Locating bugs in industry-size software systems is time consuming and challenging. An automated approach for assisting the process of tracing from bug descriptions to relevant source code benefits developers. A large body of previous work aims to address this problem and demonstrates considerable achievements. Most existing approaches focus on the key challenge of improving techniques based on textual similarity to identify relevant files. However, there exists a lexical gap between the natural language used to formulate bug reports and the formal source code and its comments. To bridge this gap, state-of-the-art approaches contain a component for analyzing bug history information to increase retrieval performance. In this paper, we propose a novel approach TraceScore that also utilizes projects' requirements information and explicit dependency trace links to further close the gap in order to relate a new bug report to defective source code files. Our evaluation on more than 13,000 bug reports shows, that TraceScore significantly outperforms two state-of-the-art methods. Further, by integrating TraceScore into an existing bug localization algorithm, we found that TraceScore significantly improves retrieval performance by 49% in terms of mean average precision (MAP).

Developing new ideas and algorithms or comparing new findings in the field of requirements engineering and management implies a dataset to work with. Collecting the required data is time consuming, tedious, and may involve unforeseen difficulties. The need for datasets often forces re-searchers to collect data themselves in order to evaluate their findings. However, comparing results with other publications is especially difficult on proprietary datasets. A big obstacle is the reproduction of a previously used dataset, which may include subtle preprocessing steps not explicitly mentioned by the original authors. Providing a predefined dataset avoids these problems. It establishes a common baseline and enables direct comparison for benchmarking. This paper provides a well defined dataset consisting of seven open source software projects. It contains a large number of typed development artifacts and links between them. Enriched with additional metadata, such as time stamps, versions, and component information, the dataset allows answering a broad range of research questions.