Managing Software Testing Technical Debt Using Evolutionary Algorithms

Technical Debt is a term coined by Ward Cunningham to denote the amount of rework required to put a piece of software into that state which it should have had from the beginning. The term outdates the agile revolution. Technical debt can occur using any development approach, but since agile development has become wide spread the notion of “technical debt” has gained much more attention. That is because if agile development is not done properly, technical debt accrues very fast and threatens to strangle the project. In this paper the author describes how technical debt comes to being, how it can be measured and what can be done to prevent it in agile development. The emphasis of the paper is on how to prevent it. What measures are necessary in an agile development project to keep technical debt from accruing over time? The paper lists out a number of measures which can be taken – organizational, procedural and technical. Automated tools play an important role in the struggle against technical debt. Samples are given how a tool can be helpful in identifying and removing problems before they get out of hand. Also important is an external auditing agency which monitors projects in progress with the aide of automated tools. In the end a case study is presented which illustrates the monitoring of technical debt within an agile development and what counter measures are required to stop it.KeywordsTechnical debtcode qualityproduct documentationsoftware defectsrefactoringsoftware metricsagile team organizationagile testing

In the fast-paced and highly competitive landscape of retail, the management of technical debt has become a critical challenge for organizations striving to maintain robust and scalable technology systems. Technical debt, the accumulated cost of prioritizing quick fixes or suboptimal solutions over more sustainable and efficient options, can significantly hinder an organization's ability to innovate, adapt, and grow. This paper explores the role of strategic leadership in effectively reducing technical debt within retail technology systems. By examining key leadership strategies, such as fostering a culture of continuous improvement, investing in long-term technology planning, and emphasizing cross-functional collaboration, the paper highlights how retail organizations can systematically address and mitigate technical debt. Strategic leadership in the retail sector involves a comprehensive understanding of both business and technological imperatives. Leaders must recognize the implications of technical debt not only in terms of immediate financial costs but also in the broader context of business agility, customer experience, and competitive advantage. The paper emphasizes the need for leaders to adopt a proactive approach, prioritizing technical debt reduction as a strategic objective that aligns with the organization's overall goals. One of the central arguments of the paper is that effective technical debt management requires a shift from reactive to proactive leadership. This involves anticipating potential issues, encouraging innovation, and making informed decisions that balance short-term gains with long-term sustainability. The paper discusses various leadership practices that contribute to this shift, including the implementation of robust governance frameworks, the adoption of agile methodologies, and the promotion of a learning-oriented organizational culture.

Technical debt is the consequence of trade-offs made during software development to ensure speedy releases. The research community lacks rigorously evaluated guidelines to help practitioners characterize, manage and prioritize debt. This paper describes a study conducted with an industrial partner during their implementation of Agile development practices for a large software development division within the company. The report contains our initial findings based on ethnographic observations and semi-structured interviews. The goal is to identify the best practices regarding managing technical debt so that the researchers and the practitioners can further evaluate these practices to extend their knowledge of the technical debt metaphor. We determined that the developers considered their own taxonomy of technical debt based on the type of work they were assigned and their personal understanding of the term. Despite management's high-level categories, the developers mostly considered design debt, testing debt and defect debt. In addition to developers having their own taxonomy, assigning dedicated teams for technical debt reduction and allowing other teams about 20% of time per sprint for debt reduction are good initiatives towards lowering technical debt. While technical debt has become a well-regarded concept in the Agile community, further empirical evaluation is needed to assess how to properly apply the concept for various development organizations.

IBED: Combining IBEA and DE for optimal feature selection in software product line engineering

The practical implications of technical debt for the entire software life cycle; with examples and case studies. Technical debt in software is incurred when developers take shortcuts and make ill-advised technical decisions in the initial phases of a project, only to be confronted with the need for costly and labor-intensive workarounds later. This book offers advice on how to avoid technical debt, how to locate its sources, and how to remove it. It focuses on the practical implications of technical debt for the entire software lifecycle, with examples and case studies from companies that range from Boeing to Twitter. Technical debt is normal; it is part of most iterative development processes. But if debt is ignored, over time it may become unmanageably complex, requiring developers to spend all of their effort fixing bugs, with no time to add new features—and after all, new features are what customers really value. The authors explain how to monitor technical det, how to measure it, and how and when to pay it down. Broadening the conventional definition of technical debt, they cover requirements debt, implementation debt, testing debt, architecture debt, documentation debt, deployment debt, and social debt. They intersperse technical discussions with “Voice of the Practitioner” sidebars that detail real-world experiences with a variety of technical debt issues.

