Search

Android applications do not seem to be tested as thoroughly as desktop ones. In particular, graphical user interface (GUI) testing appears generally limited. Like web-based applications, mobile apps suffer from GUI test fragility, i.e., GUI test classes failing or needing updates due to even minor modifications in the GUI or in the application under test. The objective of our study is to estimate the adoption of GUI testing frameworks among Android open-source applications, the quantity of modifications needed to keep test classes up to date, and their amount due to GUI test fragility. We introduce a set of 21 metrics to measure the adoption of testing tools and the evolution of test classes and test methods, and to estimate the fragility of test suites. We computed our metrics for six GUI testing frameworks, none of which achieved a significant adoption among Android projects hosted on GitHub. When present, GUI test methods associated with the considered tools are modified often, and a relevant portion (70% on average) of those modifications is induced by GUI-related fragilities. On average, for the projects considered, more than 7% of the total modified lines of code between consecutive releases belong to test classes developed with the analyzed testing frameworks. The measured percentage was higher on average than the one required by other generic test code, based on the JUnit testing framework. Fragility of GUI tests constitutes a relevant concern, probably an obstacle for developers to adopt test automation. This first evaluation of the fragility of Android scripted GUI testing can constitute a benchmark for developers and testers leveraging the analyzed test tools and the basis for the definition of a taxonomy of fragility causes and guidelines to mitigate the issue. [ABSTRACT FROM AUTHOR]

A proposed method evaluates eight popular software reliability growth models and selects the one that can best predict the software's remaining faults, providing practical support for project managers who are considering an open source component. [ABSTRACT FROM PUBLISHER]

Most studies and regulatory controls focus on hardware-related measurement, analysis, and control for energy consumption. However, all forms of hardware include significant software components. Although software systems don't consume energy directly, they affect hardware utilization, leading to indirect energy consumption. Therefore, it's important to engineer software to optimize its energy consumption. The software engineering research domain has recently been paying attention to sustainability, as the increased number of publications, empirical studies, and conferences on the topic demonstrate. The guest editors of this special issue explain the articles they selected to highlight this important research area. The Web extra at http://youtu.be/h0tQoOH9_aM is an audio interview in which IEEE Software multimedia editor Davide Falessi interviews guest editor Ayse Basar Bener about how green software can help minimize the negative effects of software products and their development. [ABSTRACT FROM PUBLISHER]

Practitioners generally view exploratory testing (ET) as a cost-effective substitute for their daily testing activities. However, empirical evidence reported in the literature gives a more comprehensive picture of ET that considers its technical debt implications. [ABSTRACT FROM AUTHOR]

The article presents ten facts regarding the selection and integration of commercial off-the-shelf (COTS) and open source software components in the development of software systems as practiced by industries. Facts mentioned include the traditional practice of using off-the-shelf (OTS) specific activities for integrating OTS components by integrators, the absence of formal selection procedures among integrators of OTS components and the lack of a specific development process phase which integrators may use in selecting OTS components.

An international survey on risk management in software development with Off-the-Shelf (OTS) components is reported upon and discussed. The survey investigated actual risk-management activities and their correlations with the occurrences of typical risks in OTS component-based development. Data from 133 software projects in Norway, Italy, and Germany were collected using a stratified random sample of IT companies. The results show that OTS components normally do not contribute negatively to the quality of the software system as a whole, as is commonly expected. However, issues such as the underestimation of integration effort and inefficient debugging remain problematic and require further investigation. The results also illustrate several promising effective risk-reduction activities, e.g., putting more effort into learning relevant OTS components, integrating unfamiliar components first, thoroughly evaluating the quality of candidate OTS components, and regularly monitoring the support capability of OTS providers. Five hypotheses are proposed regarding these risk-reduction activities. The results also indicate that several other factors, such as project, cultural, and human-social factors, have to be investigated to thoroughly deal with the possible risks of OTS-based projects. [ABSTRACT FROM AUTHOR]

Test-Driven Development (TDD) is based on formalizing a piece of functionality as a test, implementing the functionality such that the test passes, and iterating the process. This paper describes a controlled experiment for evaluating an important aspect of TDD: In TDD, programmers write functional tests before the corresponding implementation code. The experiment was conducted with undergraduate students. While the experiment group applied a test-first strategy, the control group applied a more conventional development technique, writing tests after the implementation. Both groups followed an incremental process, adding new features one at a time and regression testing them. We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed. [ABSTRACT FROM AUTHOR]

