Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to main content
After recent improvements brought the incremental compilation of large industrial test suites down to a few seconds, the first semantic checking of a project became one of the longest-running processes. As multi-core systems are now the... more
After recent improvements brought the incremental compilation of large industrial test suites down to a few seconds, the first semantic checking of a project became one of the longest-running processes. As multi-core systems are now the standard, we derived a parallelisation using software engineering laws to improve the performance of semantic checking. Our measurements show that even an outdated laptop is fast enough for daily use. The performance improvements came without performance regressions, and we can't expect additional massive benefits even from infinitely scaling Cloud resources. Companies should utilise cheaper machines that still offer enough performance for longer. This approach can help businesses increase profits, reduce electronic waste and promote sustainability while maintaining high-quality software development practices.
This paper presents our empirical observations related to the evolution of a large automated test system. The system observed is used in the industry as a test tool for complex telecommunication systems, itself consisting of more than one... more
This paper presents our empirical observations related to the evolution of a large automated test system. The system observed is used in the industry as a test tool for complex telecommunication systems, itself consisting of more than one million lines of source code. This study evaluates how different changes during the development have changed the number of observed Code Smells in the test system. We have monitored the development of the test scripts and measured the code quality characteristics over a five years period. The observations show that the introduction of continuous integration, the existence of tool support for quality improvements in itself, changing the development methodologies (from waterfall to agile), changing technical and line management structure and personnel caused no measurable change in the trends of the observed Code Smells. Internal quality improvements were achieved mainly by individuals intrinsic motivation. Our measurements show similarities with ear...
Context Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of... more
Context Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus. Results We estimate that between 17% and 32% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66% to 87%. We find that about 11% of lines are hard to label leading to active disagreements between participants...
Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of... more
Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective: We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods: We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each line is labeled by four participants. If at least three participants agree on the same label, we have consensus. Results: We estimate that between 17\% and 32\% of all changes in bug fixing commits modify the source code to fix the underlying problem. However, when we only consider changes to the production code files this ratio increases to 66\% to 87\%. We find that about 11\% of lines are hard to label leading to active disagreements between par...
This paper is based on research results achieved by a collaboration between Ericsson Hungary Ltd. and the Large Scale Testing Research Lab of Eötvös Loránd University, Budapest. We present design issues and empirical observations on... more
This paper is based on research results achieved by a collaboration between Ericsson Hungary Ltd. and the Large Scale Testing Research Lab of Eötvös Loránd University, Budapest. We present design issues and empirical observations on extending an existing industrial toolset with a new intermediate language1. Context: The industry partner’s toolset is using C/C++ as an intermediate language, providing good execution performance, but “somewhat long” build times, o ering a sub-optimal experience for users. Objective: In cooperation with our industry partner our task was to perform an experiment with Java as a different intermediate language and evaluate results, to see if this could improve build times. Method: We extended the mentioned toolset to use Java as an intermediate language. Results: Our measurements show that using Java as an intermediate language improves build times significantly. We also found that, while the runtime performance of C/C++ is better in some situations, Java,...
To help the work of TTCN-3 test system architects we created a tool that is able to visualize large test systems, fitting to daily work practices. We defined and implemented 2 layouts, clustering and interaction methods. We also show 2... more
To help the work of TTCN-3 test system architects we created a tool that is able to visualize large test systems, fitting to daily work practices. We defined and implemented 2 layouts, clustering and interaction methods. We also show 2 structuring methods, that are not yet supported by the TTCN-3 standard. With this tool we have analyzed all standardized test suites available at www.ttcn3.org, finding circular dependency and unnecessary source files in almost every test suite.
In this article we present methods and algorithms for constructing an efficient IDE in the sense that the processing costs of re-analyzing source code after change is minimal. Moreover, we show that these methods and algorithms can be... more
In this article we present methods and algorithms for constructing an efficient IDE in the sense that the processing costs of re-analyzing source code after change is minimal. Moreover, we show that these methods and algorithms can be designed in a way that they support iterative realization, hence, they fit better to the current trends of iterative software development life-cycle. We also show how these algorithms can be built into an existing system and we show measurements on performance benefits. The proposed methods were validated in the telecommunication area for compiling TTCN-3 code.
Research Interests:
Creating software products is a complex endeavor requiring the cooperation of people with different skills/knowledge/thinking. Managers, developers, testers and technical writers have to work together to create and deliver software... more
Creating software products is a complex endeavor requiring the cooperation of people with different skills/knowledge/thinking. Managers, developers, testers and technical writers have to work together to create and deliver software products. These roles might have different views, perceptions, knowledge even in the same project. In order to understand their commonalities, differences and the evolution of their skills we run a survey that was filled in by 456 professionals working in software development projects. We have found among others that (1) Internet is one of the most useful source of information for professionals; (2) trial and error is perceived to be more efficient then formal training; (3) testing skills are among the most important ones; (4) there are little differences in people’s way of thinking compared by roles, by size of employing company or by experience levels; (5) at the same time, larger companies seem to be more efficient and their experts are better at monit...
Context It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering. Objective The goal of this study is to investigate the... more
Context It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering. Objective The goal of this study is to investigate the scientific publications presented at the premier technical debt conferences by understanding how reproducible the reported findings are. Method We conducted a systematic literature review of 135 unique papers published at the “International Workshop on Managing Technical Debt” and the “International Conference on Managing Technical Debt”, the premier scientific conference series on technical debt. Results Only 44 of the investigated 135 papers presented numerical evidence and only 5 papers listed the tools, the availability of the tools, and the version of the tools used. For the rest of the papers additional information would have been needed for the potential reproducibility. One of the published papers even referred to a pornographic site as a source of ...
Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of... more
Context: Tangled commits are changes to software that address multiple concerns at once. For researchers interested in bugs, tangled commits mean that they actually study not only bugs, but also other concerns irrelevant for the study of bugs. Objective: We want to improve our understanding of the prevalence of tangling and the types of changes that are tangled within bug fixing commits. Methods: We use a crowd sourcing approach for manual labeling to validate which changes contribute to bug fixes for each line in bug fixing commits. Each Austin Z. Henley University of Tennessee, Knoxville, USA E-mail: azh@utk.edu Stratos Kourtzanidis University of Macedonia, Thessaloniki, Greece E-mail: ekourtzanidis@uom.edu.gr Eray Tüzün Department of Computer Engineering, Bilkent University, Ankara, Turkey E-mail: eraytuzun@cs.bilkent.edu.tr Christoph Treude University of Melbourne, Melbourne, Australia E-mail: christoph.treude@unimelb.edu.au Simin Maleki Shamasbi Independent Researcher, Tehran, ...
Context: It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering. Objective: The goal of this study is to investigate the... more
Context: It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering.
Objective: The goal of this study is to investigate the scientific publications presented at the premier technical debt conferences by understanding how reproducible the reported findings are.
Method: We conducted a systematic literature review of 135 unique papers published at the "International Workshop on Managing Technical Debt" and the "International Conference on Managing Technical Debt", the premier scientific conference series on technical debt.
Results: Only 44 of the investigated 135 papers presented numerical evidence and only 5 papers listed the tools, the availability of the tools, and the version of the tools used. For the rest of the papers additional information would have been needed for the potential reproducibility. One of the published papers even referred to a pornographic site as a source of a toolset for empirical research.
This paper is based on research results achieved by a collaboration between Ericsson Hungary Ltd. and the Large Scale Testing Research Lab of Eötvös Loránd University, Budapest. We present design issues and empirical observations on... more
This paper is based on research results achieved by a collaboration between Ericsson Hungary Ltd. and the Large Scale Testing Research Lab of Eötvös Loránd University, Budapest. We present design issues and empirical observations on extending an existing industrial toolset with a new intermediate language.
Context: The industry partner’s toolset is using C/C++ as an inter-mediate language, providing good execution performance, but “somewhat long” build times, offering a sub-optimal experience for users.
Objective: In cooperation with our industry partner our task was to perform  an  experiment  with  Java  as  a  different  intermediate  language and evaluate results, to see if this could improve build times.
Method: We extended the mentioned toolset to use Java as an inter-mediate language.
Results: Our measurements show that using Java as an intermediate language  improves  build  times  significantly.  We  also  found  that,  while the runtime performance of C/C++ is better in some situations, Java, at least in our testing scenarios, can be a viable alternative to improve developer productivity.
Our contribution is unique in the sense that both ways of building and execution can use the same source code as input, written in the same language, generate intermediate codes with the same high-level structure, compile into executables that are configured using the same files, run on the same machine, show the same behaviour and generate the same logs.
Conclusions: We created an alternative build pipeline that might enhance the productivity of our industry partner’s test developers by reducing the length of builds during their daily work.
Creating software products is a complex endeavor requiring the cooperation of people with different skills/knowledge/thinking. Managers, developers, testers and technical writers have to work together to create and deliver software... more
Creating software products is a complex endeavor requiring the cooperation of people with different skills/knowledge/thinking. Managers, developers, testers and technical writers have to work together to create and deliver software products. These roles might have different views, perceptions, knowledge even in the same project. In order to understand their commonalities, differences and the evolution of their skills we run a survey that was filled in by 456 professionals working in software development projects. We have found among others that (1) Internet is one of the most useful source of information for professionals; (2) trial and error is perceived to be more efficient then formal training; (3) testing skills are among the most important ones; (4) there are little differences in people's way of thinking compared by roles, by size of employing company or by experience levels; (5) at the same time, larger companies seem to be more efficient and their experts are better at monitoring and testing new technologies/methods; (6) interestingly, although most companies support the improvement of internal quality, most respondents have very limited knowledge or are not concerned of anti-patterns.
Research Interests:
To help the work of TTCN-3 test system architects we created a tool that is able to visualize large test systems, fitting to daily work practices. We defined and implemented 2 layouts, clustering and interaction methods. We also show 2... more
To help the work of TTCN-3 test system architects we created a tool that is able to visualize large test systems, fitting to daily work practices. We defined and implemented 2 layouts, clustering and interaction methods. We also show 2 structuring methods, that are not yet supported by the TTCN-3 standard. With this tool we have analyzed all standardized test suites available at www.ttcn3.org, finding circular dependency and unnecessary source files in almost every test suite.
Research Interests:
This is the data belonging to our publication "Advanced TTCN-3 Test Suite validation with Titan".
Research Interests:
Research Interests:
Recently, technical debt investigations became more and more important in the software development industry. In this paper we show that the same challenges are valid for the automated test systems. We present an internal quality analysis... more
Recently, technical debt investigations became more and more important in the software development industry. In this paper we show that the same challenges are valid for the automated test systems. We present an internal quality analysis of standardized test software developed by ETSI and 3GPP, performed on the systems publicly available at www.ttcn-3.org
Research Interests:
In this article we present methods and algorithms for constructing an efficient IDE in the sense that the processing costs of re-analyzing source code after change is minimal. Moreover, we show that these methods and algorithms can be... more
In this article we present methods and algorithms for constructing an efficient IDE in the sense that the processing costs of re-analyzing source code after change is minimal. Moreover, we show that these methods and algorithms can be designed in a way that they support iterative realization, hence, they fit better to the current trends of iterative software development life-cycle. We also show how these algorithms can be built into an existing system and we show measurements on performance benefits. The proposed methods were validated in the telecommunication area for compiling TTCN-3 code.
Research Interests:
As the size and complexity of large software systems continuously grow, so do their test systems. In today's telecommunication world, we have test systems which are comparable in complexity to that of the tested systems. Some of these... more
As the size and complexity of large software systems continuously grow, so do their test systems. In today's telecommunication world, we have test systems which are comparable in complexity to that of the tested systems. Some of these test systems have to simulate millions of users, be as robust as the tested systems themselves and provide comparable performance. To be able to handle such testing needs, ETSI developed the TTCN-3 programming language. TTCN-3 has proved to be very efficient for developing test systems for communication systems. In this article we present the results of analyzing the test software systems publicly available from www.ttcn-3.org. We show the issues that we have found on semantic level and on advanced code smell level. We also present some results on the test systems structural level.
Research Interests:
Experience has shown that the Testing and Test Control Notation version 3 (TTCN-3) language provides very good concepts for adequate test specification, but it was not presented yet how large test systems written in TTCN-3 are structured.... more
Experience has shown that the Testing and Test Control Notation version 3 (TTCN-3) language provides very good concepts for adequate test specification, but it was not presented yet how large test systems written in TTCN-3 are structured. This paper presents my efforts to analyze the structure of TTCN-3 projects, to see if such problems manifest, and if possible to provide methods that can detect these problems.