Thomas William Price

Self-regulated learning (SRL), the process by which learners actively plan, monitor, and reflect on their own learning, is a necessary skill for computing students to succeed. Researchers and instructors often rely on surveys to gain insights about computing students' knowledge or tendencies, including their SRL behaviors. However, researchers have long raised concerns about the validity of self-report measures for SRL, which may not accurately reflect students' actual SRL behaviors. In this paper, we investigated the relationship between students' self-reported SRL behaviors and their verbalized SRL behaviors during an authentic learning task. To do so, we administered the SRL-O questionnaire to students in a CS2 course and conducted a think-aloud study of a subset of those students when working on a coding task. We engaged in a process of qualitative coding to identify SRL processes from student think-aloud utterances and calculated the correlation between students' frequency of verbalized SRL behaviors and their self-reported behaviors within the same SRL construct (i.e., metacognition, planning). Our analysis yielded weak to negligible correlations between students' self-reported and identified SRL behaviors from their think-aloud utterances. To investigate further, we conducted a case study analysis of three students with similar self-reported SRL behaviors to explore how their self-regulation differed during their think-aloud study. We report examples of how different aspects of SRL are captured by both the survey and think-aloud study and make recommendations on how and when to utilize each measure for future research on computing students' SRL behavior.

When instructors want to design programming assignments to motivate their students, a common design choice is to have those students write code to make an artifact (e.g. apps, games, music, or images). The goal of this study is to understand the impacts of including artifact creation in a programming assignment on students' motivation, time on task, and cognitive load. To do so, we conducted a controlled lab study with seventy-three students from an introductory engineering course. The experimental group created a simulation they could interact with - thus having the full experience of artifact creation - while the control group wrote the exact same code, but evaluated it only with test cases. We hypothesized that students who could interact with the simulation they were programming would be more motivated to complete the assignment and report higher intrinsic motivation. However, we found no significant difference in motivation or cognitive load between the groups. Additionally, the experimental group spent more time completing the assignment than the control group. Our results suggest that artifact creation may not be necessary for motivating students in all contexts, and that artifact creation may have other effects such as increased time on task. Additionally, instructors and researchers should consider when, and in what contexts, artifact creation is beneficial and when it may not be.

Students often run into trouble when learning and practicing software testing. Recent prior studies demonstrate that a lightweight testing checklist that contains testing strategies and tutorial information could assist students in writing higher-quality tests. Prior studies also suggest that students with lower prior knowledge in unit testing may benefit more from the checklists. However, insights on the potential benefits and costs of the testing checklists in a classroom setting are lacking. To address this, we conducted an operational replication study in a CS2 course with 342 students (171 from Fall 2023 and 171 from Spring 2024) who had no prior experience in unit testing. In this paper, we report our experience in introducing the testing checklists as optional tool support in a CS2 course. To evaluate the effectiveness of the testing checklists in a classroom setting, we quantitatively analyze a combination of programming assignment submissions and survey responses generated by students. Our results suggest that students who received the testing checklists achieved significantly higher quality in their test code, in terms of code coverage and mutation coverage, compared to those who did not. We also observed that the exposure to the testing checklists in students’ early learning process encouraged students to write more unit tests to cover possible testing scenarios.