This article presents interview results which contradict widely accepted or simply undisputed ideas over "commercial-off-the shelf (COTS) product." The article also presents a definition of COTS product that captures the key features. The sample of projects this article used is limited and can't represent the whole IT industry. Instead, this study primarily considers Small-Medium Enterprises (SMEs). While SMEs produce most software, they're usually neglected by research. Specifically, the COTS-development literature seems to focus on large, mostly governmental projects performed in major companies. The goal is to empirically explore this key topic for the software industry, collect facts, and derive well-substantiated theses from these facts.

This paper presents an empirical study in an industrial context on the production of software using a framework. Frameworks are semicomplete applications, usually implemented as a hierarchy of classes. The framework is developed first, then several applications are derived from it. Frameworks are a reuse technique that supports the engineering of product lines. In the study, we compare quality (in the sense of rework effort) and productivity in traditional and framework-based software production. We observe that the latter is characterized by better productivity and quality, as well as a massive increase in productivity over time, that we attribute to the effect of learning the framework. Although we cannot extrapolate the results outside the local environment, enough evidence has been accumulated to stimulate future research work. [ABSTRACT FROM AUTHOR]

This paper aims at identifying some of the key factors in adopting or running a company-wide software reuse program. Key factors are derived from empirical evidence of reuse practices, as emerged from a survey of projects for the introduction of reuse in European companies: 24 such projects performed from 1994 to 1997 were analyzed using structured interviews. The projects were undertaken in both large and small companies, working in a variety of business domains, and using both object-oriented and procedural development approaches. Most of them produce software with high commonality between applications, and have at least reasonably mature processes. Despite that apparent potential for success, around one-third of the projects failed. Three main causes of failure were not introducing reuse-specific processes, not modifying nonreuse processes, and not considering human factors. The root cause was a lack of commitment by top management, or nonawareness of the importance of those factors, often coupled with the belief that using the object-oriented approach or setting up a repository seamlessly is all that is necessary to achieve success in reuse. Conversely, successes were achieved when, given a potential for reuse because of commonality among applications, management committed to introducing reuse processes, modifying nonreuse processes, and addressing human factors. While addressing those three issues turned out to be essential, the lower-level details of how to address them varied greatly: for instance, companies produced large-grained or small-grained reusable assets, did or did not perform domain analysis, did or did not use dedicated reuse groups, used specific tools for the repository or no tools. As far as these choices are concerned, the key point seems to be the sustainability of the approach and its suitability to the context of the company. [ABSTRACT FROM AUTHOR]

Deals with the application of the Personal Software Process (PSP), which aims to improve the performance of individual software developers, in an industrial environment. Basis of the PSP; Independent personal processes; Tool support and privacy of data; Quality management. INSET: Related Work.

Examines the impact of process diversity in software reuse. Conditions to be satisfied in implementing software reuse; Case histories of several European companies; Responsibilities of a company-level reuse groups. INSET: Research Method: Reuse Case Studies.

In recent years, the wireless Internet has become reality. Access is wireless through personal, local or global networks. Several applications are being and will be developed, either to adapt existing ones to the new infrastructure, or to support several mobile services. This article deals with engineering challenges at the application level. It presents the concept of context awareness and adaptation or the capability of an application to adapt to different terminals or to a changing geographical position. This theme is based on two research topics--namely, middleware for mobility and adaptation of the application to the terminal. Traditional middleware supports the communication among applications or components resident on a node. With mobility of terminals and components from node to node, new problems arise which extends middleware with new functions. The latter poses a hard problem because it is strictly linked with the semantics of the application. Effective adaptation requires working at the semantic level.

This article presents information related to comments on "More Success and Failure Factors in Software Reuse." The first and main observation of the data set is based not only on the data set itself but also on the knowledge gathered during the interviews with project members. The main problem with the data set is its size: 23 data points. Although this data set is the largest one available about reuse projects, it is too limited to base analysis only on data mining techniques; data mining is usually applied to data sets with thousands if not millions of data points.