Enhancing Testing Technologies for Globalization of Software Engineering and Productivity

Enhancing Testing Technologies for Globalization of Software Engineering and Productivity

Amir H. Khan, Atif M. Memon
Copyright: © 2010 |Pages: 12
DOI: 10.4018/978-1-60566-731-7.ch005
OnDemand:
(Individual Chapters)
Available
$37.50
Current Special Offers
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

While successful at increasing code churn rates, global software development and evolution suffers from several quality assurance challenges. First, sub-groups within developer communities often work on loosely coupled parts of the application code. Each developer (sub-group) typically modifies a local “copy” of the code and frequently checks-in changes (and downloads other developers’ changes). Consequently, after making a change, a developer may not immediately realize that the local change has inadvertently broken other parts of the overall software code. This situation is compounded as there is little direct inter-developer communication -- almost all communication is done via web-based tools such as code commit log messages, bug reports, change-requests, and comments. This chapter outlines the challenges that global software development adds to the already-complex quality assurance process. Two case studies of real software projects implemented in a disturbed manner demonstrate the importance of continuous integration testing and the positive consequences of increasing the diversity of quality assurance techniques/tools. Finally, it concludes with an outline of how software integration testing needs to be enhanced to meet the new challenges of globalization.
Chapter Preview
Top

2. Testing Techniques For Evolving Software

The ongoing quest of the software industry to keep software of all sizes integrated throughout the course of its development, has led to the mainstream adoption of many enabling practices. Nightly/daily builds and smoke tests (Karlsson, Andersson, & Leion, 2000), (McConnell, 1996a), (Olsson, 1999) have become widespread (Robbins, 2000), (Halloran, Scherlis, 2002). During nightly builds, a development version of the software is checked out from the source code repository tree, compiled, linked, and “smoke tested” (“smoke tests” are also called “sniff tests” or “build verification suites” (Marick, 1998)). Typically, unit tests (Robbins, 2000) and sometimes acceptance tests (Crispin, House, Wade, 2001) are executed during smoke testing. Such tests are run to (re)validate the basic functionality of the system (Marick, 1998). Smoke tests exercise the entire system; they do not have to be an exhaustive test suite but they should be capable of raising a “something is wrong here” alarm. A build that passes the smoke test is considered to be “a good build.” As is the case with all testing techniques (Schach, 1996), it is quite possible that problems are found in a good build during more comprehensive testing later or after the software has been fielded.

Complete Chapter List

Search this Book:
Reset