Software Product Line Engineering (SPLE) is a recognized methodology for systematically developing reusable software components and tailored software products for specific market segments. A critical activity within domain engineering is SPL Scoping, aimed at profiling the SPL boundaries and fitting this market segment. Yet, this market is a moving target, which requires SPLs to be proactive in anticipating and addressing future challenges and opportunities. In this setting, rather than all the possible products potentially derived from the SPL’s Feature Model (i.e., the potential portfolio), the subset of products actually deployed is a better indicator of market adoption and customer preferences, and ultimately, of the SPL’s fitness to the market. This study characterizes the phenomenon of ‘deployed portfolio evolution’ in terms of the size and frequency of portfolio changes. We then elaborate on the advantages of utilizing this data source and the necessity for dedicated tools for Portfolio Evolution Analysis integrated within variability managers. To achieve this, we introduce the functional requirements, implementation, and architecture of PortfolioScan , a dashboard for Portfolio Evolution Analysis built on top of pure::variants . The dashboard enables the evaluation of feature usage through time-series charts such as temporal heat maps, line charts, and also a scoping-criteria comparison matrix. Evaluation results (n=13) indicate a positive perception. Practitioners also recognize the benefits of Portfolio Evolution Analysis for Testing Resource Optimization and Configuration Assistance. The ultimate goal of the study is to establish a basis for more responsive and market-oriented decision-making in SPL tasks. • Deployed products in SPLs reflect market adoption and customer preferences. • Characterization of deployed portfolio evolution with real practitioners’ feedback. • PortfolioScan dashboard introduced for Portfolio Evolution Analysis in SPLs. • Time-series charts use for supporting feature usage evaluation.

Implicit feedback involves gathering information about software usage to grasp how and when the software is utilized. This study investigates the integration of implicit feedback mechanisms into Software Product Line Engineering (SPLE). While common in product-based development for identifying bugs, usability issues, and informing requirement prioritization, its adoption in SPLs has been limited due to the unique challenges posed by SPLE, such as the emphasis on Domain Engineering over Application Engineering, and the need for systematic reuse of shared assets. We propose a novel approach to incorporate feedback practices into Domain Engineering, thereby shifting the focus from individual product variants to the SPL platform, and specifically moving from product-based feedback to feature-based feedback. Based on a case study, we suggest that product derivation includes a second step that injects the trackers at the time of derivation, using a Feedback Model that complements the Configuration Model for feedback analysis.To test this approach, we introduce FEACKER, an extension to pure::variants as the variability manager. FEACKER injects trackers when the product variant is derived. The findings are validated through a Technology Acceptance Model (TAM) evaluation and a focus group discussion, providing insights into the feasibility, acceptance, and potential impact of platform-based feedback in SPLE. The results indicate agreement on the benefits of conducting feedback analysis at the platform level and the perception that FEACKER seamlessly extends the capabilities of pure::variants.

Summary Mutation testing is an approach to assess the quality of test cases. Mutants are modified versions of a system that ideally compose faulty behaviour. Test cases for a system are effective if they kill these mutants. For software product lines, several works have addressed mutation testing to inject variability faults, which may only exist in some variants. These works focus on variability models or specific implementation techniques. In contrast, feature‐oriented programming has been rarely investigated, wherefore, we (1) derive corresponding mutation operators, (2) investigate the feasibility of our proposed and conventional operators on 4 software product lines, and (3) discuss open challenges in mutation testing of software product lines. The results show that our proposed operators are suitable to cause variability faults and extend the capabilities of conventional operators. Nonetheless, mutation testing of software product lines is comparably expensive, due to a high number of variants and mutants—resulting in equivalence and redundancy.

Many existing approaches have exploited the similarity notion to analyze software systems. In product-line engineering, similarity notion has been considered to fulfill analysis objectives, such as improving the testing effectiveness and reducing the testing efforts. However, most of the existing approaches consider in the similarity measurement only information of high level of abstraction, such as the feature selections of variants. In this paper, we present the notion of similarity in product-line engineering using different types of problem-space as well as solution-space information. In particular, we discuss different scenarios of measuring the similarity between variants and the possibility of combining different types of information to output the similarity between the compared variants. Moreover, we realized these scenarios in the industrial variant management tool pure::variants to fulfill analysis functionalities.

