Determining the cost of a stop-test decision (software reliability)

Ehrlich, W.K.; Prasanna, B.; Stampfel, J. P.; Wu, Jing

doi:10.1109/52.199726

Cited by 82 publications

(32 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Changes in failure rate over time can be used by management to make a decision about when to stop testing. Practical experiences of the use of reliability growth models in a variety of contexts are published, e.g., by Musa and Ackerman (1989), Ehrlich et al (1993), Wood (1996, 1997), and Jeske and Zhang (2005.…”

Section: Software Reliability Growth Modelsmentioning

confidence: 98%

A replicated empirical study of a selection method for software reliability growth models

Andersson

2006

Empir Software Eng

View full text Add to dashboard Cite

Replications are commonly considered to be important contributions to investigate the generality of empirical studies. By replicating an original study it may be shown that the results are either valid or invalid in another context, outside the specific environment in which the original study was launched. The results of the replicated study show how much confidence we could possibly have in the original study. We present a replication of a method for selecting software reliability growth models to decide whether to stop testing and release software. We applied the selection method in an empirical study, conducted in a different development environment than the original study. The results of the replication study show that with the changed values of stability and curve fit, the selection method works well on the empirical system test data available, i.e., the method was applicable in an environment that was different from the original one. The application of the SRGMs to failures during functional testing resulted in predictions with low relative error, thus providing a useful approach in giving good estimates of the total number of failures to expect during functional testing.

show abstract

Section: Software Reliability Growth Modelsmentioning

confidence: 98%

A replicated empirical study of a selection method for software reliability growth models

Andersson

2006

Empir Software Eng

View full text Add to dashboard Cite

show abstract

“…Some of the decisive factors and constraints that should be considered when to stop testing includes: achieving predetermined reliability levels, testing the budget of the software project, test the completion time limit, and code coverage. Realistically, testing of software is a trade-off between budget, time, (Dalal & Mallows, 1988;Ehrlich, Prasanna, Stampfel, & Wu, 1993;Kapur & Garg, 1990;McDaid & Wilson, 2001;Pham & Zhang, 1999;Zhang & Pham, 1998).…”

Section: Introductionmentioning

confidence: 99%

When to stop testing multi upgradations of software based on cost criteria

Kapur

Pham

Singh

et al. 2014

International Journal of Systems Science: Operations & Logi

View full text Add to dashboard Cite

Software testing is an important phase of the software development life cycle to achieve highly reliable software. Due to the time and resource limitation during the testing phase, firms do not attempt to deliver a complete and perfect product in one development cycle. They plan multi upgradations of software by adding new functionalities. Many models have been developed in the past which discuss about when to stop testing and when to release the software to the users. But they have been limited to the study of single version only. In the present framework, we describe a unified approach to address an important issue of when to stop testing the multi-upgradation of software, which is a complex process. The total debugging cost for each upgradation includes the cost of debugging in the warranty period along with the testing cost. It is assumed that the software is supported till the warranty period is over. In the proposed cost model for each upgradation, we consider that some of the remaining faults of previous release are reported and removed partly during the testing period and partly during the warranty period of new upgradation. An algorithm for finding the optimal release time for each version is developed. We estimate the parameters of the model using Statistical Package for Social Sciences on the real data set, and obtain optimum stopping time for each version of the software using Maple software.

show abstract

“…5 Initial bug density, the inverse of initial software quality, is thusB/Y . 6 This assumption is widely supported and built upon in other models (see, e.g., Okumoto and Goel 1980, Ehrlich et al 1993, Pham and Zhang 1999, Jiang et al 2012. Although other models of bug detection do exist, we follow the above tradition while utilizing a deterministic variant that maintains tractability and focus; such an approach is typical when the stochastic nature of the bug detection process is not critical to the research questions being studied (see, e.g., Ji et al 2005;Arora et al 2006;Ji et al 2011).…”

Section: The General Modelmentioning

confidence: 99%

“…Some studies account for it more abstractly as a function of time (Shantikumar and Tufekci 1983), reliability (Pham and Zhang 1999), or the number of remaining flaws (Ji et al 2005). Ehrlich et al (1993) also introduce a cost to the software firm resulting from consumer use that depends on the software failure intensity at release, the usage period, and an exogenous demand that is independent of the model parameters. Beyond postrelease bug processing and fixing costs, we further account for the fact that the firm also incurs goodwill costs at a rate that is proportional to both the current bug count and network size.…”

Section: Literature Reviewmentioning

confidence: 99%

The Influence of Software Process Maturity and Customer Error Reporting on Software Release and Pricing

August

Niculescu

2013

Management Science

View full text Add to dashboard Cite

Software producers are making greater use of customer error reporting to discover defects and improve the quality of their products. We study how software development differences among producers (e.g., varying levels of process maturity) and software class and functionality differences (e.g., operating system versus productivity software) affect how these producers coordinate software release timing and pricing to optimally harness error reporting contributions from users. In settings where prices are fixed, we characterize the optimal release time and demonstrate why in some cases it can actually be preferable to delay release when customer error reporting rates increase. The manner in which a firm's optimal release time responds to increases in software functionality critically hinges on whether the added functionality enhances or dilutes user error reporting; in both cases, the effect of added functionality on release timing can go in either direction, depending on both firm and product market characteristics. For example, when processing costs are relatively large compared to goodwill costs, firms with lower process maturity will release earlier when per module error reporting contributions become diluted and release later when these contributions become enhanced. We also examine how a firm adapts price with changes in error reporting levels and software functionality, and finally provide implications of how beta testing influences release timing.

show abstract

Determining the cost of a stop-test decision (software reliability)

Cited by 82 publications

References 3 publications

A replicated empirical study of a selection method for software reliability growth models

A replicated empirical study of a selection method for software reliability growth models

When to stop testing multi upgradations of software based on cost criteria

The Influence of Software Process Maturity and Customer Error Reporting on Software Release and Pricing

Contact Info

Product

Resources

About