One of the most important choices a researcher makes is selecting a research paradigm and methodology, without which they will be hampered in their search for knowledge and answers. Ideally, researchers consider all possible approaches and select the most appropriate one, but several factors constrain this: Time, familiarity with certain approaches, and the uncertainty of the benefit of change. \Cer draws from many research disciplines, exposing new possibilities that may not be seized due to these limitations. The Cards for Alternative Research Design (CARD) deck is designed to expand researchers awareness of different research approaches through a card-based prototyping exercise. This serious card-based game approach could be used by graduate students, early-career researchers, research course instructors, research mentors, and even experienced researchers. CARD games are intended to reduce the formality and potentially confrontational aspects of being asked to consider new approaches, allowing participants to examine their current research and plans through different paradigms, methodologies, and constraints, without it being a direct criticism of their current choices. This can increase the level of understanding of research framing and practice, strengthening the arguments for using a given approach and introducing valid arguments to adopt different approaches, with low time investment. This report summarizes the current evolution of the CARD deck, including an accompanying glossary and multiple games that can be played with the cards. 

Peer evaluation is widely used in team project courses in software engineering to assess individual contributions, promote accountability, and improve teamwork. However, current practices in peer evaluation vary significantly in terms of purpose, design, and implementation, which makes it challenging to compare them and establish best practices.This study systematically investigates peer evaluation in software engineering team project courses. In a literature review spanning from 2007 to 2025, we identified 50 articles that discuss the use of peer evaluation in these courses. By iteratively coding the findings and employing a thematic synthesis approach, we developed a taxonomy to characterize peer evaluation practices across four dimensions including their context, participants, mechanisms, and outcomes. Using this taxonomy, we organize the findings from existing literature and characterize how peer evaluation is applied across different courses. Additionally, we interviewed seven SE educators to collect their perspectives on the quality and applicability of the taxonomy. Based on their feedback, we refined the taxonomy and provided a set of guidelines to support educators and researchers in designing and implementing peer evaluation interventions, as well as reporting them in a structured and informed manner.

Software analytics (SA) is often proposed as a tool to support software engineering (SE) tasks. Several secondary studies on SA have been published, some published within the same calendar year. This presents an opportunity to take a meta-perspective and examine how the field of SA has been conceptualized and synthesized so far. By analyzing how SA is defined, which topics are emphasized, what search strategies are employed, and to what extent primary studies overlap, we aim to identify gaps, trends, and redundancies in the current body of secondary studies. Such insights can inform the design and focus of future secondary studies. We identified five secondary studies on SA published from 2015 to 2023 that cover primary research from 2000 to 2021. Despite similarities in objectives and overlapping search timeframes, the secondary studies have negligible overlap in their included primary studies. Each secondary study presents a distinct perspective, and collectively, the five secondary studies offer a fragmented rather than cohesive view of the research landscape. We present a structured overview of the identified secondary studies in terms of their objectives, research quality, and findings. This overview helps readers navigate and leverage existing research. The analysis also indicates that there is potential for further secondary research to build a more cohesive and comprehensive understanding of the SA literature. 

Several studies have evaluated various ML techniques and found promising results in classifying bug reports. However, these studies have used different evaluation designs, making it difficult to compare their results. Furthermore, they have focused primarily on accuracy and did not consider other potentially relevant factors such as generalizability, explainability, and maintenance cost. These two aspects make it difficult for practitioners and researchers to choose an appropriate ML technique for a given context. Therefore, we compare promising ML techniques against practitioners’ concerns using evaluation criteria that go beyond accuracy. Based on an existing framework for adopting ML techniques, we developed an evaluation framework for ML techniques for bug report classification. We used this framework to compare nine ML techniques on three datasets. The results enable a tradeoff analysis between various promising ML techniques. The results show that an ML technique with the highest predictive accuracy might not be the most suitable technique for some contexts. The overall approach presented in the paper supports making informed decisions when choosing ML techniques. It is not locked to the specific techniques, datasets, or factors we have selected here, and others could easily use and adapt it for additional techniques or concerns. Editor's note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

Context: The evidence for the prevalence of test smells at the unit testing level has relied on the accuracy of detection tools, which have seen intense research in the last two decades. The Eager Test smell, one of the most prevalent, is often identified using simplified detection rules that practitioners find inadequate.

Objective: We aim to improve the rules for detecting the Eager Test smell.

Method: We reviewed the literature on test smells to analyze the definitions and detection rules of the Eager Test smell. We proposed a novel, unambiguous definition of the test smell and a heuristic to address the limitations of the existing rules. We evaluated our heuristic against existing detection rules by manually applying it to 300 unit test cases in Java.

Results: Our review identified 56 relevant studies. We found that inadequate interpretations of original definitions of the Eager Test smell led to imprecise detection rules, resulting in a high level of disagreement in detection outcomes. Also, our heuristic detected patterns of eager and non-eager tests that existing rules missed.

Conclusion: Our heuristic captures the essence of the Eager Test smell more precisely; hence, it may address practitioners’ concerns regarding the adequacy of existing detection rules.