Software Architectural Smells (SA smells) are design problems in the internal structure and behavior of an SA. These can be seen as a specific category under the umbrella concept of Technical Debt (TD). TD is a central concept in software development projects and having the means to detect and measure the smells is important to understand impairments they may cause. However, TD is only limited to the technical aspects and does not describe smells found on an enterprise level. Enterprise Architecture Debt (EAD) expands the concepts of TD beyond the technical aspects such that it covers the debts that can be found in all layers of an Enterprise Architecture (EA). EA smells give a measurement for EAD, by providing means for detecting the smell, hence enabling a method to quantify the level of debt. The goal of this paper is to find EA smells derived from existing SA smells. This has resulted in three new EA smells that could be used as measurements for the quality of an EA. They can also be used in the future as a basis for automatic EA smell detection.

Agile teams measure their velocity for performance, based on Story Points. However, such velocity does not allow predicting when the product will be finished. Story points measure effort only. They do not discriminate between creating functionality and other tasks. Non-functional requirements, such as agreeing with stakeholders, designing, testing, or documenting, consume effort but do not add functionality. Thus, it remains unclear whether the product makes any progress, or the team is just looping around technical debt and unclear requirements. Euro Project Office has therefore developed a method how to complement a product backlog by functional size, indicating progress and completeness in unambiguous terms. The method is based on the international standard ISO/IEC 14143 [1] and ISO/IEC 19761 [2]. Tools are available as open source and can be used by development teams with minimum investment into training.

Towards Software Product Lines Optimization Using Evolutionary Algorithms

The design of Renewable Energy Power Plants (REPPs) is crucial not only for the investments' performance and attractiveness measures, but also for the maximization of resource (source) usage (e.g. sun, water, and wind) and the minimization of raw materials (e.g. aluminum: Al, cadmium: Cd, iron: Fe, silicon: Si, and tellurium: Te) consumption. Hence, several appropriate and satisfactory Multi-Objective Problems (MOPs) are mandatory during the REPPs' design phases. MOPs related tasks can only be managed by very well organized knowledge acquisition on all REPPs' design equations and models. The proposed MOPs need to be solved with one or more multi-objective algorithm, such as Multi-Objective Evolutionary Algorithms (MOEAs). In this respect, the first aim of this research study is to start gathering knowledge on the REPPs' MOPs. The second aim of this study is to gather detailed information about all MOEAs and available free software tools for their development. The main contribution of this research is the initialization of a proposed multi-objective evolutionary algorithm knowledge acquisition system for renewable energy power plants (MOEAs-KAS-F-REPPs) (research and development loopwise process: develop, train, validate, improve, test, improve, operate, and improve). As a simple representative example of this knowledge acquisition system research with two selective and elective proposed standard objectives (as test objectives) and eight selective and elective proposed standard constraints (as test constraints) are generated and applied as a standardized MOP for a virtual small hydropower plant design and investment. The maximization of energy generation (MWh) and the minimization of initial investment cost (million €) are achieved by the Multi-Objective Genetic Algorithm (MOGA), the Niched Sharing Genetic Algorithm/Non-dominated Sorting Genetic Algorithm (NSGA-I), and the NSGA-II algorithms in the Scilab 6.0.0 as only three standardized MOEAs amongst all proposed standardized MOEAs on two desktop computer configurations (Windows 10 Home 1709 64 bits, Intel i5-7200 CPU @ 2.7 GHz, 8.00 GB RAM with internet connection and Windows 10 Pro, Intel(R) Core(TM) i5 CPU 650 @ 3.20 GHz, 6,00 GB RAM with internet connection). The algorithm run-times (computation time) of the current applications vary between 20.64 and 59.98 seconds.

A multi-objective particle swarm optimization (MOPSO) approach for multi-objective economic load dispatch problem in power system is presented in this paper. The economic load dispatch problem is a non-linear constrained multi-objective optimization problem. The proposed MOPSO approach handles the problem as a multi-objective problem with competing and non-commensurable fuel cost, emission and system loss objectives and has a diversity-preserving mechanism using an external memory (call “repository”) and a geographically-based approach to find widely different Pareto-optimal solutions. In addition, fuzzy set theory is employed to extract the best compromise solution. Several optimization runs of the proposed MOPSO approach were carried out on the standard IEEE 30-bus test system. The results revealed the capabilities of the proposed MOPSO approach to generate well-distributed Pareto-optimal non-dominated solutions of multi-objective economic load dispatch. Comparison with Multi-objective Evolutionary Algorithm (MOEA) showed the superiority of the proposed MOPSO approach and confirmed its potential for solving multi-objective economic load dispatch.

