Cultural dynamics play a significant role in the unfolding of the global software practice. Research in the other disciplines have utilized the idea of cultural models to help researchers investigate cultural influence in their respective fields. Cultural models are defined as the taken-for-granted, pre-supposed models of the world that are shared widely by members of a society and that help the members understand their world and influence their behavior in that world. Utilizing this cultural models idea, we conducted an ethnographically-informed investigation of a global software practice at a large vendor organization in India to uncover some cultural models embedded in the practice. This paper presents an ethnographic account of an escalation situation that occurred in the field. Using this situation as our unit of analysis, we uncovered three cultural models - Agreement, Flexibility, and Trust Cultural Models - that appear to have influenced the organization of the behaviors of the participant members. The findings illustrate how the internalized cultural models influenced the members' behaviors to make decision that conflicted the business prospects (e.g., Agreement Model), the different members internalized different understanding of the cultural elements (e.g., Trust Model), and the cultural models tacitly played the role of "cultural blind spots" (e.g., Flexibilty Model). Thus, the research demonstrates how the technical system of global software engineering is complexly intertwined with the cultural system of its members.

This paper presents the results of a four-month ethnographically-informed study that we performed at a vendor organization in India to understand how culture influences global software-testing practice. The paper discusses our findings and analysis of software-testing activities conducted by two teams: one working for a Japanese client, the other working for a U.S. client. The findings show the differences in the software-testing approaches of the two teams with respect to team structure, thought processes, expectations, testing focus areas, and trust levels. The analysis suggests that cultural differences (e.g., national, user, and software-developer) are responsible for these differences in testing approaches. The paper describes the study details, our observations about the different testing-approach patterns that the teams adopted, our analysis of the reasons for those differences, and our reflections and suggested implications based on the findings.

In the era of globally distributed software engineering, the practice of outsourced, off shored software testing (OOST) has witnessed increasing adoption. Although there have been ethnographic studies of the development aspects of global software engineering and of the in-house practice of testing, there have been fewer studies of OOST, which to succeed, can require dealing with unique challenges. To address this limitation of the existing studies, we conducted-and, in this paper, report the findings of-an ethnographically-informed study of three vendor testing teams involved in OOST practice. Specifically, we studied how test engineers perform their tasks under deadline pressures, the challenges that they encounter, and their strategies for coping with the challenges. Our study provides insights into the differences and similarities between in-house testing and OOST, the influence of team structures on the degree of pressure experienced by test engineers in the OOST setup, and the factors that influence quality and productivity under OOST.

Although many static-analysis techniques have been developed for automatically detecting bugs, such as null dereferences, fewer automated approaches have been presented for analyzing whether and how such bugs are fixed. Attempted bug fixes may be incomplete in that a related manifestation of the bug remains unfixed. In this paper, we characterize the “completeness” of attempted bug fixes that involve the flow of invalid values from one program point to another, such as null dereferences, in Java programs. Our characterization is based on the definition of a bug neighborhood, which is a scope of flows of invalid values. We present an automated analysis that, given two versions P and P' of a program, identifies the bugs in P that have been fixed in P', and classifies each fix as complete or incomplete. We implemented our technique for null-dereference bugs and conducted empirical studies using open-source projects. Our results indicate that, for the projects we studied, many bug fixes are not complete, and thus, may cause failures in subsequent executions of the program.

Several recent studies indicate that many industrial applications exhibit poor quality in the design of exception-handling. To improve the quality of error-handling, we need to understand the problems and obstacles that developers face when designing and implementing exception-handling. In this paper, we present our research on understanding the viewpoint of developers-novices and experts-toward exception-handling. First, we conducted a study with novice developers in industry. The study results reveal that novices tend to ignore exceptions because of the complex nature of exception-handling. Then, we conducted a second study with experts in industry to understand their perspective on exception-handling. The study results show that, for experts, exception-handling is a crucial part in the development process. Experts also confirm the novices' approach of ignoring exception-handling and provide insights as to why novices do so. After analyzing the study data, we identified factors that influence experts' strategy selection process for handling exceptions and then built a model that represents a strategy selection process experts use to handle exceptions. Our model is based on interacting modules and fault scope. We conclude with some recommendations to help novices improve their understanding of exception-handling.

This paper presents a new approach for locating and repairing faults that cause runtime exceptions in Java programs. The approach handles runtime exceptions that involve a flow of an incorrect value that finally leads to the exception. This important class of exceptions includes exceptions related to dereferences of null pointers, arithmetic faults (e.g., ArithmeticException), and type faults (e.g., ArrayStoreException). Given a statement at which such an exception occurred, the technique combines dynamic analysis (using stack-trace information) with static backward data-flow analysis (beginning at the point where the runtime exception occurred) to identify the source statement at which an incorrect assignment was made; this information is required to locate the fault. The approach also identifies the source statements that may cause this same exception on other executions, along with the reference statements that may raise an exception in other executions because of this incorrect assignment; this information is required to repair the fault. The paper also presents an application of our technique to null pointer exceptions. Finally, the paper describes an implementation of the null-pointer-exception analysis and a set of studies that demonstrate the advantages of our approach for locating and repairing faults in the program.