The world faces escalating crises: record-breaking temperatures, widespread fires, severe flooding, increased oceanic microplastics, and unequal resource distribution. Academia introduces courses around sustainability to meet the new demand, but software engineering education lags behind. While software systems contribute to environmental issues through high energy consumption, they also hold the potential for solutions, such as more efficient and equitable resource management. Yet, sustainability remains a low priority for many businesses, including those in the digital sector. Business as usual is no longer viable. A transformational change in software engineering education is urgently needed. We must move beyond traditional curriculum models and fully integrate sustainability into every aspect of software development. By embedding sustainability as a core competency, we can equip future engineers not only to minimise harm but also to innovate solutions that drive positive, sustainable change. Only with such a shift can software engineering education meet the demands of a world in crisis and prepare students to lead the next generation of sustainable technology. This article discusses a set of challenges and proposes a customisable education roadmap for integrating sustainability into the software engineering curricula. These challenges reflect our perspective on key considerations, stemming from regular, intensive discussions in regular workshops among the authors and the community, as well as our extensive research and teaching experience in the field.

Many test prioritisation techniques have been proposed in order to improve test effectiveness of Continuous Integration (CI) pipelines. Particularly, diversity-based testing (DBT) has shown promising and competitive results to improve test effectiveness. However, the technical and practical challenges of introducing test prioritisation in CI pipelines are rarely discussed, thus hindering the applicability and adoption of those proposed techniques. This research builds on our prior work in which we evaluated diversity-based techniques in an industrial setting. This work investigates the factors that influence the adoption of DBT both in connection to improvements in test cost-effectiveness, as well as the process and human related challenges to transfer and use DBT prioritisation in CI pipelines. We report on a case study considering the CI pipeline of Axis Communications in Sweden. We performed a thematic analysis of a focus group interview with senior practitioners at the company to identify the challenges and perceived benefits of using test prioritisation in their test process. Our thematic analysis reveals a list of ten challenges and seven perceived effects of introducing test prioritisation in CI cycles. For instance, our participants emphasized the importance of introducing comprehensible and transparent techniques that instill trust in its users. Moreover, practitioners prefer techniques compatible with their current test infrastructure (e.g., test framework and environments) in order to reduce instrumentation efforts and avoid disrupting their current setup. In conclusion, we have identified tradeoffs between different test prioritisation techniques pertaining to the technical, process and human aspects of regression testing in CI. We summarize those findings in a list of seven advantages that refer to specific stakeholder interests and describe the effects of adopting DBT in CI pipelines.

Abstract Several operations, ranging from regular code updates to compiling, building, testing, and distribution to customers, are consolidated in continuous integration and delivery. Professionals seek additional information to complete the mission at hand during these tasks. Developers who devote a large amount of time and effort to finding such information may become distracted from their work. We will better understand the processes, procedures, and resources used to deliver a quality product on time by defining the types of information that software professionals seek. A deeper understanding of software practitioners' information needs has many advantages, including remaining competitive, growing knowledge of issues that can stymie a timely update, and creating a visualisation tool to assist practitioners in addressing their information needs. This is an extension of a previous work done by the authors. The authors conducted a multiple‐case holistic study with six different companies (38 unique participants) to identify information needs in continuous integration and delivery. This study attempts to capture the importance, frequency, required effort (e.g. sequence of actions required to collect information), current approach to handling, and associated stakeholders with respect to identified needs. 27 information needs associated with different stakeholders (i.e. developers, testers, project managers, release team, and compliance authority) were identified. The identified needs were categorised as testing, code & commit, confidence, bug, and artefacts. Apart from identifying information needs, practitioners face several challenges in developing visualisation tools. Thus, 8 challenges that were faced by the practitioners to develop/maintain visualisation tools for the software team were identified. The recommendations from practitioners who are experts in developing, maintaining, and providing visualisation services to the software team were listed.

