Search

Testing plug-in-based systems is challenging due to complex interactions among many different plug-ins, and variations in version and configuration. The objective of this paper is to increase our understanding of what testers and developers think and do when it comes to testing plug-in-based systems. To that end, we conduct a qualitative (grounded theory) study, in which we interview 25 senior practitioners about how they test plug-in applications based on the Eclipse plug-in architecture. The outcome is an overview of the testing practices currently used, a set of identified barriers limiting test adoption, and an explanation of how limited testing is compensated by self-hosting of projects and by involving the community. These results are supported by a structured survey of more than 150 professionals. The study reveals that unit testing plays a key role, whereas plug-in specific integration problems are identified and resolved by the community. Based on our findings, we propose a series of recommendations and areas for future research. [ABSTRACT FROM AUTHOR]

Service-oriented architectures (SOAs) have found their ways into industry to enable better business-to-business cooperation. With the advent of SOA, new challenges for software development and testing also appeared. In this article, we motivate the need for SOA online testing and show how it can reveal faults that slipped offline testing. The paper outlines a case study in which online testing has been implemented as proof-of-concept, but also evaluated in terms of its effectiveness to identify typical SOA runtime reconfiguration problems according to an existing fault taxonomy. The experiments of the case study demonstrate that online testing (1) can detect many typical runtime reconfiguration faults, and that (2) online testing provides additional value over offline testing. [ABSTRACT FROM AUTHOR]

Because of its many uses and benefits, code reviews are a standard part of the modern software engineering workflow. Since they require involvement of people, code reviewing is often the longest part of the code integration activities. Using experience gained at Microsoft and with support of data, we posit (1) that code reviews often do not find functionality issues that should block a code submission; (2) that effective code reviews should be performed by people with specific set of skills; and (3) that the social aspect of code reviews cannot be ignored. We find that we need to be more sophisticated with our guidelines for the code review workflow. We show how our findings from code reviewing practice influence our code review tools at Microsoft. Finally, we assert that, due to its costs, code reviewing practice is a topic deserving to be better understood, systematized and applied to software engineering workflow with more precision than the best practice currently prescribes. [ABSTRACT FROM AUTHOR]