Code review in the industry today is different to code review twenty years ago. The process has become more lightweight, reviews are performed frequently and change-based and the use of specialized tools is increasing. An accurate view of the current state of the industrial practice is an indispensable foundation for improving it. Most recent descriptions of review practices come from a limited population of large hightech companies. Therefore, we used interviews with software engineering professionals from a broad sample of 19 companies to gain insight into their code review practices. We augmented our findings with data for 11 companies found through a semisystematic literature review. There are many commonalities in the code review processes of these companies, but also a lot of variation in the details. A simple process taxonomy cannot describe these variations adequately. Therefore, we present a faceted classification scheme that is grounded in our observations.

Code review is known to be an efficient quality assurance technique. Many software companies today use it, usually with a process similar to the patch review process in open source software development. However, there is still a large fraction of companies performing almost no code reviews at all. And the companies that do code reviews have a lot of variation in the details of their processes. For researchers trying to improve the use of code reviews in industry, it is important to know the reasons for these process variations. We have performed a grounded theory study to clarify process variations and their rationales. The study is based on interviews with software development professionals from 19 companies. These interviews provided insights into the reasons and influencing factors behind the adoption or non-adoption of code reviews as a whole as well as for different process variations. We have condensed these findings into seven hypotheses and a classification of the influencing factors. Our results show the importance of cultural and social issues for review adoption. They trace many process variations to differences in development context and in desired review effects.

This article investigates relationships between media, mood, and communication in teams, and studies how they are related to project success. Team projects are an essential part of the software engineering curriculum. Student teams carry out full software projects, including requirements elicitation, project management, implementation, and testing. This requires various technical skills, but non-technical and psychological aspects are of utmost importance as well, just as in professional software teams. Modern software is often developed by distributed teams. In many cases, team members feel isolated and distant from each other. Indirect communication and inappropriate media create a similar feeling of distance as geographical location. This perceived distance could have an impact on their individual and group moods, and eventually on project success. Therefore, these factors should be considered in educational software engineering team projects. In a longitudinal study at Leibniz Universität Hannover, 20 student teams were observed over a period of 4 months. They were free to schedule team meetings when and where they wanted; and they could use any communication media they chose. Statistical correlations and non-parametric test are used for quantitative empirical analysis. Furthermore, we used analyses of variance for repeated measures to investigate conflicts over time. Results led to a number of recommendations for course organizers. They are interesting for software engineering in general.

There are many different approaches to testing software, with different benefits for software quality and the development process. Yet, it is not well understood what developers struggle with when getting started with testing - and why some do not test at all or not as much as would be good for their project. This missing understanding keeps us from improving processes and tools to help novices adopt proper testing practices. We conducted a qualitative study with 97 computer science students. Through interviews, we explored their experiences and attitudes regarding testing in a collaborative software project. We found enabling and inhibiting factors for testing activities, the different testing strategies they used, and novices’ perceptions and attitudes of testing. Students push test automation to the end of the project, thus robbing themselves from the advantages of having a test suite during implementation. Students were not convinced of the return of investment in automated tests and opted for laborious manual tests - which they often regretted in the end. Understanding such challenges and opportunities novices face when confronted with adopting testing can help us improve testing processes, company policies, and tools. Our findings provide recommendations that can enable organizations to facilitate the adoption of testing practices by their members.

Students of software engineering need a mental model to guide their activities; this mental model should contain a concept of success. They should be able to contribute to that success criterion through their daily work. Although economic gain is a wide-spread measure of success, it cannot be fully controlled by developers or even project leaders. Inappropriate deadlines, political influences, and many other aspects are beyond the control of software engineers. A success criterion closer to the sphere of influence of software engineers could better guide decisions of students - and practicing software engineers as well. We introduce the concept of requirements compliance1, which measures the size of the intersection between stated and implemented requirements. Fulfilled requirements are considered a success. Both unfulfilled requirements and unsolicited features are considered indications of reduced success: The latter consume resources without meeting stated needs, while missing requirements ignore customer requests. In this paper, we motivate and introduce the core concept of requirements compliance. We show how it can be and has been used for different variants of software engineering education, including serious educational games. We go beyond this prior use by identifying ways of modeling, observing and controlling requirements compliance in a series of student projects. We discuss opportunities for using this concept in software engineering education - but also build on the mental model in research and in practice.

Many software development projects struggle with creating and communicating a testing culture that is appropriate for the project's needs. This may degrade software quality by leaving defects undiscovered. Previous research suggests that social coding sites such as GitHub provide a collaborative environment with a high degree of social transparency. This makes developers' actions and interactions more visible and traceable. We conducted interviews with 33 active users of GitHub to investigate how the increased transparency found on GitHub influences developers' testing behaviors. Subsequently, we validated our findings with an online questionnaire that was answered by 569 members of GitHub. We found several strategies that software developers and managers can use to positively influence the testing behavior in their projects. However, project owners on GitHub may not be aware of them. We report on the challenges and risks caused by this and suggest guidelines for promoting a sustainable testing culture in software development projects.

During acceptance testing customers assess whether a system meets their expectations and often identify issues that should be improved. These findings have to be communicated to the developers -- a task we observed to be error prone, especially in distributed teams. Here, it is normally not possible to have developer representatives from every site attend the test. Developers who were not present might misunderstand insufficiently documented findings. This hinders fixing the issues and endangers customer satisfaction. Integrated feedback systems promise to mitigate this problem. They allow to easily capture findings and their context. Correctly applied, this technique could improve feedback, while reducing customer effort. This paper collects our experiences from comparing acceptance testing with and without feedback systems in a distributed project. Our results indicate that this technique can improve acceptance testing -- if certain requirements are met. We identify key requirements feedback systems should meet to support acceptance testing.