Multiobjective optimization: When objectives exhibit non-uniform latencies

[Context] In agile software development, requirements are frequently represented in lightweight artifacts such as user stories (USs). To support their validation, USs may be complemented with additional artifacts such as acceptance criteria and test cases. [Problem] Existing studies propose frameworks for US writing, or investigate high-level factors that contribute to productivity, such as teamwork and support from management. However, empirical evidence on the impact of requirements artifacts on team efficiency is scarce. [Method] Through a mixed-methods case study at a large Dutch organization, we investigate how the use of requirements artifacts affects efficiency. We collected data from eight agile teams: 1,345 USs from nineteen sprints, US quality indicators, the quantity of associated acceptance criteria and test cases, and cycle time. We statistically analyzed the existence of correlations between these variables, and we triangulated our results through interviews with product owners and scrum masters from the involved teams. [Findings] Our employed indicators for US quality do not seem to have an effect on on-time completion, with our interviewees highlighting the trade-off between investing on writing quality and short-term efficiency. We found, instead, that the existence of acceptance criteria may be a relevant factor for on-time completion, as confirmed both by statistical tests and the interviewees.

As information technology becomes integral to the products and services in a growing range of industries, there has been a corresponding surge of interest in understanding how firms can effectively formulate and execute digital business strategies. This fusion of IT within the business environment gives rise to a strategic tension between investing in digital artifacts for long-term value creation and exploiting them for short-term value appropriation. Further, relentless innovation and competitive pressures dictate that firms continually adapt these artifacts to changing market and technological conditions, but sustained profitability requires scalable architectures that can serve a large customer base and stable interfaces that support integration across a diverse ecosystem of complementary offerings. The study of digital business strategy needs new concepts and methods to examine how these forces are managed in pursuit of competitive advantage. We conceptualize the logic of digital business strategy in terms of two constructs: design capital (i.e., the cumulative stock of designs owned or controlled by a firm) and design moves (i.e., the discrete strategic actions that enlarge, reduce, or modify a firm’s stock of designs). We also identify two salient dimensions of design capital, namely, option value and technical debt. Using embedded case studies of four firms, we develop a rich conceptual model and testable propositions to lay out a design-based logic of digital business strategy. This logic highlights the interplay between design moves and design capital in the context of digital business strategy and contributes to a growing body of insights that link the design of digital artifacts to competitive strategy and firm-level performance.

Software quality assurance is concerned with the efficient and effective development of large, reliable, and high-quality software systems. In agile software development and maintenance, refactoring is an important phase for the continuous improvement of a software system by removing quality defects like code smells. As time is a crucial factor in agile development, not all quality defects can be removed in one refactoring phase (especially in one iteration). Documentation of quality defects that are found during automated or manual discovery activities (e.g., pair programming) is necessary to avoid wasting time by rediscovering them in later phases. Unfortunately, the documentation and handling of existing quality defects and refactoring activities is a common problem in software maintenance. To recall the rationales why changes were carried out, information has to be extracted from either proprietary documentations or software versioning systems. In this chapter, we describe a process for the recurring and sustainable discovery, handling, and treatment of quality defects in software systems. An annotation language is presented that is used to store information about quality defects found in source code and that represents the defect and treatment history of a part of a software system. The process and annotation language can not only be used to support quality defect discovery processes, but is also applicable in testing and inspection processes.

Multi-objective problems (MOPs), a class of optimization problems in the real-world, have multiple conflicting objectives. Multi-objective evolutionary algorithms (MOEAs) are known as great potential algorithms to solve difficult MOPs. With MOEAs, based on the principle of population, we have a set of optimal solutions (feasible solution set) after the search. We often use the concept of dominance relationship in population, and it is not difficult to find out set of Pareto optimal solutions during generations. However, with expensive optimization problems in the real world, it has to use a lot of fitness function evaluations during the search. To avoid expensive physical experiments, we can use computer simulations methods to solve the difficult MOPs. In fact, this way often costs expensive in computation and times for the simulation. In these cases, researchers discussed on the usage of surrogate models for evolutionary algorithms, especially for MOEAs to minimize the number of fitness callings. There are a series of proposals which were introduced with the usage of RBF, PRS, Kriging, SVM models. With the concept of machine learning, these MOEAs can solve expensive MOPS effectively. However, with our analysis, we found that using a fixed ratio of fitness functions and surrogate functions may make the unbalance of exploitation and exploration of the evolutionary process. In this paper, we suggest to use an adaptive control to determine the effective ratio during the search. The proposal is confirmed though an experiment with standard measurements on well-known benchmark sets.