Recently, many faculty have begun to engage students in free and open source software (FOSS) development both for pedagogical advantage and in response to increased student demand. Faculty see FOSS as providing authentic computing artifacts to enrich course content. Students see FOSS projects as a way to contribute to something real and develop their skills while building a portfolio of their work to share with potential employers. Despite these benefits, CS teachers and students have expressed frustration with the challenges of engaging with existing FOSS projects.

It is acknowledged that student blogs in computer science courses can strengthen student communication skills, but it is rarely reported that these blogs can also provide a window into their authors' multiple facets. Computer science (CS) students are not one-dimensional; they have interests outside of CS that are often hidden, isolated from their CS experience, but which, if integrated into the CS education, could enrich their experience, increase their motivation, and enhance their relationships with their peers. We have discovered that when students write regular blogs, they use them as opportunities to express those interests and reveal talents that can be leveraged by faculty to their advantage. What we learn through these blogs helps us to increase student engagement in the course and makes us better advisers for their career in school and beyond. Common to the structure of our courses is that students are encouraged to review each others' blogs, which are in public repositories, and to make suggestions to improve them. This mutual and collective review process is beneficial to all of them, because they learn about and help each other in a positive way. Students also learn about themselves by being able to look back at how their ideas evolved, how much they learned, and what they have accomplished.

Computing often makes headlines for negative social impacts such as data breaches, algorithmic bias, and cyber warfare. The many ways that computing can create social good are similarly powerful but seem to get much less attention. This BoF will explore ways to incorporate the positive potential of computing for social good in undergraduate courses. The organizers are especially interested in active learning approaches where students can experience first-hand the positive social impact of computing. The discussion will allow faculty who have included computing for social good in their courses to exchange ideas and share their experiences. Faculty who are interested in this area but have not yet tried it in their courses are encouraged to join the discussion.

Many computer science students are eager to learn about how to contribute to Free and Open Source Software (FOSS) projects, but like most computer science departments, ours has no courses to help them achieve that goal. Creating such courses requires buy-in by deans, department chairs, and other faculty, who, because of lack of knowledge, can have little interest in supporting such efforts. Our poster shows how we solved this problem and created a means for students to simultaneously learn how to be contributors to FOSS projects and earn credit toward their major. It shows how we sought and found interested students and engaged them through repeated, informal meetings, which we used to gain the support of the chair and dean, and how we simulated a prototype course by having the students sign up for independent study credit. The group then met at regular intervals, communicated and shared work using discussion forums, source code repositories, and IRC chat. All course content is based on open source materials, including free textbooks, an abundance of on-line tutorials and reference materials, lecture notes and assignments that we wrote, with open source licenses, and other materials borrowed from http://foss2serve.org. The success of this simulated course led to the creation of a pilot course for the Spring 2019 semester, endorsed by the college. The poster presents several assignments, discusses preliminary findings, and provides links to materials that we created for this course. It also shows how we encouraged students to work on humanitarian FOSS (HFOSS) projects.

We present a sequence of programming projects for the CS2 introductory computer science course which provides a holistic experience for students in preparation for their future roles in any workplace in which software is developed, whether in academia, government, industry, or elsewhere. The progression of projects has several key features: (1) they are easily reused simply by changing the underlying input data set; (2) they offer a flexible degree of analysis objectives; (3) they take advantage of freely available open source data sets and encourage their use; (4) they are designed to be small models of the kinds of problems likely to be encountered outside of the classroom environment; (5) they facilitate the introduction of increasingly more sophisticated software testing concepts, starting with the most elementary; (6) a student who attempts to do them in earnest, even if unsuccessful, can still learn important lessons about the different facets of programming and problem solving; and (7) a student's understanding of the relationship between choice of data representation and performance will likely mature if he or she successfully completes the assignments.

