Vincent Blondeau, Anne Etien, N. Anquetil, Sylvain Cresson, Pascal Croisy, Stéphane Ducasse
{"title":"What are the Testing Habits of Developers? A Case Study in a Large IT Company","authors":"Vincent Blondeau, Anne Etien, N. Anquetil, Sylvain Cresson, Pascal Croisy, Stéphane Ducasse","doi":"10.1109/ICSME.2017.68","DOIUrl":"https://doi.org/10.1109/ICSME.2017.68","url":null,"abstract":"Tests are considered important to ensure the good behavior of applications and improve their quality. But development in companies also involves tight schedules, old habits, less-trained developers, or practical difficulties such as creating a test database. As a result, good testing practices are not always used as often as one might wish. With a major IT company, we are engaged in a project to understand developers testing behavior, and whether it can be improved. Some ideas are to promote testing by reducing test session length, or by running automatically tests behind the scene and send warnings to developers about the failing ones. Reports on developers testing habits in the literature focus on highly distributed open-source projects, or involve students programmers. As such they might not apply to our industrial, closed source, context. In this paper, we take inspiration from experiments of two papers of the literature to enhance our comprehension of the industrial environment. We report the results of a field study on how often the developers use tests in their daily practice, whether they make use of tests selection and why they do. Results are reinforced by interviews with developers involved in the study. The main findings are that test practice is in better shape than we expected; developers select tests \"ruthlessly\" (instead of launching an entire test suite); although they are not accurate in their selection, and; contrary to expectation, test selection is not influenced by the size of the test suite nor the duration of the tests.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"13 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127052960","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"SimEvo: Testing Evolving Multi-process Software Systems","authors":"Tingting Yu","doi":"10.1109/ICSME.2017.29","DOIUrl":"https://doi.org/10.1109/ICSME.2017.29","url":null,"abstract":"Regression testing is used to perform re-validation of evolving software. However, most existing techniques for regression testing focus exclusively on single-process applications, but to date, no work has considered regression testing for software involving multiple processes or event handlers (e.g., software signals) at the system-level. The unique characteristics of concurrency control mechanism employed at the system-level can affect the static and dynamic analysis techniques on which existing regression testing approaches rely. Therefore, applying these approaches can result in inadequately tested software during maintenance, and ultimately impair software quality. In this paper, we propose SimEvo, the first regression testing techniques for multi-process applications. SimEvo employs novel impact analysis techniques to identify system-level concurrent events that are affected by the changes. It then reuses existing test cases, as well as generating new test cases, focused on the set of impacted events, to effectively and efficiently explore the newly updated concurrent behaviors. Our empirical study on a set of real-world Linux applications shows that SimEvo is more cost-effective in achieving high inter-process coverage and revealing real world system-level concurrency faults than other approaches.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129133274","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Understanding Spreadsheet Evolution in Practice","authors":"Liang Xu","doi":"10.1109/ICSME.2017.38","DOIUrl":"https://doi.org/10.1109/ICSME.2017.38","url":null,"abstract":"As a special kind of software, spreadsheets have been evolving during their life cycle. Understanding spreadsheet evolution can help facilitate spreadsheet design, maintenance and fault detection. However, understanding spreadsheet evolution is challenging in practice. There are many factors that hinder spreadsheet evolution comprehension, such as, lack of version information, complicated structure changes during evolution, etc. Thus, we propose this work to facilitate the understanding of spreadsheet evolution, including developing semi-automated technique to build versioned spreadsheet corpora, characterizing and understanding how spreadsheet templates are reused, developing automated tools for spreadsheet comparison, and new approaches for fault detection during evolution","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"52 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125398314","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
J. Silva, I. Wiese, D. Germán, Igor Steinmacher, M. Gerosa
{"title":"How Long and How Much: What to Expect from Summer of Code Participants?","authors":"J. Silva, I. Wiese, D. Germán, Igor Steinmacher, M. Gerosa","doi":"10.1109/ICSME.2017.81","DOIUrl":"https://doi.org/10.1109/ICSME.2017.81","url":null,"abstract":"Open Source Software (OSS) communities depend on continu-ally recruiting new contributors. Some communities promote initiatives such as Summers of Code to foster contribution, but little is known about how successful these initiatives are. As a case study, we chose Google Summer of Code (GSoC), which is a three-month internship promoting software development by students in several OSS projects. We quantitatively inves-tigated different aspects of students' contribution, including number of commits, code churn, and contribution date inter-vals. We found that 82% of the studied OSS projects merged at least one commit in codebase. When only newcomers are considered, ~54% of OSS projects merged at least one com-mit. We also found that ~23% of newcomers contributed to GSoC projects before knowing they would be accepted. Addi-tionally, we found that the amount of commits and code of students with experience in the GSoC projects are strongly correlated with how much code they produced and how long they remained during and after GSoC. OSS communities can take advantage of our results to balance the trade-offs in-volved in entering CCEs, to set the communities' expectations about how much contribution they can expect to achieve, and for how long students will probably engage.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"140 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123316703","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Fiorella Zampetti, Cedric Noiseux, G. Antoniol, Foutse Khomh, M. D. Penta
{"title":"Recommending when Design Technical Debt Should be Self-Admitted","authors":"Fiorella Zampetti, Cedric Noiseux, G. Antoniol, Foutse Khomh, M. D. Penta","doi":"10.1109/ICSME.2017.44","DOIUrl":"https://doi.org/10.1109/ICSME.2017.44","url":null,"abstract":"Previous research has shown how developers \"selfadmit\" technical debt introduced in the source code, commenting why such code represents a workaround or a temporary, incomplete solution. This paper investigates the extent to which previously self-admitted technical debt can be used to provide recommendations to developers when they write new source code, suggesting them when to \"self-admit\" design technical debt, or possibly when to improve the code being written. To achieve this goal, we have developed a machine learning approach named TEDIOUS (TEchnical Debt IdentificatiOn System), which leverages various kinds of method-level features as independent variables, including source code structural metrics, readability metrics and, last but not least, warnings raised by static analysis tools. We assessed TEDIOUS on data from nine open source projects for which there are available tagged self-admitted technical debt instances, also comparing the performances of different machine learners. Results of the study indicate that TEDIOUS achieves, when recommending self-admitted technical debts within a single project, an average precision of about 50% and a recall of 52%. When predicting cross-projects, TEDIOUS improves, achieving an average precision of 67% and a recall of 55%. Last, but not least, we noticed how TEDIOUS leverages readability, size and complexity metrics, as well as some warnings raised by static analysis tools.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133116244","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Flattening Code for Metrics Measurement and Analysis","authors":"Yoshiki Higo, S. Kusumoto","doi":"10.1109/ICSME.2017.65","DOIUrl":"https://doi.org/10.1109/ICSME.2017.65","url":null,"abstract":"When we measure code metrics or analyze source code, code normalization is occasionally performed as a preprocessing. Code normalization means removing untargeted program elements, formatting source code, or transforming source code with specific rules. Code normalization makes measurement and analysis results more significant. Existing code normalization mainly targets program elements not influencing program behavior (e.g., code comments and blank lines) or program tokens (e.g., variable names and literals). In this paper, we propose a new code normalization technique targeting program structure. Our proposed technique transforms a complex program statement to simple ones. We call this transformation flattening. By flattening code, we can obtain source code including only simple program statements. As applications of the code flattening, we report how it changes LOC metric and clone detection results.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"51 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123490419","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Leonel Merino, Mohammad Ghafari, C. Anslow, Oscar Nierstrasz
{"title":"CityVR: Gameful Software Visualization","authors":"Leonel Merino, Mohammad Ghafari, C. Anslow, Oscar Nierstrasz","doi":"10.1109/ICSME.2017.70","DOIUrl":"https://doi.org/10.1109/ICSME.2017.70","url":null,"abstract":"Gamification of software engineering tasks improve developer engagement, but has been limited to mechanisms such as points and badges. We believe that a tool that provides developers an interface analogous to computer games can represent the gamification of software engineering tasks more effectively via software visualization. We introduce CityVR – an interactive software visualization tool that implements the city metaphor technique using virtual reality in an immersive 3D environment medium to boost developer engagement in software comprehension tasks. We evaluated our tool with a case study based on ArgoUML. We measured engagement in terms of feelings, interaction, and time perception. We report on how our design choices relate to developer engagement. We found that developers i) felt curious, immersed, in control, excited, and challenged, ii) spent considerable interaction time navigating and selecting elements, and iii) perceived that time passed faster than in reality, and therefore were willing to spend more time using the tool to solve software engineering tasks.https://youtu.be/R0C-HMAtgnk","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"7 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122034142","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Carmine Vassallo, Gerald Schermann, Fiorella Zampetti, Daniele Romano, P. Leitner, A. Zaidman, M. D. Penta, Sebastiano Panichella
{"title":"A Tale of CI Build Failures: An Open Source and a Financial Organization Perspective","authors":"Carmine Vassallo, Gerald Schermann, Fiorella Zampetti, Daniele Romano, P. Leitner, A. Zaidman, M. D. Penta, Sebastiano Panichella","doi":"10.1109/ICSME.2017.67","DOIUrl":"https://doi.org/10.1109/ICSME.2017.67","url":null,"abstract":"Continuous Integration (CI) and Continuous Delivery (CD) are widespread in both industrial and open-source software (OSS) projects. Recent research characterized build failures in CI and identified factors potentially correlated to them. However, most observations and findings of previous work are exclusively based on OSS projects or data from a single industrial organization. This paper provides a first attempt to compare the CI processes and occurrences of build failures in 349 Java OSS projects and 418 projects from a financial organization, ING Nederland. Through the analysis of 34,182 failing builds (26% of the total number of observed builds), we derived a taxonomy of failures that affect the observed CI processes. Using cluster analysis, we observed that in some cases OSS and ING projects share similar build failure patterns (e.g., few compilation failures as compared to frequent testing failures), while in other cases completely different patterns emerge. In short, we explain how OSS and ING CI processes exhibit commonalities, yet are substantially different in their design and in the failures they report.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"48 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126245819","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Liuqing Li, He Feng, Wenjie Zhuang, Na Meng, B. Ryder
{"title":"CCLearner: A Deep Learning-Based Clone Detection Approach","authors":"Liuqing Li, He Feng, Wenjie Zhuang, Na Meng, B. Ryder","doi":"10.1109/ICSME.2017.46","DOIUrl":"https://doi.org/10.1109/ICSME.2017.46","url":null,"abstract":"Programmers produce code clones when developing software. By copying and pasting code with or without modification, developers reuse existing code to improve programming productivity. However, code clones present challenges to software maintenance: they may require consistent application of the same or similar bug fixes or program changes to multiple code locations. To simplify the maintenance process, various tools have been proposed to automatically detect clones [1], [2], [3], [4], [5], [6]. Some tools tokenize source code, and then compare the sequence or frequency of tokens to reveal clones [1], [3], [4], [5]. Some other tools detect clones using tree-matching algorithms to compare the Abstract Syntax Trees (ASTs) of source code [2], [6]. In this paper, we present CCLEARNER, the first solely token-based clone detection approach leveraging deep learning. CCLEARNER extracts tokens from known method-level code clones and nonclones to train a classifier, and then uses the classifier to detect clones in a given codebase.To evaluate CCLEARNER, we reused BigCloneBench [7], an existing large benchmark of real clones. We used part of the benchmark for training and the other part for testing, and observed that CCLEARNER effectively detected clones. With the same data set, we conducted the first systematic comparison experiment between CCLEARNER and three popular clone detection tools. Compared with the approaches not using deep learning, CCLEARNER achieved competitive clone detection effectiveness with low time cost.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"41 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126702620","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Embroidery: Patching Vulnerable Binary Code of Fragmentized Android Devices","authors":"Xuewen Zhang, Yuanyuan Zhang, Juanru Li, Yikun Hu, Huayi Li, Dawu Gu","doi":"10.1109/ICSME.2017.15","DOIUrl":"https://doi.org/10.1109/ICSME.2017.15","url":null,"abstract":"The rapid-iteration, web-style update cycle of Android helps fix revealed security vulnerabilities for its latest version. However, such security enhancements are usually only available for few Android devices released by certain manufacturers (e.g., Google's official Nexus devices). More manufactures choose to stop providing system update service for their obsolete models, remaining millions of vulnerable Android devices in use. In this situation, a feasible solution is to leverage existing source code patches to fix outdated vulnerable devices. To implement this, we introduce Embroidery, a binary rewriting based vulnerability patching system for obsolete Android devices without requiring the manufacturer's source code against Android fragmentation. Embroidery patches the known critical framework and kernel vulnerabilities in Android using both static and dynamic binary rewriting techniques. It transplants official patches (CVE source code patches) of known vulnerabilities to different devices by adopting heuristic matching strategies to deal with the code diversity introduced by Android fragmentation, and fulfills a complex dynamic memory modification to implement kernel vulnerabilities patching. We employ Embroidery to patch sophisticated Android kernel and framework vulnerabilities for various manufactures' obsolete devices ranging from Android 4.2 to 5.1. The result shows the patched devices are able to defend against known exploits and the normal functions are not affected.","PeriodicalId":147888,"journal":{"name":"2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":"81 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127606878","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}