One of the most important choices a researcher makes is selecting a research paradigm and methodology, without which they will be hampered in their search for knowledge and answers. Ideally, researchers consider all possible approaches and select the most appropriate one, but several factors work against this: time, familiarity with certain approaches, and the uncertainty of the benefit of change. Computer Science Education Research draws from many research disciplines, exposing new possibilities that may not be seized due to these constraints. The Research Alternatives Exercise is designed to expand researchers' awareness of different research approaches through a rapid, card-based prototyping exercise. The card-based approach reduces the formality and potentially confrontational aspects of being asked to consider new approaches, allowing participants to examine their current research and plans through different paradigms, methodologies, and constraints, without it being a direct criticism of their current choices. This can increase the level of understanding of research framing and practice, strengthening the arguments for using a given approach and introducing valid arguments to adopt different approaches, with low time investment.

Characterising code quality is a challenge that was addressed by a previous ITiCSE Working Group (Börstler et al., 2017). As emerged from that study, educators, developers, and students have different perceptions of the aspects involved. The perception of code quality by CS1 students develops from the feedback they receive when submitting practical work. As a consequence of increasingly large classes and the widespread use of autograders, student code is predominantly assessed based on functional correctness, emphasising a machine-oriented perspective with scarce or no feedback given about human-oriented aspects of code quality. Such limited perception of code quality may negatively impact how students understand, create, and interact with code artefacts. Although Börstler et al. concluded that "code quality should be discussed more thoroughly in educational programs", the lack of materials and time constraints have slowed down progress in that regard. The goal of this Working Group is to support CS1 instructors who want to introduce a broader perspective on code quality in their classroom by providing a curated list of examples and activities suitable for novices. In order to achieve this goal, we have extracted from the CS education literature a range of examples and activities, which have then been analyzed and organized in terms of code quality dimensions. We have also mapped the topics covered in those materials to existing taxonomies relevant to code quality in CS1. Based on this work, we provide (1) a catalog of examples that illustrates the range of quality defects that could be addressed at the CS1 level and (2) a sample set of activities devised to introduce code quality to CS1 students. These materials have the potential to help educators address the subject in more depth.

Systematic Mapping Studies (SMSs) are valuable in evidence-based software engineering research. SMSs aim to provide an overview of research, identify gaps and trends, and assess the feasibility of conducting a more focused systematic literature review. In current guidelines for conducting SMSs, a quality assessment of the included papers is suggested only when the research questions explicitly require such a quality assessment. We agree with the recommendation that quality assessment is generally non-mandatory. However, SMSs deal with papers ranging from opinion papers to papers reporting highly rigorous empirical studies. Therefore, in this paper, we argue that analyzing the type of papers is essential for almost every intended purpose of an SMS. Otherwise, without distinguishing papers based on their types, we risk deriving a less informative or incomplete overview or, at worst, a misleading overview of research. Petersen et al. 'encourage' the classification of papers into six paper types as proposed by Wieringa et al.: evaluation research, solution proposal, validation research, philosophical papers, opinion papers, and personal experience papers. Given the lenient guidelines on assessing the quality of included studies, we recommend a stronger focus on classifying papers by type. 

The quality of the test suites and the constituent test cases significantly impacts confidence in software testing. While research has identified several quality attributes of test cases and test suites, there is a need for a better understanding of their relative importance in practice. We investigate practitioners' perceptions regarding the relative importance of quality attributes of test cases and test suites and the challenges that they face in ensuring the perceived important quality attributes. To capture the practitioners' perceptions, we conducted an industrial survey using a questionnaire based on the quality attributes identified in an extensive literature review. We used a sampling strategy that leverages LinkedIn to draw a large and heterogeneous sample of professionals with experience in software testing. We collected 354 responses from practitioners with a wide range of experience (from less than one year to 42 years of experience). We found that the majority of practitioners rated Fault Detection, Usability, Maintainability, Reliability, and Coverage to be the most important quality attributes. Resource Efficiency, Reusability, and Simplicity received the most divergent opinions, which, according to our analysis, depend on the software-testing contexts. Also, we identified common challenges that apply to the important attributes, namely inadequate definition, lack of useful metrics, lack of an established review process, and lack of external support. The findings point out where practitioners actually need further support with respect to achieving high-quality test cases and test suites under different software testing contexts. Hence, the findings can serve as a guideline for academic researchers when looking for research directions on the topic. Furthermore, the findings can be used to encourage companies to provide more support to practitioners to achieve high-quality test cases and test suites.

Team project courses in software engineering allow students to apply their acquired disciplinary knowledge while developing essential skills needed to work in the software industry. This paper examines the challenges and lessons learned by students in two team project courses involving industrial customers. The first course involves small teams and less complex project, whereas the second course, has larger teams and more complex projects. Using thematic analysis, we analyzed 158 reports submitted by two cohorts of students across two successive team project courses. As per our findings most challenges and lessons learned pertain to soft skills, such as teamwork, working in remote and hybrid setting, and collaboration with industrial customers. The results show that challenges and lessons learned evolve as students progress to the second team project course, for example, managing changes and addressing individual skill gaps were more pronounced in the first project course, while students reported greater coordination, communication, and contribution issues in the second team project course. The alignment between the challenges faced and the lessons learned suggests that addressing challenges in teamwork, collaborating with industrial customers, and working in hybrid or remote settings helped students develop effective strategies to mitigate these challenges. This process offers a valuable learning experience for the students, enriching their professional growth.