Measures of testability as a basis for quality assurance

Bache, Richard; Müllerburg, Monika

doi:10.1049/sej.1990.0011

Cited by 67 publications

(36 citation statements)

References 1 publication

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The IEEE standard glossary [32] defines testability as "the degree to which a system or component facilitates the establishment of test criteria and performance of tests to determine whether those criteria have been met." Bache and Mullerburg [33] defined testability in terms of the effort required for testing. They measured this effort using the number of test cases required to satisfy a given coverage criterion.…”

Section: B Testability and Unit Testing Strategiesmentioning

confidence: 99%

“…Following the definition provided by Bache and Mullerburg [33], we used the number of test cases required to test a class according to the MaDUM testing strategy as our testability measure. Thus, this measure has been used to evaluate the testability of classes participating in APs, compared to that of other classes.…”

Section: B Testability and Unit Testing Strategiesmentioning

confidence: 99%

See 1 more Smart Citation

A Study on the Relation between Antipatterns and the Cost of Class Unit Testing

Sabané

Penta

Antoniol

et al. 2013

2013 17th European Conference on Software Maintenance and Reengineering

View full text Add to dashboard Cite

Abstract-Antipatterns are known as recurring, poor design choices; recent and past studies indicated that they negatively affect software systems in terms of understandability and maintainability, also increasing change-and defect-proneness. For this reason, refactoring actions are often suggested. In this paper, we investigate a different side-effect of antipatterns, which is their effect on testability and on testing cost in particular. We consider as (upper bound) indicator of testing cost the number of test cases that satisfy the minimal data member usage matrix (MaDUM) criterion proposed by Bashir and Goel. A study-carried out on four Java programs, Ant 1.8.3, ArgoUML 0.20, CheckStyle 4.0, and JFreeChart 1.0.13-supports the evidence that, on the one hand, antipatterns unit testing requires, on average, a number of test cases substantially higher than unit testing for non-antipattern classes. On the other hand, antipattern classes must be carefully tested because they are more defect-prone than other classes. Finally, we illustrate how specific refactoring actions-applied to classes participating in antipatterns-could reduce testing cost.

show abstract

Section: B Testability and Unit Testing Strategiesmentioning

confidence: 99%

Section: B Testability and Unit Testing Strategiesmentioning

confidence: 99%

A Study on the Relation between Antipatterns and the Cost of Class Unit Testing

Sabané

Penta

Antoniol

et al. 2013

2013 17th European Conference on Software Maintenance and Reengineering

View full text Add to dashboard Cite

show abstract

“…Software quality is of the utmost importance to both developers and users of software systems. Testing remains the most practical means of assuring the quality of software (Bache and Müllerburg 1990;Yu et al 2001).…”

Section: Introductionmentioning

confidence: 99%

Contributions of tester experience and a checklist guideline to the identification of categories and choices for software testing

et al. 2010

View full text Add to dashboard Cite

An early step for most black-box testing methods is to identify a set of categories and choices (or their equivalents) from the specification. The identification is often performed in an ad hoc manner, thus the quality of categories and choices is in doubt. Poorly identified categories and choices will affect the comprehensiveness of test cases. In this paper, we describe several comparative studies using three commercial specifications and discuss the major results. The objectives of our studies are (a) to investigate the differences in the types and amounts of mistakes made between inexperienced and experienced software testers in an ad hoc identification approach and (b) to determine the extent of mistake reduction after discussing the mistakes with the software testers and providing them with an identification checklist.

show abstract

“…Others have also focused on the internal control structure of software when discussing testability. For example, Bache and Müllerburg (1990) define a number of testability metrics for control-flow based testing strategies. In essence the metrics they proposed determine the minimum number of paths, and hence the minimum number of test cases, needed in order to satisfy particular coverage criteria.…”

Section: The Testability Conceptmentioning

confidence: 99%

Investigating the Partial Relationships Between Testability and the Dynamic Range-to-Domain Ratio

Al-Khanjari¹,

Woodward²

2003

AJIS

View full text Add to dashboard Cite

ABSTRACT:The word 'testability' has been used variously in the software community to represent a number of different concepts such as how easy it is to test a program or how easy it is to achieve execution coverage of certain program components. Voas and colleagues have used the word to capture a slightly different notion, namely the ease with which faults, if present in a program, can be revealed by the testing process. The significance of this concept is twofold. First, if it is possible to measure or estimate testability, it can guide the tester in deciding where to focus the testing effort. Secondly, knowledge about what makes some programs more testable than others can guide the developer so that design-fortest features are built in to the software. The propagation, infection and execution (PIE) analysis technique has been proposed as a way of estimating the Voas notion of testability. Unfortunately, estimating testability via the PIE technique is a difficult and costly process. However, Voas has suggested a link with the metric, domain-to-range ratio (DRR). This paper reviews the various testability concepts and summarises the PIE technique. A prototype tool developed by the authors to automate part of the PIE analysis is described and a method is proposed for dynamically determining the inverse of the domain-to-range ratio. This inverse ratio can be considered more natural in some sense and the idea of calculating its value from program execution leads to the possibility of automating its determination. Some experiments have been performed to investigate empirically whether there is a partial link between testability and this dynamic range-to-domain ratio (DRDR). Statistical tests have shown that for some programs and computational functions there is a strong relationship, but for others the relationship is weak.

show abstract

Measures of testability as a basis for quality assurance

Cited by 67 publications

References 1 publication

A Study on the Relation between Antipatterns and the Cost of Class Unit Testing

A Study on the Relation between Antipatterns and the Cost of Class Unit Testing

Contributions of tester experience and a checklist guideline to the identification of categories and choices for software testing

Investigating the Partial Relationships Between Testability and the Dynamic Range-to-Domain Ratio

Contact Info

Product

Resources

About