@article {15478,
	title = {Generating Event Sequence-Based Test Cases Using GUI Runtime State Feedback},
	journal = {Software Engineering, IEEE Transactions on},
	volume = {36},
	year = {2010},
	month = {2010/02//jan},
	pages = {81 - 95},
	abstract = {This paper presents a fully automatic model-driven technique to generate test cases for graphical user interfaces (GUIs)-based applications. The technique uses feedback from the execution of a ??seed test suite,?? which is generated automatically using an existing structural event interaction graph model of the GUI. During its execution, the runtime effect of each GUI event on all other events pinpoints event semantic interaction (ESI) relationships, which are used to automatically generate new test cases. Two studies on eight applications demonstrate that the feedback-based technique 1) is able to significantly improve existing techniques and helps identify serious problems in the software and 2) the ESI relationships captured via GUI state yield test suites that most often detect more faults than their code, event, and event-interaction-coverage equivalent counterparts.},
	keywords = {automatic model driven technique, event interaction coverage equivalent counterparts, event semantic interaction relationships, event sequence based test cases, Graphical user interfaces, GUI runtime state feedback, program testing, Software quality},
	isbn = {0098-5589},
	doi = {10.1109/TSE.2009.68},
	author = {Xun Yuan and Memon, Atif M.}
}
@conference {15496,
	title = {Using methods \& measures from network analysis for gui testing},
	booktitle = {Software Testing, Verification, and Validation Workshops (ICSTW), 2010 Third International Conference on},
	year = {2010},
	month = {2010/04//},
	pages = {240 - 246},
	abstract = {Graphical user interfaces (GUIs) for today{\textquoteright}s applications are extremely large. Moreover, they provide many degrees of freedom to the end-user, thus allowing the user to perform a very large number of event sequences on the GUI. The large sizes and degrees of freedom create severe problems for GUI quality assurance, including GUI testing. In this paper, we leverage methods and measures from network analysis to analyze and study GUIs, with the goal of aiding GUI testing activities. We apply these methods and measures on the event-flow graph model of GUIs. Results of a case study show that "network centrality measures" are able to identify the most important events in the GUI as well as the most important sequences of events. These events and sequences are good candidates for test prioritization. In addition, the "betweenness clustering" method is able to partition the GUI into regions that can be tested separately.},
	keywords = {betweenness clustering method, event sequences, event-flow graph model, Graphical user interfaces, GUI quality assurance, GUI testing, network analysis, network centrality measures, program testing, Software quality},
	doi = {10.1109/ICSTW.2010.61},
	author = {Elsaka,E. and Moustafa,W. E and Nguyen,Bao and Memon, Atif M.}
}
@conference {14701,
	title = {Improving software quality with static analysis},
	booktitle = {Proceedings of the 7th ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering},
	series = {PASTE {\textquoteright}07},
	year = {2007},
	month = {2007///},
	pages = {83 - 84},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {At the University of Maryland, we have been working to improve the reliability and security of software by developing new, effective static analysis tools. These tools scan software for bug patterns or show that the software is free from a particular class of defects. There are two themes common to our different projects: 1. Our ultimate focus is on utility: can a programmer actually improve the quality of his or her software using an analysis tool? The important first step toward answering this question is to engineer tools so that they can analyze existing, nontrivial programs, and to carefully report the results of such analyses experimentally. The desire to better understand a more human-centered notion of utility underlies much of our future work. 2. We release all of our tools open source. This allows other researchers to verify our results, and to reuse some or all of our implementations, which often required significant effort to engineer. We believe that releasing source code is important for accelerating the pace of research results software quality, and just as importantly allows feedback from the wider community. In this research group presentation, we summarize some recent work and sketch future directions.},
	keywords = {bug patterns, bugs, C, Data races, FFIs, java, modularity, network protocols, Software quality},
	isbn = {978-1-59593-595-3},
	doi = {10.1145/1251535.1251549},
	url = {http://doi.acm.org/10.1145/1251535.1251549},
	author = {Foster, Jeffrey S. and Hicks, Michael W. and Pugh, William}
}
@article {15476,
	title = {Reliable Effects Screening: A Distributed Continuous Quality Assurance Process for Monitoring Performance Degradation in Evolving Software Systems},
	journal = {Software Engineering, IEEE Transactions on},
	volume = {33},
	year = {2007},
	month = {2007/02//},
	pages = {124 - 141},
	abstract = {Developers of highly configurable performance-intensive software systems often use in-house performance-oriented "regression testing" to ensure that their modifications do not adversely affect their software{\textquoteright}s performance across its large configuration space. Unfortunately, time and resource constraints can limit in-house testing to a relatively small number of possible configurations, followed by unreliable extrapolation from these results to the entire configuration space. As a result, many performance bottlenecks escape detection until systems are fielded. In our earlier work, we improved the situation outlined above by developing an initial quality assurance process called "main effects screening". This process 1) executes formally designed experiments to identify an appropriate subset of configurations on which to base the performance-oriented regression testing, 2) executes benchmarks on this subset whenever the software changes, and 3) provides tool support for executing these actions on in-the-field and in-house computing resources. Our initial process had several limitations, however, since it was manually configured (which was tedious and error-prone) and relied on strong and untested assumptions for its accuracy (which made its use unacceptably risky in practice). This paper presents a new quality assurance process called "reliable effects screening" that provides three significant improvements to our earlier work. First, it allows developers to economically verify key assumptions during process execution. Second, it integrates several model-driven engineering tools to make process configuration and execution much easier and less error prone. Third, we evaluate this process via several feasibility studies of three large, widely used performance-intensive software frameworks. Our results indicate that reliable effects screening can detect performance degradation in large-scale systems more reliably and with significantly less resources than conventional t- echniques},
	keywords = {configuration subset, distributed continuous quality assurance process, evolving software systems, in house testing, main effects screening, performance bottlenecks, performance degradation monitoring, performance intensive software systems, process configuration, process execution, program testing, regression testing, reliable effects screening, software benchmarks, Software performance, software performance evaluation, Software quality, software reliability, tool support},
	isbn = {0098-5589},
	doi = {10.1109/TSE.2007.20},
	author = {Yilmaz,C. and Porter, Adam and Krishna,A. S and Memon, Atif M. and Schmidt,D. C and Gokhale,A.S. and Natarajan,B.}
}
@article {15475,
	title = {Skoll: A Process and Infrastructure for Distributed Continuous Quality Assurance},
	journal = {Software Engineering, IEEE Transactions on},
	volume = {33},
	year = {2007},
	month = {2007/08//},
	pages = {510 - 525},
	abstract = {Software engineers increasingly emphasize agility and flexibility in their designs and development approaches. They increasingly use distributed development teams, rely on component assembly and deployment rather than green field code writing, rapidly evolve the system through incremental development and frequent updating, and use flexible product designs supporting extensive end-user customization. While agility and flexibility have many benefits, they also create an enormous number of potential system configurations built from rapidly changing component implementations. Since today{\textquoteright}s quality assurance (QA) techniques do not scale to handle highly configurable systems, we are developing and validating novel software QA processes and tools that leverage the extensive computing resources of user and developer communities in a distributed, continuous manner to improve software quality significantly. This paper provides several contributions to the study of distributed, continuous QA (DCQA). First, it shows the structure and functionality of Skoll, which is an environment that defines a generic around-the-world, around-the-clock QA process and several sophisticated tools that support this process. Second, it describes several novel QA processes built using the Skoll environment. Third, it presents two studies using Skoll: one involving user testing of the Mozilla browser and another involving continuous build, integration, and testing of the ACE+TAO communication software package. The results of our studies suggest that the Skoll environment can manage and control distributed continuous QA processes more effectively than conventional QA processes. For example, our DCQA processes rapidly identified problems that had taken the ACE+TAO developers much longer to find and several of which they had not found. Moreover, the automatic analysis of QA results provided developers information that enabled them to quickly find the root causes of problems},
	keywords = {ACE+TAO communication software package, component assembly, component deployment, distributed continuous quality assurance, distributed development teams, distributed processing, end-user customization, flexible product design, incremental development, object-oriented programming, Skoll, software engineering, Software quality, systems analysis},
	isbn = {0098-5589},
	doi = {10.1109/TSE.2007.70719},
	author = {Porter, Adam and Yilmaz,C. and Memon, Atif M. and Schmidt,D. C and Natarajan,B.}
}
@article {15445,
	title = {Automating regression testing for evolving GUI software},
	journal = {Journal of Software Maintenance and Evolution: Research and Practice},
	volume = {17},
	year = {2005},
	month = {2005///},
	pages = {27 - 64},
	abstract = {With the widespread deployment of broadband connections worldwide, software development and maintenance are increasingly being performed by multiple engineers, often working around-the-clock to maximize code churn rates. To ensure rapid quality assurance of such software, techniques such as {\textquoteleft}nightly/daily building and smoke testing{\textquoteright} have become widespread since they often reveal bugs early in the software development process. During these builds, a development version of the software is checked out from the source code repository tree, compiled, linked, and (re)tested with the goal of (re)validating its basic functionality. Although successful for conventional software, smoke tests are difficult to develop and automatically re-run for software that has a graphical user interface (GUI). In this paper, we describe a framework called DART (Daily Automated Regression Tester) that addresses the needs of frequent and automated re-testing of GUI software. The key to our success is automation: DART automates everything from structural GUI analysis, smoke-test-case generation, test-oracle creation, to code instrumentation, test execution, coverage evaluation, regeneration of test cases, and their re-execution. Together with the operating system{\textquoteright}s task scheduler, DART can execute frequently with little input from the developer/tester to re-test the GUI software. We provide results of experiments showing the time taken and memory required for GUI analysis, test case and test oracle generation, and test execution. We empirically compare the relative costs of employing different levels of detail in the GUI test oracle. We also show the events and statements covered by the smoke test cases. Copyright {\textcopyright} 2005 John Wiley \& Sons, Ltd.},
	keywords = {daily/nightly builds, event-flow graphs, Graphical user interfaces, GUI regression testing, GUI testing, smoke testing, Software quality},
	isbn = {1532-0618},
	doi = {10.1002/smr.305},
	url = {http://onlinelibrary.wiley.com/doi/10.1002/smr.305/abstract},
	author = {Memon, Atif M. and Nagarajan,Adithya and Xie,Qing}
}
@conference {15482,
	title = {Rapid "crash testing" for continuously evolving GUI-based software applications},
	booktitle = {Software Maintenance, 2005. ICSM{\textquoteright}05. Proceedings of the 21st IEEE International Conference on},
	year = {2005},
	month = {2005/09//},
	pages = {473 - 482},
	abstract = {Several rapid-feedback-based quality assurance mechanisms are used to manage the quality of continuously evolving software. Even though graphical user interfaces (GUIs) are one of the most important parts of software, there are currently no mechanisms to quickly retest evolving GUI software. We leverage our previous work on GUI testing to define a new automatic GUI re-testing process called "crash testing" that is integrated with GUI evolution. We describe two levels of crash testing: (1) immediate feedback-based in which a developer indicates that a GUI bug was fixed in response to a previously reported crash; only select crash test cases are rerun and the developer is notified of the results in a matter of seconds, and (2) between code changes in which new crash test cases are generated on-the-fly and executed on the GUI. Since the code may be changed by another developer before all the crash tests have been executed, hence requiring restarting of the process, we use a simple rotation-based scheme to ensure that all crash tests are executed over a series of code changes. We show, via empirical studies, that our crash tests are effective at revealing serious problems in the GUI.},
	keywords = {crash testing, graphical user interface software retesting, Graphical user interfaces, GUI-based software application, immediate feedback, program testing, rapid-feedback-based quality assurance, software evolution, Software maintenance, software prototyping, Software quality},
	doi = {10.1109/ICSM.2005.72},
	author = {Xie,Q. and Memon, Atif M.}
}
@article {15474,
	title = {Studying the fault-detection effectiveness of GUI test cases for rapidly evolving software},
	journal = {Software Engineering, IEEE Transactions on},
	volume = {31},
	year = {2005},
	month = {2005/10//},
	pages = {884 - 896},
	abstract = {Software is increasingly being developed/maintained by multiple, often geographically distributed developers working concurrently. Consequently, rapid-feedback-based quality assurance mechanisms such as daily builds and smoke regression tests, which help to detect and eliminate defects early during software development and maintenance, have become important. This paper addresses a major weakness of current smoke regression testing techniques, i.e., their inability to automatically (re)test graphical user interfaces (GUIs). Several contributions are made to the area of GUI smoke testing. First, the requirements for GUI smoke testing are identified and a GUI smoke test is formally defined as a specialized sequence of events. Second, a GUI smoke regression testing process called daily automated regression tester (DART) that automates GUI smoke testing is presented. Third, the interplay between several characteristics of GUI smoke test suites including their size, fault detection ability, and test oracles is empirically studied. The results show that: 1) the entire smoke testing process is feasible in terms of execution time, storage space, and manual effort, 2) smoke tests cannot cover certain parts of the application code, 3) having comprehensive test oracles may make up for not having long smoke test cases, and 4) using certain oracles can make up for not having large smoke test suites.},
	keywords = {daily automated regression tester, Fault diagnosis, fault-detection, formal specification, formal verification, Graphical user interfaces, GUI test cases, program testing, quality assurance mechanism, rapidly evolving software, smoke regression testing technique, software development, software fault tolerance, Software maintenance, software prototyping, Software quality, test oracles},
	isbn = {0098-5589},
	doi = {10.1109/TSE.2005.117},
	author = {Memon, Atif M. and Xie,Q.}
}
@conference {15480,
	title = {Empirical evaluation of the fault-detection effectiveness of smoke regression test cases for GUI-based software},
	booktitle = {Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on},
	year = {2004},
	month = {2004/09//},
	pages = {8 - 17},
	abstract = {Daily builds and smoke regression tests have become popular quality assurance mechanisms to detect defects early during software development and maintenance. In previous work, we addressed a major weakness of current smoke regression testing techniques, i.e., their lack of ability to automatically (re)test graphical user interface (GUI) event interactions - we presented a GUI smoke regression testing process called daily automated regression tester (DART). We have deployed DART and have found several interesting characteristics of GUI smoke tests that we empirically demonstrate in this paper. We also combine smoke tests with different types of test oracles and present guidelines for practitioners to help them generate and execute the most effective combinations of test-case length and test oracle complexity. Our experimental subjects consist of four GUI-based applications. We generate 5000-8000 smoke tests (enough to be run in one night) for each application. Our results show that: (1) short GUI smoke tests with certain test oracles are effective at detecting a large number of faults; (2) there are classes of faults that our smoke test cannot detect; (3) short smoke tests execute a large percentage of code; and (4) the entire smoke testing process is feasible to do in terms of execution time and storage space.},
	keywords = {daily automated regression tester, daily builds, fault-detection effectiveness, graphical user interface, Graphical user interfaces, GUI-based software, program testing, Quality assurance, Regression analysis, smoke regression test cases, software development, software fault tolerance, Software maintenance, Software quality, software quality assurance, test oracle complexity, test oracles, test-case length},
	doi = {10.1109/ICSM.2004.1357785},
	author = {Memon, Atif M. and Xie,Qing}
}
@article {15498,
	title = {Preserving distributed systems critical properties: a model-driven approach},
	journal = {Software, IEEE},
	volume = {21},
	year = {2004},
	month = {2004///},
	pages = {32 - 40},
	abstract = {The need for creating predictability in distributed systems is most often specified in terms of quality-of-service (QoS) requirements, which help define the acceptable levels of dependability with which capabilities such as processing capacity, data throughput, or service availability reach users. For longer-term properties such as scalability, maintainability, adaptability, and system security, we can similarly use persistent software attributes (PSAs) to specify how and to what degree such properties must remain intact as a network expands and evolves over time. The Skoll distributed continuous software quality assurance process helps to identify viable system and software configurations for meeting stringent QOS and PSA requirements by coordinating the use of distributed computing resources. The authors tested their process using the large, rapidly evolving ACE+TAO middleware suite.},
	keywords = {configuration management, formal verification, Middleware, middleware suite, model-driven approach, persistent software attributes, QoS requirements, Quality assurance, quality of service, quality-of-service, Skoll distributed computing resources, software configuration, Software maintenance, Software quality, software quality assurance process, system dependability},
	isbn = {0740-7459},
	doi = {10.1109/MS.2004.50},
	author = {Yilmaz,C. and Memon, Atif M. and Porter, Adam and Krishna,A. S and Schmidt,D. C and Gokhale,A. and Natarajan,B.}
}
@conference {15468,
	title = {Skoll: distributed continuous quality assurance},
	booktitle = {Software Engineering, 2004. ICSE 2004. Proceedings. 26th International Conference on},
	year = {2004},
	month = {2004/05//},
	pages = {459 - 468},
	abstract = {Quality assurance (QA) tasks, such as testing, profiling, and performance evaluation, have historically been done in-house on developer-generated workloads and regression suites. Since this approach is inadequate for many systems, tools and processes are being developed to improve software quality by increasing user participation in the QA process. A limitation of these approaches is that they focus on isolated mechanisms, not on the coordination and control policies and tools needed to make the global QA process efficient, effective, and scalable. To address these issues, we have initiated the Skoll project, which is developing and validating novel software QA processes and tools that leverage the extensive computing resources of worldwide user communities in a distributed, continuous manner to significantly and rapidly improve software quality. This paper provides several contributions to the study of distributed continuous QA. First, it illustrates the structure and functionality of a generic around-the-world, around-the-clock QA process and describes several sophisticated tools that support this process. Second, it describes several QA scenarios built using these tools and process. Finally, it presents a feasibility study applying these scenarios to a 1MLOC+ software package called ACE+TAO. While much work remains to be done, the study suggests that the Skoll process and tools effectively manage and control distributed, continuous QA processes. Using Skoll we rapidly identified problems that had taken the ACE+TAO developers substantially longer to find and several of which had previously not been found. Moreover, automatic analysis of QA task results often provided developers information that quickly led them to the root cause of the problems.},
	keywords = {1MLOC+ software package, ACE+TAO, around-the-clock QA process, around-the-world QA process, distributed continuous QA, distributed continuous quality assurance, distributed programming, program verification, Quality assurance, Skoll, software performance evaluation, software profiling, Software quality, Software testing},
	doi = {10.1109/ICSE.2004.1317468},
	author = {Memon, Atif M. and Porter, Adam and Yilmaz,C. and Nagarajan,A. and Schmidt,D. and Natarajan,B.}
}
@conference {15479,
	title = {DART: a framework for regression testing "nightly/daily builds" of GUI applications},
	booktitle = {Software Maintenance, 2003. ICSM 2003. Proceedings. International Conference on},
	year = {2003},
	month = {2003/09//},
	pages = {410 - 419},
	abstract = {"Nightly/daily building and smoke testing" have become widespread since they often reveal bugs early in the software development process. During these builds, software is compiled, linked, and (re)tested with the goal of validating its basic functionality. Although successful for conventional software, smoke tests are difficult to develop and automatically rerun for software that has a graphical user interface (GUI). In this paper, we describe a framework called DART (daily automated regression tester) that addresses the needs of frequent and automated re-testing of GUI software. The key to our success is automation: DART automates everything from structural GUI analysis; test case generation; test oracle creation; to code instrumentation; test execution; coverage evaluation; regeneration of test cases; and their re-execution. Together with the operating system{\textquoteright}s task scheduler, DART can execute frequently with little input from the developer/tester to retest the GUI software. We provide results of experiments showing the time taken and memory required for GUI analysis, test case and test oracle generation, and test execution. We also empirically compare the relative costs of employing different levels of detail in the GUI test cases.},
	keywords = {automated retesting, automatic test software, coverage evaluation, daily automated regression tester, DART, frequent retesting, graphical user interface, Graphical user interfaces, GUI software, instrumentation coding, program testing, regression testing, Software development management, Software development process, Software maintenance, Software quality, structural GUI analysis, Test Case Generation, test cases regeneration, Test execution, test oracle creation},
	doi = {10.1109/ICSM.2003.1235451},
	author = {Memon, Atif M. and Banerjee,I. and Hashmi,N. and Nagarajan,A.}
}
@conference {18662,
	title = {AQuA: an adaptive architecture that provides dependable distributed objects},
	booktitle = {Seventeenth IEEE Symposium on Reliable Distributed Systems},
	year = {1998},
	month = {1998/10//},
	pages = {245 - 253},
	abstract = {Dependable distributed systems are difficult to build. This is particularly true if they have dependability requirements that change during the execution of an application, and are built with commercial off-the-shelf hardware. In that case, fault tolerance must be achieved using middleware software, and mechanisms must be provided to communicate the dependability requirements of a distributed application to the system and to adapt the system{\textquoteright}s configuration to try to achieve the desired dependability. The AQuA architecture allows distributed applications to request a desired level of availability using the Quality Objects (QuO) framework and includes a dependability manager that attempts to meet requested availability levels by configuring the system in response to outside requests and changes in system resources due to faults. The AQuA architecture uses the QuO runtime to process and invoke availability requests, the Proteus dependability manager to configure the system in response to faults and availability requests, and the Ensemble protocol stack to provide group communication services. Furthermore, a CORBA interface is provided to application objects using the AQuA gateway. The gateway provides a mechanism to translate between process-level communication, as supported by Ensemble, and IIOP messages, understood by Object Request Brokers. Both active and passive replication are supported, and the replication type to use is chosen based on the performance and dependability requirements of particular distributed applications},
	keywords = {adaptive architecture, AQuA, availability requests, client-server systems, commercial off-the-shelf hardware, CORBA, dependability manager, dependability requirements, dependable distributed objects, distributed object management, Ensemble protocol stack, Fault tolerance, group communication services, middleware software, Object Request Brokers, process-level communication, proteus, Quality Objects, replication, software fault tolerance, Software quality},
	doi = {10.1109/RELDIS.1998.740506},
	author = {Cukier, Michel and Ren,J. and Sabnis,C. and Henke,D. and Pistole,J. and Sanders,W. H. and Bakken,D. E. and Berman,M.E. and Karr,D. A. and Schantz,R.E.}
}
@article {16305,
	title = {Assessing software review meetings: results of a comparative analysis of two experimental studies},
	journal = {IEEE Transactions on Software Engineering},
	volume = {23},
	year = {1997},
	month = {1997/03//},
	pages = {129 - 145},
	abstract = {Software review is a fundamental tool for software quality assurance. Nevertheless, there are significant controversies as to the most efficient and effective review method. One of the most important questions currently being debated is the utility of meetings. Although almost all industrial review methods are centered around the inspection meeting, recent findings call their value into question. In prior research the authors separately and independently conducted controlled experimental studies to explore this issue. The paper presents new research to understand the broader implications of these two studies. To do this, they designed and carried out a process of {\textquotedblleft}reconciliation{\textquotedblright} in which they established a common framework for the comparison of the two experimental studies, reanalyzed the experimental data with respect to this common framework, and compared the results. Through this process they found many striking similarities between the results of the two studies, strengthening their individual conclusions. It also revealed interesting differences between the two experiments, suggesting important avenues for future research},
	keywords = {Aggregates, Collaborative work, Computer Society, Costs, Helium, Inspection, inspection meeting, Job shop scheduling, Programming, reconciliation, Software development management, Software quality, software quality assurance, software review meeting assessment, Software reviews},
	isbn = {0098-5589},
	doi = {10.1109/32.585501},
	author = {Porter, Adam and Johnson,P. M}
}
@article {16297,
	title = {An experiment to assess the cost-benefits of code inspections in large scale software development},
	journal = {IEEE Transactions on Software Engineering},
	volume = {23},
	year = {1997},
	month = {1997/06//},
	pages = {329 - 346},
	abstract = {We conducted a long term experiment to compare the costs and benefits of several different software inspection methods. These methods were applied by professional developers to a commercial software product they were creating. Because the laboratory for this experiment was a live development effort, we took special care to minimize cost and risk to the project, while maximizing our ability to gather useful data. The article has several goals: (1) to describe the experiment{\textquoteright}s design and show how we used simulation techniques to optimize it; (2) to present our results and discuss their implications for both software practitioners and researchers; and (3) to discuss several new questions raised by our findings. For each inspection, we randomly assigned three independent variables: (1) the number of reviewers on each inspection team (1, 2, or 4); (2) the number of teams inspecting the code unit (1 or 2); and (3) the requirement that defects be repaired between the first and second team{\textquoteright}s inspections. The reviewers for each inspection were randomly selected without replacement from a pool of 11 experienced software developers. The dependent variables for each inspection included inspection interval (elapsed time), total effort, and the defect detection rate. Our results showed that these treatments did not significantly influence the defect detection effectiveness, but that certain combinations of changes dramatically increased the inspection interval},
	keywords = {Analysis of variance, code inspection cost benefits, code unit, commercial software product, Computer Society, cost-benefit analysis, Costs, defect detection effectiveness, defect detection rate, Design optimization, experienced software developers, experiment design, independent variables, Inspection, inspection interval, inspection team, Laboratories, large scale software development, Large-scale systems, live development effort, long term experiment, professional aspects, professional developers, Programming, reviewers, simulation techniques, software cost estimation, software inspection methods, software practitioners, Software quality, Switches},
	isbn = {0098-5589},
	doi = {10.1109/32.601071},
	author = {Porter, Adam and Siy,H. P and Toman,C. A and Votta,L. G.}
}