In this paper, we give abrief overview on the tutorial "Using Feature Models to Manage Variability and Requirements Reuse".

In practice, organizations often rely on the clone-and-own approach to reuse and customize existing systems. While increasing maintenance costs encourage some organizations to adopt their development processes towards more systematic reuse, others still avoid migrating to a reusable platform. Based on our experiences, a barrier preventing the adoption of software product lines is the fear of introducing new and more problematic bugs---during the migration or later on. We are aware of several works that automate software-product-line adoption, but they neglect the migration and maintenance of test cases. Automating the refactoring of tests can help to facilitate the adoption barrier, compare the quality after migrations, and support maintenance. In this vision paper, we i) discuss open research challenges that are based on our experiences and ii) sketch a first framework to develop automated solutions. Overall, we aim to illustrate our idea and initiate further research to facilitate the adoption and maintenance of software product lines.

The analysis of software product lines is challenging due to the potentially large number of products, which grow exponentially in terms of the number of features. Product sampling is a technique used to avoid exhaustive testing, which is often infeasible. In this paper, we propose a classification for product sampling techniques and classify the existing literature accordingly. We distinguish the important characteristics of such approaches based on the information used for sampling, the kind of algorithm, and the achieved coverage criteria. Furthermore, we give an overview on existing tools and evaluations of product sampling techniques. We share our insights on the state-of-the-art of product sampling and discuss potential future work.

A software product line comprises a family of software products that share a common set of features. It enables customers to compose software systems from a managed set of features. Testing every product of a product line individually is often infeasible due to the exponential number of possible products in the number of features. Several approaches have been proposed to restrict the number of products to be tested by sampling a subset of products achieving sufficient combinatorial interaction coverage. However, existing sampling algorithms do not scale well to large product lines, as they require a considerable amount of time to generate the samples. Moreover, samples are not available until a sampling algorithm completely terminates. As testing time is usually limited, we propose an incremental approach of product sampling for pairwise interaction testing (called IncLing), which enables developers to generate samples on demand in a step-wise manner. Furthermore, IncLing uses heuristics to efficiently achieve pairwise interaction coverage with a reasonable number of products. We evaluated IncLing by comparing it against existing sampling algorithms using feature models of different sizes. The results of our approach indicate efficiency improvements for product-line testing.

Most software systems are designed to provide custom functionality using configuration options. Testing such systems is challenging as running tests of a single configuration is often not sufficient, because defects may appear in other configurations. Ideally, all configurations of a software system should be tested, which is usually not applicable in practice due to the combinatorial explosion with respect to the configuration options. Multiple sampling strategies aim to reduce the set of tested configurations to a feasible amount, such as T-wise sampling, random configurations, and user-defined configurations. However, these strategies are often not applied in practice as they require manual effort or a specialized testing framework. Within our tool FeatureIDE, we integrate all aforementioned strategies and reduce the manual effort by automating the process of generating and testing configurations. Furthermore, we provide support for unit testing to avoid redundant test executions and for variability-aware testing. With this extension of FeatureIDE, we aim to make recent testing techniques for configurable systems applicable in practice.

Exhaustively testing every product of a software product line (SPL) is a difficult task due to the combinatorial explosion of the number of products. Combinatorial interaction testing is a technique to reduce the number of products under test. However, it is typically up-to the tester in which order these products are tested. We propose a similarity-based prioritization to be applied on these products before they are generated. The proposed approach does not guarantee to find more errors than sampling approaches, but it aims at increasing interaction coverage of an SPL under test as fast as possible over time. This is especially beneficial since usually the time budget for testing is limited. We implemented similarity-based prioritization in FeatureIDE and evaluated it by comparing its outcome to the default outcome of three sampling algorithms as well as to random orders. The experiment results indicate that the order with similarity-based prioritization is better than random orders and often better than the default order of existing sampling algorithms.