The effectiveness of a test data adequacy criterion for a given program and specification is the probability that a test set satisfying the criterion will expose a fault. Experiments were performed to compare the effectiveness of the mutation testing and all-uses test data adequacy criteria at various coverage levels, for randomly generated test sets. Large numbers of test sets were generated and executed, and for each, the proportion of mutants killed or def-use associations covered was measured. This data was used to estimate and compare the effectiveness of the criteria. The results were mixed: at the highest coverage levels considered, mutation was more effective than all-uses for five of the nine subjects, all-uses was more effective than mutation for two subjects, and there was no clear winner for two subjects. However, mutation testing was much more expensive than all-uses. The relationship between coverage and effectiveness for fixed-sized test sets was also explored and was found to be nonlinear and, in many cases, nonmonotonic.

In previously reported research we designed and analyzed algorithms that improved upon the run time complexity of all known weak and strong mutation analysis methods at the expense of increased space complexity. Here we describe a new serial strong mutation algorithm whose running time is on the average much faster than the previous ones and that uses significantly less space than them also. Its space requirement is approximately the same as that of Mothra, a well-known and readily available implemented system. Moreover, while this algorithm can serve as basis for a new mutation system, it is designed to be consistent with the Mothra architecture, in the sense that, by replacing certain modules of that system with new ones, a much faster system will result. Such a Mothra-based implementation of the new work is in progress.

Existing serial algorithms to do mutation analysis are inefficient, and descriptions of parallel mutation systems pre-suppose that these serial algorithms are the best one can do serially. We present a universal mutation analysis data structure and new serial algorithms for both strong and weak mutation analysis that on average should perform much faster than existing ones, and can never do worse. We describe these algorithms as well as the results of our analysis of their run time complexities. We believe that this is the first paper in which analytical methods have been applied to obtain the run time complexities of mutation analysis algorithms.

An experiment comparing the effectiveness of the all-uses and all-edges test data adequacy criteria is discussed. The experiment was designed to overcome some of the deficiencies of previous software testing experiments. A large number of test sets was randomly generated for each of nine subject programs with subtle errors. For each test set, the percentages of executable edges and definition-use associations covered were measured, and it was determined whether the test set exposed an error. Hypothesis testing was used to investigate whether all-uses adequate test sets are more likely to expose errors than are all-edges adequate test sets. Logistic regression analysis was used to investigate whether the probability that a test set exposes an error increases as the percentage of definition-use associations or edges covered by it increases. Error exposing ability was shown to be strongly positively correlated to percentage of covered definition-use associations in only four of the nine subjects. Error exposing ability was also shown to be positively correlated to the percentage of covered edges in four different subjects, but the relationship was weaker.>

The comparative analysis of test data criteria in software testing is considered, and an attempt is made to investigate how criteria have been and should be compared to each other. It is argued that there are two fundamentally different goals in comparing criteria: (1) to compare the error-exposing ability of criteria, and (2) to compare the cost of using the criteria for selecting and/or evaluating test data. Relations such as the power relation and probable correctness are clearly in the first category, and test case counting is clearly in the second category. Subsumption, in contrast, is not entirely in either category. It is shown that the subsumption relation primarily compares the difficulty of satisfying two criteria. If one assumes that the criteria being compared are applicable, then one can infer their relative power and size complexities from the subsumption relation. In addition, it is shown that, while the size complexity of a criterion gives some indication of the relative cost of using the criterion, it is by no means a sufficient measure of the overall difficulty of using that criterion, which also includes the process of checking whether the predicate defined by the criterion has been satisfied, which may not only be difficult, but impossible.>

A definition of software reliability is proposed in which reliability is treated as a generalization of the probability of correctness of the software in question. A tolerance function is introduced as a method of characterizing an acceptable level of correctness. This in turn is used, together with the probability function defining the operational input distribution, as a parameter of the definition of reliability. It is shown that the definition can be used to provide many natural models of reliability by varying the tolerance function and that it may be reasonably approximated using well-chosen test sets. It is also shown that there is an inherent limitation to the measurement of reliability using finite test sets.>