• WEs with high similarity guided developers to relevant directories and files. • Eye-tracking revealed the benefits and challenges of using WEs in OSS projects. • Data beyond the title and description is needed to obtain more relevant WEs. • WEs served as a starting point for resolving issues on GitHub. • WEs complement LLMs by offering community-validated solutions. The growing popularity of Open-Source Software projects has raised questions about the challenges novice and inexperienced developers face, especially on code contribution platforms like GitHub. This study investigates the effects of using Worked Examples (WEs) to support these developers in solving coding tasks, using eye-tracking and cognitive effort analysis. The research involved 20 undergraduate students analyzing issues from the JabRef repository, with recommendations of high and low-similarity examples provided by a bot. The findings suggest that highly similar WEs effectively guided participants by helping identify relevant directories, files, and code snippets, serving as starting points for task resolution. However, challenges emerged, such as difficulties locating useful information and risks of false proximity between seemingly similar issues. These results highlight the need for improved recommendation strategies beyond textual similarity, incorporating structural elements such as file and method names, while reducing cognitive load through better presentation of relevant information. This work lays the groundwork for exploring WEs in Open-Source Software projects and opens avenues for further research, including validating findings in other repositories and understanding behavioral patterns in using WEs.

Software systems have been continuously evolved and delivered with high quality due to the widespread adoption of automated tests. A recurring issue hurting this scenario is the presence of flaky tests, a test case that may pass or fail non-deterministically. A promising, but yet lacking more empirical evidence, approach is to collect static data of automated tests and use them to predict their flakiness. In this paper, we conducted an empirical study to assess the use of code identifiers to predict test flakiness. To do so, we first replicate most parts of the previous study of Pinto et al. (MSR 2020). This replication was extended by using a different ML Python platform (Scikit-learn) and adding different learning algorithms in the analyses. Then, we validated the performance of trained models using datasets with other flaky tests and from different projects. We successfully replicated the results of Pinto et al. (2020), with minor differences using Scikit-learn; different algorithms had performance similar to the ones used previously. Concerning the validation, we noticed that the recall of the trained models was smaller, and classifiers presented a varying range of decreases. This was observed in both intra-project and inter-projects test flakiness prediction.

A Software Product Line (SPL) represents a set of systems sharing common and variable features. The varying features and respective elements (variability) enable differentiating products of a certain domain. Thus, managing variability is a crucial activity for the success of SPL engineering, especially those based on UML due to a large amount of variability representation in different diagrams. There are few experiments in the literature to evaluate and to compare UML-based variability management approaches. In this paper, we analyze a subset of such approaches: SMarty (our approach), PLUS, and Razavian and Khosravi. We empirically compared them by conducting an experiment with more than 50 participants in terms of configuring SPL products and variability traceability among class and component diagram variable elements. We also analyzed the influence of the participants knowledge on the use of each approach and the amount of material consultation required for each variability management approach. In addition, we checked whether participants comprehend traceability capabilities of approaches. Results pointed out: SMarty is as effective as other studied approaches to configuring SPL specific products; the number of consultations on each approach instructional material did not influence effectiveness; and SMarty needs more participants previous knowledge on UML to configure SPL products.

Students usually have difficulties assimilating basic contents of introductory programming disciplines. Test-Driven Development (TDD) is an interesting approach to address this issue, but it does not focus on quality with respect to software testing. This study aims to verify the effectiveness of the use of software testing criteria for producing test cases with higher quality in the context of education with TDD. We used the test-driven development technique with a change in the refactoring step, adding an activity for creating test cases using software testing criteria. We performed two experimental studies to evaluate the effectiveness of the technique. Each study comprised two groups: one using traditional TDD and the other using TDD with test criteria, both having developed the same software. The results showed that groups applying the proposed intervention produced better test cases, with greater coverage, and not disrupting TDD. Moreover, we could observe that, in general, the test set for groups using TDD with criteria was more efficient, getting greater coverage with fewer test cases than groups using plain TDD.

The development of effective learning objects that explores blended learning, collaborative, and open development requires a laborious process. Information created and used at each phase of the process must be manually translated and augmented until achieving a proper product. The issue of systematic development of learning objects can be addressed using model-driven development. In fact, each phase in the development of learning objects requires a specific type of user/developer profile and generates different models. This article defines a model-driven approach for the open and collaborative development of learning objects. The approach herein described uses concept maps, represented as CXL documents, and statechart-based models, which are represented as UML models in XMI documents. Finally, the later model is used to generate learning objects, given a specific platform description. The current implementation supports the generation of slides in LaTeX/Beamer format. The feasibility of the approach is demonstrated using a course on software testing for undergraduate students, with learning objects generated for a context that comprises both traditional classroom and blended learning.