SUMMARY During software development, companies are frequently faced with lack of time and resources, which limits their ability to effectively complete testing efforts. This paper presents a system‐level, value‐driven approach to test case prioritization called the Prioritization of Requirements for Test (PORT). PORT involves analysing and assigning value to each requirement using the following four factors: requirements volatility, customer priority, implementation complexity, and fault proneness. System test cases are prioritized such that the test cases for requirements with higher priority are executed earlier during system test. PORT was applied to four student team projects as well as an industrial case study. The results show that PORT improves the rate of detection of severe failures over random prioritization. Additionally, the results indicate that customer priority was the most important contributor towards improved rate of failure detection. Copyright © 2013 John Wiley & Sons, Ltd.

Security inspection and testing require experts in security who think like an attacker. Security experts need to know code locations on which to focus their testing and inspection efforts. Since vulnerabilities are rare occurrences, locating vulnerable code locations can be a challenging task. We investigated whether software metrics obtained from source code and development history are discriminative and predictive of vulnerable code locations. If so, security experts can use this prediction to prioritize security inspection and testing efforts. The metrics we investigated fall into three categories: complexity, code churn, and developer activity metrics. We performed two empirical case studies on large, widely used open-source projects: the Mozilla Firefox web browser and the Red Hat Enterprise Linux kernel. The results indicate that 24 of the 28 metrics collected are discriminative of vulnerabilities for both projects. The models using all three types of metrics together predicted over 80 percent of the known vulnerable files with less than 25 percent false positives for both projects. Compared to a random selection of files for inspection and testing, these models would have reduced the number of files and the number of lines of code to inspect or test by over 71 and 28 percent, respectively, for both projects.

Software fails and fixing it is expensive. Research in failure prediction has been highly successful at modeling software failures. Few models, however, consider the key cause of failures in software: people. Understanding the structure of developer collaboration could explain a lot about the reliability of the final product. We examine this collaboration structure with the developer network derived from code churn information that can predict failures at the file level. We conducted a case study involving a mature Nortel networking product of over three million lines of code. Failure prediction models were developed using test and post-release failure data from two releases, then validated against a subsequent release. One model's prioritization revealed 58% of the failures in 20% of the files compared with the optimal prioritization that would have found 61% in 20% of the files, indicating that a significant correlation exists between file-based developer network metrics and failures.

In industrial practice, information on the software field quality of a product is available too late in the software lifecycle to guide affordable corrective action. An important step towards remediation of this problem lies in the ability to provide an early estimation of post-release field quality. This paper evaluates the Software Testing and Reliability Early Warning for Java (STREW-J) metric suite leveraging the software testing effort to predict post-release field quality early in the software development phases. The metric suite is applicable for software products implemented in Java for which an extensive suite of automated unit test cases are incrementally created as development proceeds. We validated the prediction model using the STREW-J metrics via a two-phase case study approach which involved 27 medium-sized open source projects, and five industrial projects. The error in estimation and the sensitivity of the predictions indicate the STREW-J metric suite can be used effectively to predict post-release software field quality.

As pair programming is used widely in software engineering education, instructors may wish to proactively form pairs to increase the likelihood of compatible pairs. A study involving 361 software engineering students was carried out at North Carolina State University to understand and predict pair compatibility. We have found that students are compatible with partners whom they perceive of similar skill, although instructors cannot proactively manage this perception. Pairing of two minority students is more likely and mixed gender pairs are less likely to be compatible. Additionally, pairing of students with similar actual skill level as measured by midterm grades in class, GPA, and SAT/GRE scores also likely results in compatible pairs. Our research addresses the following challenges faced by instructors in software engineering: 1) organizational concern in pairing of students; 2) increasing the retention rates of female and minority students in classes; and 3) proactively forming mutually-compatible pairs.

A classic question in software development is "How much testing is enough?" Aside from dynamic coverage-based metrics, there are few measures that can be used to provide guidance on the quality of an automatic test suite as development proceeds. This paper utilizes the software testing and reliability early warning (STREW) static metric suite to provide a developer with indications of changes and additions to their automated unit test suite and code for added confidence that product quality will be high. Retrospective case studies to assess the utility of using the STREW metrics as a feedback mechanism were performed in academic, open source and industrial environments. The results indicate at statistically significant levels the ability of the STREW metrics to provide feedback on important attributes of an automatic test suite and corresponding code