Developers often spend time to determine whether test case failures are real failures or flaky. The flaky tests, also known as non-deterministic tests, switch their outcomes without any modification in the codebase, hence reducing the confidence of developers during maintenance as well as in the quality of a product. Re-running test cases to reveal flakiness is resource-consuming, unreliable and does not reveal the root causes of test flakiness. Our paper evaluates a multi-factor approach to identify flaky test executions implemented in a tool named MDF laker. The four factors are: trace-back coverage, flaky frequency, number of test smells, and test size. Based on the extracted factors, MDFlaker uses k-Nearest Neighbor (KNN) to determine whether failed test executions are flaky. We investigate MDFlaker in a case study with 2166 test executions from different open-source repositories. We evaluate the effectiveness of our flaky detection tool. We illustrate how the multi-factor approach can be used to reveal root causes for flakiness, and we conduct a qualitative comparison between MDF laker and other tools proposed in literature. Our results show that the combination of different factors can be used to identify flaky tests. Each factor has its own trade-off, e.g., trace-back leads to many true positives, while flaky frequency yields more true negatives. Therefore, specific combinations of factors enable classification for testers with limited information (e.g., not enough test history information).

Summary Identifying the root causes of test flakiness is one of the challenges faced by practitioners during software testing. In other words, the testing of the software is hampered by test flakiness. Since the research about test flakiness in large‐scale software engineering is scarce, the need for an empirical case‐study where we can build a common and grounded understanding of the problem as well as relevant remedies that can later be evaluated in a large‐scale context is a necessity. This study reports the findings from a multiple‐case study. The authors conducted an online survey to investigate and catalogue the root causes of test flakiness and mitigation strategies. We attempted to understand how practitioners perceive test flakiness in closed‐source development, such as how they define test flakiness and what practitioners perceive can affect test flakiness. The perceptions of practitioners were compared with the available literature. We investigated whether practitioners' perceptions are reflected in the test artefacts such as what is the relationship between the perceived factors and properties of test artefacts. This study reported 19 factors that are perceived by professionals to affect test flakiness. These perceived factors are categorized astest code,system under test,CI/test infrastructure, andorganization‐related. The authors concluded that some of the perceived factors in test flakiness in closed‐source development are directly related to non‐determinism, whereas other perceived factors concern different aspects, for example, lack of good properties of a test case, deviations from the established processes, and ad hoc decisions. Given a data set from investigated cases, the authors concluded that two of the perceived factors (i.e., test case size and test case simplicity) have a strong effect on test flakiness.

This Innovative Practice Full Paper presents an approach to integrate three critical elements in Computer Science education. The call to imbue computer science graduates with strategic skills needed to address our pressing global sustainability challenges is extremely important, and a great challenge to degree programmes in computer science and software engineering. Doing this successfully requires great care, and possibly several iterations across an entire curriculum. In this regard, learning for sustainability faces similar challenges as understanding scientific results and ethics. Improving skills in searching for, reading, and producing academic texts are often neglected, as are skills in understanding ethics; what norms and values that guide our choices of methods for solving problems. To handle the fact that these subjects (academic writing, ethics and sustainability) are treated separately, and thereby lowering student engagement with the topics, we have successfully integrated them into one coherent subject of Professionalism in Computer Science. By integrating the three subjects, we do three things: a) describe a multi-faceted but integrated engineering role; b) integrate the three aspects of the role we focus on in education and steer away from the view that these are add-ons; and c) increase the motivation of students to take on these aspects of the engineering role. Our approach uses a flipped-classroom style with students playing educational games, participating in discussion seminars and conducting critical analyses of other students' choices in IT system design. Much emphasis is on the students academic writing abilities, including critical information search and a student peer-review procedure. Also, we do this using an integrated assessment format where teachers from different disciplinary backgrounds jointly assess material from students, which stimulates discussions among ourselves about what and how to assess, and provides a practical way to integrate assessments. We present results from attitude surveys, course evaluations and the contents of the students' analyses in their final essays. In conclusion, our approach demonstrates a clear shift in how students perceive sustainability, showing that it is possible to achieve changes in attitude towards the subjects as such and their importance for computer scientists.

Integrating novel software systems in our society, economy, and environment can have far-reaching effects. As a result, software systems should be designed in such a way as to maintain or improve the sustainability of the socio-technical system of their destination. However, a paradigm shift is required to raise awareness of software professionals on the potential sustainability effects of software systems. While Requirements Engineering is considered the key to driving this change, requirements engineers lack the knowledge, experience and methodological support for doing so. This paper presents a question-based framework for raising awareness of the potential effects of software systems on sustainability, as the first step towards enabling the required paradigm shift. A feasibility study of the framework was carried out with two groups of computer science students. The results of the study indicate that the framework helps enable discussions about potential effects that software systems could have on sustainability.